ROBERT MAAS
Sunnyvale, CA 94086
http://tinyurl.com/uh3t (Click on "Contact me")
e-mail: res129.3.CalRobert [at] SpamGourmet.com
OBJECTIVE: Changing fields from Programmer/Analyst to Software Engineer
SUMMARY: 10+ years experience designing & writing software
Major application areas include:
* Instructional/educational software
* Smart/expert systems
* Calculations in support of scientific research
* Automation of business systems
Programmed languages include:
* Java (on 3 platforms), including: applets, JDBC/ODBC, JSP, J2EE servlets,
XML parsing (SAX), GUI (AWT & swing), JavaDoc
* JavaScript, including calls to methods in Java classes
* C (on 4 platforms)
* C++ (on 2 platforms)
* Visual Basic
* Fortran (on 5 platforms)
* Lisp (on 6 platforms)
* Assembly/machine language (for 7 different CPUs)
* Perl/PHP/shell (just a little on one platform)
Platforms (programming environments) include: Unix/Linux shell, CGI,
Macintosh, MicroSoft Windows, and many others
SKILLS AND ACCOMPLISHMENTS:
SOFTWARE
* Wrote programming module to find longest matching segments between
correct answer and student's guess, and to present all the correct
matches back to the student in correct sequence for further edit,
which allowed computer assisted instruction software to test/coach
short-answer and fill-in-blank questions.
* Implemented my effective flashcard-drill algorithm, whereby anyone
regardless of disability or young age can learn vocabulary and
spelling.
* Wrote program to lay out text and graphics, including arbitrarily-
complex nested mathematical formulae, for printing or display.
* Wrote module to perform interactive derivations in differential
calculus and related algebra, which allowed students to create such
derivations and get them immediately graded as part of
computer-assisted instruction.
* Wrote software for very-low-overhead packet-based communication,
which allowed effective use of low-speed modems that were the only
modems affordable at the time.
* Wrote program for adaptive compression of text data, typically
achieving 3:1 compression with ordinary text and 5:1 compression with
tabular data similar to spreadsheets.
* Wrote program for computing predicted vibrational spherical harmonics
for NMR (Nuclear Magnetic Resonance) measurements of large organic
molecules, and plotting results both as function of excitation
frequency and parametrically one measurement against another, to
distinguish whether particular molecular bonds were mostly fixed or
oscillating or freely rotating.
* Wrote program for payroll, which included deductions etc., at a university,
and achieved greater speed and accuracy than previous non-computer method.
* Wrote program for pre-registration (allocated students to desired
classes as much as possible, and detected classes that were over- or
under-enrolled) at Santa Clara University, which allowed classes to be
automatially planned several months before the school term started.
* Completely designed and programmed a system for watching for
newly-arriving e-mail, distinguishing spam from legitimate e-mail,
parsing headers to find injection IP number, building and maintaining
database of spam-complaint addresses for IP blocks, automatically
composing and sending spam complaints within a minute of newly-arrived
spam, which relieved me of the burden of doing all that work manually.
Details of recent activities&accomplishments: http://tinyurl.com/352wo4
INFORMATION ORGANIZATION
* Compiled a toplevel meta-index to the InterNet, listing all the major
lists and indexes that were available online 1991-1996, allowing
Internet users to find important information before the World Wide Web
and search engines existed. http://tinyurl.com/yokhtb
* Compiled (in 1996) an index of information and advice about dealing with
network abuse (mostly "spam"). http://tinyurl.com/3xkgm9
EXPERIENCE:
Programmer/Analyst IMSSS, Stanford University, Stanford, CA
EDUCATION:
Bachelor of Science (Mathematics major) from University of Santa Clara, CA
Computer-programming classes at De Anza College, Cupertino, CA
PUBLISHED WRITINGS:
(1995) Computer-based advanced placement calculus for gifted students.
Instructional Science, 22, 339-362 (written by my supervisor about our work)
(1985) Natural-language interface for an instructable robot.
International Journal of Man-Machine Studies, 22, 215-240 (written by me)
(1984) A note on discourse with an instructable robot.
Theoretical Linguistics, 11, 5-20 (written by my supervisor about my work)
(1978) Magnetic relaxation analysis of dynamic processes in
macromolecules in the pico- to microsecond range.
Biophysical Journal, Vol 24, 103-117 (jointly written by supervisor and me)
(1970) Abstract on differential algebra published in Notices of the AMS (by me)
ACADEMIC/INTELLECTUAL HONORS, PROFESSIONAL LICENSES:
- First place in University of Santa Clara High School Mathematics
contest for three years
- Undergraduate mathematics research project at University of Santa
Clara for five summers
- Among top five (in United States) in William Lowell Putnam
undergraduate mathematics competition
- Passed California civil service exam for Programmer/Analyst I
- Passed Mensa exam, achieving top 1% on BOTH tests, whereas achieving
top 2% on EITHER test is sufficient to qualify for Mensa
- Passed federal civil service exam for Writing & Public Info
SKILLS/BUZZWORDS/PHRASES (in alphabetical order):
1620, 360/370, 6502, 68000, 8080, acia, algol, altair 8800a,
anti-spam, applet, archie, arpanet, assembler, awt, bachelor of
science degree, balanced binary trees, bitmapped image of graph to
parameterized lineaments, bitnet, blockade puzzles for 3-yr-olds or
dan quayle, bnf-driven type-checking, c, c++, cai, calculus, canonical
representations, card input, cgi, class-assignment, client/server
telecommunications, clustering, cmucl, cobol, college graduate,
combinatorics, computer-assisted instruction, console typewriter,
consumerism, cross-reference, data compression, ddt, dec pdp-10,
destructuring, device interfaces, diablo disks, diet optimization,
differential algebra, differential polynomials, dm2500 emulator,
docindex, dom, eqd, expert system, file maintenance and indexing,
finger, flashcard drill, forth, fortran, four-phase iv/70, fractals,
frontpanel, ftp, gcd, generalized computer dating, graph hockey, gui,
hashing, heapsort, help-net, hermes, high-level languages, html,
hypercard, hypertalk, i/o device interrupt handlers, ibm 1130, ibm
1620, ibm 360/370, image processing, imsss, indexing, info-nets,
information retrieval and indexing, intel 8080, interval arithmetic,
interval refinement stochastic mapping, inventions, its, j2ee, j2se,
java, javadoc, javascript, jdbc, jsax, jsp, jsys, kermit, large prime
numbers, lattice manipulation, laying out text, linux, lisp, listserv,
maasinfo, machine language, macintosh, macintosh allegro common lisp,
macl, maclisp, macsyma, mail, mainsail, mathematical research,
mathematical-formula printer, mathematics, mathprinter, mensa,
meta-index, microsoft windows, mos 6502, ms-windows, natural language
understanding, net-relaxation, netnews, netscout, nmr relaxation,
note, nuclear magnetic resonance relaxation, numrel, nutritional
diets., odbc, opacs, os traps, packet-based data communication,
packet-based telecommunications, pacs-l, payroll, pcnet, pdp-10, perl,
permutations, php, pnews, pocket forth, portable standard lisp,
porting, pre-registration, prettyprinter, principal differential
ideals, processing and rendering remote-sensing multi-spectral images,
programmer/analyst, proofreading, proximity-hashing, pseudo-random
numbers, psl, putnam contest, pvm, rdrlist, redhat linux, reduce,
rlisp, rmail, rmi, rn, rsa cryptosystem, rscs, s-expressions, sail,
save/restore environment, sax, segmat, servlets, sesame c,
shortanswertests, single-step debugger, sl, software engineer, sokoban
puzzles for 3-yr-olds or dan quayle, sort/merge, space exploration,
sprouts, standard lisp, stanford, stipple, sunos, svc202 commands,
swing, syntax&semantics checking, syscalls, telecommunications,
telnet, tenex, terminal emulation, text compression, toolbox traps,
topindex, toplevel meta-index, tops-10, uci-lisp, university payroll,
university pre-registration, unix, us citizen, usenet, uuo, vb,
versaterm, virus detection and removal, visual basic, visual c/c++,
vm/cms, waits, wilbur, word problems, wordprob, writing & public info,
www, xml, zmodem, zterm.
On 29 Jan, 10:31, ········································@MaasInfo.Org
(Robert Maas) wrote:
> ROBERT MAAS
> Sunnyvale, CA 94086
I don't think that comp.programming is really a suitable place for a
CV. I suspect that the two *.lang.* groups aren't, either.
> PUBLISHED WRITINGS:
> (1995) Computer-based advanced placement calculus for gifted students.
> Instructional Science, 22, 339-362 (written by my supervisor about our work)
> (1985) Natural-language interface for an instructable robot.
> International Journal of Man-Machine Studies, 22, 215-240 (written by me)
> (1984) A note on discourse with an instructable robot.
> Theoretical Linguistics, 11, 5-20 (written by my supervisor about my work)
> (1978) Magnetic relaxation analysis of dynamic processes in
> macromolecules in the pico- to microsecond range.
> Biophysical Journal, Vol 24, 103-117 (jointly written by supervisor and me)
> (1970) Abstract on differential algebra published in Notices of the AMS (by me)
It seems a bit odd to include in your "published writings" two papers
written solely by someone else.
> SKILLS/BUZZWORDS/PHRASES (in alphabetical order):
> ... blockade puzzles for 3-yr-olds or
> dan quayle ...
I'd advise re-writing this bit. There seem at least four problems with
it:
1) Putting jokes in your CV looks unprofessional;
2) It makes you look cynical, which is possibly not a good idea when
you are trying to get a job;
3) You may well annoy someone of a different political viewpoint;
4) it looks a bit dated now.
Neverthless, I hope you do find employment soon.
Best of luck.
Paul.
> From: ······@aol.com
> I don't think that comp.programming is really a suitable place
> for a CV.
It's not a CV, it's a resume, a 1-2 page summary (plus keywords to
trigger search engines that recruiters use). A CV is much more
complete, perhaps five or ten pages of detail (not counting the
keywords).
> I suspect that the two *.lang.* groups aren't, either.
I've been posting to ba.jobs.resumes and/or misc.jobs.resumes since
1991, but haven't gotten any job since 2.5 weeks in 1992, and
haven't even gotten an interview since 1994. I've tried posting to
Web-based job boards more recently, but not a single
employer/recruiter ever contacted me as a result to tell me about
any job even close to what I can do. All I've gotten in response to
my Web-based resume postings is spam spam and more spam, mostly
from CareerBuilder and Monster. If you can think of any reasonable
place to post my resume where I'll get legitimate queries for more
information about my skills for jobs or which my resume shows I
mostly qualify, please tell me where.
Meanwhile I'm really really desperate, and since most of my
experience is in Lisp I feel that comp.lang.lisp is a reasonable
place to post my resume, and since java is the only currently
popular language where I'm competant I feel that
comp.lang.java.programmer is a reasonable place to post, and since
I have experience in ten or twenty different languages depending on
how you count them (assembly language on six different CPUs counts
as 1 or 6? 3 different dialects of FORTRAN counts as 1 or 3? 6
different dialects of Lisp counts as 1 or 6?), plus my Hello-CGI
project to document how to get started programming in several
additional languages or Web server-side applications, I feel my
wide variation of programming languages and ability to learn more
qualifies me to post my resume in comp.programming to catch anybody
who wants to hire me for some odd job in a new language nobody yet
knows but which I can learn quickly.
> It seems a bit odd to include in your "published writings" two
> papers written solely by someone else.
They were written specifically about my work and/or projects that
include my work as a major part.
During my work on nuclear magnetic resonace relaxation, I tried a
new idea for classifying molecular side-chains as to whether they
wobbled or freely rotated, which turned out to be successful, and
that result of mine was a key point in enabling the publishing of
the results of the research project. My name was listed as one of
the authors of the paper, whose head author was the leader of the
research team. It's difficult to squeeze all that explanation into
a **resume**, better the employer who is interested in NMR research
contact me for more info.
During my work on CAI for calculus, my idea for the derivational
engine was the number one key new idea in making the five-year
project feasible. Without my idea, and subsequent implementation by
me, the CAI systen would have been worthless because didn't go
beyond what old systems for CAI already did. Again, the leader of
the project wrote up a description of our system to publish. It
wouldn't have been reasonable for each individual programmer to
publish his/her own contribution independently.
By the way, I'm starting a new job-ad-filtering "cooperative",
whereby job-seekers mark up help-wanted ads to identify the
specific required skills/experience in each, and then submit these
tagged ads to a database. The database is then automatically
searched for each job-seeker to eliminate jobs for which that
person is definitely *not* qualified (for example if it requires 3
years experience using JBoss and WebSphere but that particular
job-seeker has not even *seen* either of those application
frameworks, much less gotten years of experience using both), and
then show the job-seeker just the remaining jobs. This way
job-seekers wouldn't have to scan thousands of jobs, *each* of
which requires such a skill the job-seeker doesn't have, becoming
too exhausted to continue, and being forced to quit looking before
finding even one job ad for which the person might qualify. If
anybody reading this thread is interested in joining my FilJob
(short for filter-job) "cooperative", use this URL:
<http://tinyurl.com/filjob>
On Sat, 31 Jan 2009 17:01:54 -0800, Robert Maas wrote:
>> From: ······@aol.com
>> I don't think that comp.programming is really a suitable place for a
>> CV.
>
> It's not a CV, it's a resume, a 1-2 page summary (plus keywords to
> trigger search engines that recruiters use). A CV is much more complete,
> perhaps five or ten pages of detail (not counting the keywords).
Hi Rob,
I would suggest you write a CV, in a conventional format. There are
plenty of samples on the web. People who are reviewing job
applications get lots of them, and are willing to discard yours at the
sign of the slightest oddity.
> I've been posting to ba.jobs.resumes and/or misc.jobs.resumes since
> 1991, but haven't gotten any job since 2.5 weeks in 1992, and haven't
> even gotten an interview since 1994. I've tried posting to Web-based job
That's not a coincidence. Something is wrong with the way you are
searching for jobs. Posting to random places like c.l.l is not the
answer - talk to a professional career advisor about this, or at least
try to find the necessary advice on the web. But if I were you, I
would talk to a professional, it is well worth it.
>> It seems a bit odd to include in your "published writings" two papers
>> written solely by someone else.
>
> They were written specifically about my work and/or projects that
> include my work as a major part.
Publications matter for academic jobs, and since you don't have a PhD,
you are not a likely candidate for one of those. So drop these
entirely, and perhaps include a _short_ summary in a Projects section
in your CV.
Write a concise, conventional CV, with job history, education, DATES
for everything, etc. It is difficult to find a job with a long
history of unemployment, since that is a bad signal that something is
wrong with you. Do not sound desperate (I know, it is difficult), and
don't advertise the fact that you are desperate on public forums -
potential employees may google for you.
So I reiterate: get advice from an experienced person (if you have a
friend who does HR at a company, any company, even outside your field,
that could be very helpful), and change your job search strategy.
Good luck,
Tamas
> From: Tamas K Papp <······@gmail.com>
> I would suggest you write a CV, in a conventional format.
I'm in the USA, and around here a CV is used *only* for tenured
faculty positions, whereas a resume is used for all other
professional and technical positions. Accordingly your advice to
post a CV isn't useful to me. I understand that in Europe, a CV is
used more commonly, so I'm guessing that's "where you're coming from".
> Something is wrong with the way you are searching for jobs.
That's correct. But none of the advice I've gotten over the past 17
years has gotten me even one job interview since 1994 (and it got
me only a "handful" of intehviews even from 1991-94: Computer aided
design using embedded Lisp, data compression, data encryption,
HyperCard-specific tool for a new kind of "book", Unix-specific
tool for classifying news articles, and one other I forget what).
> Posting to random places like c.l.l is not the answer
More than two thirds of my software programming has been in Lisp.
None of the regular job boards have had even one Lisp programming
job in over a dozen years. None of the regular employers posting
job ads to regular job boards would even allow me to write one line
of code in Lisp in the context of work they're paying me for. Where
else than c.l.lisp would I be likely to find people who appreciate
Lisp and would allow me to write software using Lisp if they hired
me to work for them at all, as opposed to absolutely forbidding use
of Lisp in my work for them?
> talk to a professional career advisor about this
I have no money to pay anybody like that. The only decent advice I
ever gotten from the free career-advice/help agencies was three
years ago when Connect in the EDD building in Sunnyvale gave me a
class in how to upgrade my resume per recent standards expected of
employers.
> or at least try to find the necessary advice on the web.
I was very active in misc.jobs.misc and ba.jobs.misc (or
.discussion after the name change), but nobody in either group ever
gave me any useful advice.
> Publications matter for academic jobs, and since you don't have a
> PhD, you are not a likely candidate for one of those.
You don't seem to be well informed. Nearly all my paid software
work has been in academic setting: Working while undergraduate for
my school (payroll and pre-registration), doing odd jobs for
somebody at my alma mater, and working for various places in
Stanford University (A.I. lab, Magnetic Resonance lab, Applied
Earth Sciences department, and Institute for Mathematical Studies
in the Social Sciences). Obviously I was a candidate for all those
jobs. Are you denying that, or saying that those kinds of jobs,
working as staff in a college/university, are no longer available
like they were until 1991? If you mean the latter, then your
wording is wrong, because it's not that I'm not qualified (because
of not having a Ph.D.), but that that kind of job no longer exists
at all (or else somebody in c.l.lisp would have mentionned one of
the jobs at least once within the past 15 years).
> So drop these entirely,
At the present time, not one person has seriously looked at *any*
of my useful work since 1992, and I no longer have any way to
contact anybody I used to work for before then, so the *only*
written proof I have that I ever did anything useful would be those
published reports about my work. It seems to me that it's better to
have pubilshed writings describing my work than no "references" at
all. Anyone want to debate that point?
> and perhaps include a _short_ summary in a Projects section in your CV.
I'm not sure I understand you fully. Please explain your meaning.
> Write a concise, conventional CV, with job history, education,
> DATES for everything, etc.
At this point I'm going to regard you as an utter idiot or asshole/berzerker.
"Shooting myself in the foot" by making it blatantly obvious that
I've had no paying work, since 1992, not even formal volunteer work
in all this time, is the fastest way to mv resume /dev/null
> Do not sound desperate (I know, it is difficult),
There is nothing in my r{e'}sum{e'} to indicate that I'm desperate.
Au contraire, I cite several examples of where I've done great good by my work.
> and don't advertise the fact that you are desperate on public
> forums - potential employees may google for you.
You sound like those Army commanders who tell the soldiers
suffering "shell shock" to "suck it up", which is why the suicide
rate has increased greatly in recent years.
> ... if you have a friend ...
I don't. I've never been able to find anyone who had enough
intellectual and emotional compatibilty with me plus interest/time
in establishing a personal relationship with me. The only two
intellectual peers I ever found to hang around with were Bill
Gosper and Hans Moravec, but neither was compatible with me on the
personal level (Bill has no concept of a man's need for female
companionship, and Hans is 100% shy about any personal-feelings
talk of any kind whatsoever; otherwise each was a great peer buddy
and "friend in need" in impersonal way), and our hanging around
ended many years ago, before I became unemployed.
> change your job search strategy.
I've done that several times since I got laid off in 1991, but
so-far none of the changes have gotten me any employment.
You don't seem to like my latest re-write of my resume. Perhaps
you'd be willing to look at all the resumes I've written since I
became unemployed in 1991, and tell me what you think is wrong with
each, and which of them you *dis*like the least (since obviously
you have such a negative attitude at my attempts that you wouldn't
ever like *any* resume that I write even if I write it just the way
you ask me to)? Also look at a resume that a "professional career
adviser" at De Anza college wrote for me and tell me if you like it?
By the way, if I can't get a paying job, at least maybe I can save
the world's economy by some of the economic measures I've proposed
recently <http://tinyurl.com/5llxwu> (if I can find somebody in or
government who will seriously listen to my ideas, unlike Anna Eshoo
who totally ignores my messages), and by the new "cooperative" kind
of economy I'm planning to set up on the Web in lieu of any
reasonable government action. Do you know anyone would be
interested in joining me to work on any part of this "cooperative"
project? Similar ideas described:
<http://en.wikipedia.org/wiki/Cooperative>
<http://en.wikipedia.org/wiki/Commune_(intentional_community)>
"producer co-operatives, in which the producers of a
co-operative's goods and services are defined as its users"
<http://www.123exp-business.com/t/04254093613/>
<http://www.nncc.org/Choose.Quality.Care/qual.sitter.coop.html>
I have several ideas for specific services that would be included
in the overall "cooperative". Most of the ideas for projects listed
here <http://shell.rawbw.com/~rem/WAP/projectIdeas.html> would be
appropriate. Perhaps one of those specific projects would be more
interesting to you than the general mechanism for managing the
per-user balance between labor performed and services received
which maintains the "cooperative" by avoiding the "Little Red Hen"
"tragedy of Commons"??
Robert Maas, http://tinyurl.com/uh3t wrote:
>> From: Tamas K Papp <······@gmail.com>
>> Posting to random places like c.l.l is not the answer
>
> More than two thirds of my software programming has been in Lisp.
I think you may have isolated the problem. Seriously, you really need to
diversify. And I don't mean into Scheme... ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Robert Maas wrote:
>> From: ······@aol.com
>> I don't think that comp.programming is really a suitable place
>> for a CV.
>
> It's not a CV, it's a resume, a 1-2 page summary (plus keywords to
> trigger search engines that recruiters use). A CV is much more
> complete, perhaps five or ten pages of detail (not counting the
> keywords).
My CV is 2 pages long. I believe "resume" is American for CV. If you are
interested in working in Europe, I would recommend also using "CV".
> Meanwhile I'm really really desperate, and since most of my
> experience is in Lisp...
If you diversify into OCaml or F#, I'll gladly help you advertise your
products.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Robert Maas wrote:
>>> From: ······@aol.com
>>> I don't think that comp.programming is really a suitable place
>>> for a CV.
>> Meanwhile I'm really really desperate, and since most of my
>> experience is in Lisp...
>
> If you diversify into OCaml or F#, I'll gladly help you advertise your
> products.
Products ????
He is looking for a job !
Arne
Arne Vajhøj wrote:
> Jon Harrop wrote:
>> If you diversify into OCaml or F#, I'll gladly help you advertise your
>> products.
>
> Products ????
>
> He is looking for a job !
I suspect he's looking for income.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-02-05, Jon Harrop <···@ffconsultancy.com> wrote:
> Arne Vajhøj wrote:
>> Jon Harrop wrote:
>>> If you diversify into OCaml or F#, I'll gladly help you advertise your
>>> products.
>>
>> Products ????
>>
>> He is looking for a job !
>
> I suspect he's looking for income.
But income without a regular job generally requires better people skills than
job income. Or at least the equivalent job income.
In comp.programming Kaz Kylheku <········@gmail.com> wrote:
| On 2009-02-05, Jon Harrop <···@ffconsultancy.com> wrote:
|> Arne Vajh?j wrote:
|>> Jon Harrop wrote:
|>>> If you diversify into OCaml or F#, I'll gladly help you advertise your
|>>> products.
|>>
|>> Products ????
|>>
|>> He is looking for a job !
|>
|> I suspect he's looking for income.
|
| But income without a regular job generally requires better people skills than
| job income. Or at least the equivalent job income.
Or skills in the art of the con, or knowing how to not get caught after a
bank heist.
--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
················@ipal.net wrote in ················@news1.newsguy.com:
>| But income without a regular job generally requires better people
>| skills than job income. Or at least the equivalent job income.
>
> Or skills in the art of the con, or knowing how to not get caught
> after a bank heist.
Them's people skills.
Kaz Kylheku wrote:
> On 2009-02-05, Jon Harrop <···@ffconsultancy.com> wrote:
>> Arne Vajhøj wrote:
>>> Jon Harrop wrote:
>>>> If you diversify into OCaml or F#, I'll gladly help you advertise your
>>>> products.
>>>
>>> Products ????
>>>
>>> He is looking for a job !
>>
>> I suspect he's looking for income.
>
> But income without a regular job generally requires better people skills
> than job income. Or at least the equivalent job income.
By that argument, I have good people skills.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
> From: Kaz Kylheku <········@gmail.com>
> But income without a regular job generally requires better people
> skills than job income.
Perhaps under the current economic system. On the other hand what
if there were an online auction site for bidding on short-term
contracts, where all you need to do is
(1) make the lowest bid on the contract
(2) complete the contract before the deadline
and you get paid automatically? No need to talk your way into the
contract. Just bid-then-perform. That's it. No people skills
needed?
From: George Peter Staplin
Subject: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <grrb37$eu5$1@news.xmission.com>
Robert Maas, http://tinyurl.com/uh3t wrote:
>> From: Kaz Kylheku <········@gmail.com>
>> But income without a regular job generally requires better people
>> skills than job income.
>
> Perhaps under the current economic system. On the other hand what
> if there were an online auction site for bidding on short-term
> contracts, where all you need to do is
> (1) make the lowest bid on the contract
> (2) complete the contract before the deadline
> and you get paid automatically? No need to talk your way into the
> contract. Just bid-then-perform. That's it. No people skills
> needed?
There is such an online auction site, or at least was. It was overrun by
people that didn't know what they were doing, and the quality was often
questionable from what I've heard of the work. Perhaps things have changed
by now.
People skills do say a lot about a person, or lack thereof.
A bigger problem is often that some companies are wasting the time of US
programmers with H-1B visa scams, with phoney ads, so that they can use
foreign workers.
See the video here about "Fake job ads":
http://www.youtube.com/programmersguild
The law firm that made that video got into a lot of trouble, but as far as I
know, their client list wasn't leaked yet. If that ever happens, we might
find that big and well known companies are intentionally using the H-1B
Visa system to take advantage of foreigners and force them to work long
hours for less pay than a US worker.
My understanding that many of the jobs with rare qualifications are about
this type of scam. It's pretty wide spread from what I've been able to
tell. You don't have to search long to find one of those jobs through the
want ads, or sites like Monster, Dice, etc.
Even Bill Gates has lied about the H-1B visa program. See:
http://www.youtube.com/watch?v=0BIvffAHsJs
http://www.youtube.com/watch?v=RDltU1ysQTE
Microsoft is not entirely staffed or run by corrupt people, but they have
given some of the people that work there a bad reputation. It casts a
shadow of doubt on people like Tony Hoare, and Leslie Lamport, due to guilt
by association.
Eventually these corrupt companies will fail. I'm hoping that employees
that are being replaced, or about to be, will consider that they have all
of the power. If you unite, you can replace the entire company and do
something better.
Note: I have nothing necessarily against some poor foreigner taking a job
from a company. What I think is wrong is that they are being taken
advantage of, and the company is hurting the local economy. Some companies
use that leverage to manipulate foreign workers. They should put more
emphasis in school on business ethics, especially with regard to lies,
otherwise the management of companies must learn the hard way how their
choices effect society.
-George
On 12 Apr, 01:01, George Peter Staplin <········@xmission.com> wrote:
> Robert Maas,http://tinyurl.com/uh3twrote:
> > No need to talk your way into the
> > contract. Just bid-then-perform. That's it. No people skills
> > needed?
>
> SNIP
>
> People skills do say a lot about a person, or lack thereof.
People skills say a lot about the lack of a person ???
But seriously what does lack or existence of people skills
say about a person beyond the mere fact itself ?
> Note: I have nothing necessarily against some poor foreigner taking a job
> from a company. What I think is wrong is that they are being taken
> advantage of, and the company is hurting the local economy. Some companies
> use that leverage to manipulate foreign workers. They should put more
> emphasis in school on business ethics, especially with regard to lies,
> otherwise the management of companies must learn the hard way how their
> choices effect society.
<....must....resist....urge....to....make....political....comment....>
> From: George Peter Staplin <········@xmission.com>
> >> But income without a regular job generally requires better people
> >> skills than job income.
> > Perhaps under the current economic system. On the other hand what
> > if there were an online auction site for bidding on short-term
> > contracts, where all you need to do is
> > (1) make the lowest bid on the contract
> > (2) complete the contract before the deadline
> > and you get paid automatically? No need to talk your way into the
> > contract. Just bid-then-perform. That's it. No people skills
> > needed?
> There is such an online auction site, or at least was. It was
> overrun by people that didn't know what they were doing, and the
> quality was often questionable from what I've heard of the work.
> Perhaps things have changed by now.
Can you please try to find it and show me where to find it?
> People skills do say a lot about a person, or lack thereof.
But such skills as needed to hussle a job under the current system
are irrelevant to many kinds of work, such as computer programming.
It really sucks that good skilled people with lots of other skills
are neglected for employment because they don't have that one
specific skill job-hustling and none of the employment agencies are
willing to do their supposed job.
> A bigger problem is often that some companies are wasting the time of US
> programmers with H-1B visa scams, with phoney ads, so that they can use
> foreign workers.
> See the video here about "Fake job ads":
> http://www.youtube.com/programmersguild
I have no way to see that video here but I've made a note just now
to try to see it next time I'm at a semi-public computer lab where
watching InterNet videos is possible.
> ... My understanding that many of the jobs with rare qualifications
> are about this type of scam. It's pretty wide spread from what
> I've been able to tell. You don't have to search long to find one
> of those jobs through the want ads, or sites like Monster, Dice,
> etc.
A few days ago, on recommendation from someody who claimed DICE was
good, I tried a job search through DICE. I found only a very few
jobs at all in my category and nearby, with only one that I
qualified for per the requirements section, which said *nothing*
except that I needed 4 years experience software programming,
nothing specific at all, although the job duties section was full
of stuff I had not the slightest idea how to do them, but just to
harass them for posting such a stupid ad I applied anyway. I also
applied at a company that is two blocks from where I live despite
the fact it requires a security clearance plus lots of experience
with military specs etc., only because they are so very very
conveniently located that I've been wanting to get my resume to
them just in case they have some job not requiring security
clearance, and this was my first chance, a shot in the dark.
As for jobs I really qualify for, I haven't seen one in more than a
dozen years.
> http://www.youtube.com/watch?v=0BIvffAHsJs
> http://www.youtube.com/watch?v=RDltU1ysQTE
Likewise noted for later attempt to watch.
> Note: I have nothing necessarily against some poor foreigner
> taking a job from a company.
I neither, but when I'm willing to work at the legal minimum wage
but the company says i'm too expensive so they'll hire the
foreigner instead to save money, it totally pisses me off, either
that they are breaking the law, or they are simply not listening to
me that I'm really highly skilled but after 17+ years unemployment
I'm desperate to find a job even if I have to work at minimum wage
to "get my foot (back) in the door".
-- Maas Wireless Web Services: http://tinyurl.com/6l6ke3
Robert Maas, http://tinyurl.com/uh3t wrote:
...
> As for jobs I really qualify for, I haven't seen one in more than a
> dozen years.
...
If I wanted a job, and was not qualified for any recently advertised
jobs, I would do the following:
1. Pick a skill set that is needed both for advertised jobs, and for at
least one major, well-known, active open source project.
2. Get studying. Study the chosen skill set, and also the open source
project.
3. As soon as possible, start contributing to the project. In the early
stages, use general programming skills to analyze bugs. As I built
knowledge of the project and the skills, I would expect to be able to
propose implementations of requested enhancements.
The objective would be to simultaneously build three things: in-demand
skills, a body of code to which I had made significant contributions
using those skills, and set of programmers with whom I had good
cooperative relationships.
4. Apply for jobs that need the skill set, pointing to the open source
contributions as evidence of recent experience, and asking other
participants to act as references.
Patricia
On 8 May, 16:10, Patricia Shanahan <····@acm.org> wrote:
> Robert Maas,http://tinyurl.com/uh3twrote:
>
> ...> As for jobs I really qualify for, I haven't seen one in more than a
> > dozen years.
>
> ...
>
> If I wanted a job, and was not qualified for any recently advertised
> jobs, I would do the following:
>
> 1. Pick a skill set that is needed both for advertised jobs, and for at
> least one major, well-known, active open source project.
No, no, no! Stick to LiSP, it is The Best Language.
1Z <···········@yahoo.com> wrote in news:d80bd6bf-19d7-4d02-b5d5-
············@t11g2000vbc.googlegroups.com:
> No, no, no! Stick to LiSP, it is The Best Language.
It's not the best language to get hired as a code monkey. A big project
using as typical programming language often becomes a nightmare mess, and
some of the key programmers quit because they find better jobs. That's why
the project needs to hire more programmers.
In Common Lisp, the person who wrote the program is more likely to stay to
keep improving it. There is usually no need to hire any other programmers
than that one. So you're less likely to find jobs advertised for Common
Lisp programmers, simply because they aren't needed.
On 8 Mai, 21:33, "eric-and-jane-smith" <·······@nospam.com> wrote:
> 1Z <···········@yahoo.com> wrote in news:d80bd6bf-19d7-4d02-b5d5-
> ············@t11g2000vbc.googlegroups.com:
>
> > No, no, no! Stick to LiSP, it is The Best Language.
>
> It's not the best language to get hired as a code monkey.
But it is the best language to stay unemployed.
> A big project using a typical programming language often
> becomes a nightmare mess, and ...
In your parallel universe non Lisp programs automatically
become a nightmare mess?
> some of the key programmers quit because they find better jobs.
Probably as Lisp programmers with very attractive salary. :-)
> That's why the project needs to hire more programmers.
The size of a project has no influence of the team size?
> In Common Lisp, the person who wrote the program is more likely to stay to
> keep improving it.
Or to debug and test endlessly because code coverage
tests with 100% code coverage are necessary after each
change. Dynamic typing has advantages ...
> There is usually no need to hire any other programmers
> than that one.
In which reality do companys only hire one programmer
independend of the size of the task?
> So you're less likely to find jobs advertised for Common
> Lisp programmers, simply because they aren't needed.
Well, this is your explanation why the chances to get a job
as Lisp programmer are small. Other people will have other
explanations. At the end the explanation is irrelevant. If you
want to get a job you must have skills that are searched for.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at wrote in
·········································@r36g2000vbr.googlegroups.com:
> But it is the best language to stay unemployed.
Even better than Seed7?
On 9 Mai, 01:24, "eric-and-jane-smith" <·······@nospam.com> wrote:
> ·············@gmx.at wrote ···········································@r36g2000vbr.googlegroups.com:
>
> > But it is the best language to stay unemployed.
>
> Even better than Seed7?
Yes, in this regard I consider Lisp as the best language ever.
At least I have never heard of a person being unemployed
for more than a dozen years because of Seed7 or any other
programming language skills.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at wrote in
·········································@t10g2000vbg.googlegroups.com:
> Yes, in this regard I consider Lisp as the best language ever.
> At least I have never heard of a person being unemployed
> for more than a dozen years because of Seed7 or any other
> programming language skills.
You're saying you think he's unemployed because of CL? If you read what he's been
posting for years about not being able to get a job, you would realize his problem has
nothing to do with CL.
CL competence is valuable for programming job applicants. I'm not saying he does or
doesn't have such competence, but just that it's unrelated to the real reason why he
can't get a job.
You should learn CL yourself. Even if you never have any use for it in any job, what
you learn from it can make you a much better programmer in any programming language.
On 10 Mai, 21:45, "eric-and-jane-smith" <·······@nospam.com> wrote:
> ·············@gmx.at wrote ···········································@t10g2000vbg.googlegroups.com:
>
> > Yes, in this regard I consider Lisp as the best language ever.
> > At least I have never heard of a person being unemployed
> > for more than a dozen years because of Seed7 or any other
> > programming language skills.
>
> You're saying you think he's unemployed because of CL?
No.
> If you read what he's been
> posting for years about not being able to get a job, you would realize his problem has
> nothing to do with CL.
Agree. OTOH I had discussions with several Lisp enthusiast
which did not show any people skills. The habbit to suppose
that everybody, who doesn't have the same opinion is an idiot,
is not really helpful to convince people. Discussions are about
exchanging opinions and not about forcing an opinion to others.
> CL competence is valuable for programming job applicants.
You probably know that there are much bigger markets than
CL competence...
> I'm not saying he does or
> doesn't have such competence, but just that it's unrelated to the real reason why he
> can't get a job.
>
> You should learn CL yourself. Even if you never have any use for it in any job, what
> you learn from it can make you a much better programmer in any programming language.
By pure coincidence I just bought a book about Lisp a few days
ago. I had some Lisp knowledge already and wanted more
information. From what I have seen so far I can tell you:
I will not turn into a Lisp fan. :-)
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
On May 11, 3:47 am, ·············@gmx.at wrote:
> On 10 Mai, 21:45, "eric-and-jane-smith" <·······@nospam.com> wrote:
[...]
> > If you read what he's been posting for years about
> > not being able to get a job, you would realize his
> > problem has nothing to do with CL.
> Agree. OTOH I had discussions with several Lisp enthusiast
> which did not show any people skills.
Eh, some people are jerks wherever you go, but I've really seen no
evidence that Lisp attracts them at a higher rate than any other
programming language.
[...]
> > CL competence is valuable for programming job applicants.
> You probably know that there are much bigger markets than
> CL competence...
Market size is hardly the only factor when it comes to determining the
value of a skill.
Cheers,
Pillsy
[...]
Pillsy <·········@gmail.com> writes:
>> Agree. OTOH I had discussions with several Lisp enthusiast
>> which did not show any people skills.
>
> Eh, some people are jerks wherever you go, but I've really seen no
> evidence that Lisp attracts them at a higher rate than any other
> programming language.
Not /jerks/ perhaps, but maybe Asperger Syndrome type personalities?
But that's the case for math and computer science in general.
--
(espen)
On May 11, 9:46 am, Espen Vestre <·····@vestre.net> wrote:
> Pillsy <·········@gmail.com> writes:
[...]
> > Eh, some people are jerks wherever you go, but I've really seen no
> > evidence that Lisp attracts them at a higher rate than any other
> > programming language.
> Not /jerks/ perhaps, but maybe Asperger Syndrome type personalities?
I don't think Lisp is worse for this than any other programming
language.
> But that's the case for math and computer science in general.
Kinda, yeah. Though I tend to dislike dragging autism spectrum
disorders into conversations like this one....
Cheers,
Pillsy
[...]
Pillsy <·········@gmail.com> writes:
>> But that's the case for math and computer science in general.
>
> Kinda, yeah. Though I tend to dislike dragging autism spectrum
> disorders into conversations like this one....
I agree - I was merely commenting on your general statement, just to
make that clear.
--
(espen)
·············@gmx.at wrote in
·········································@u10g2000vbd.googlegroups.com:
> By pure coincidence I just bought a book about Lisp a few days
> ago. I had some Lisp knowledge already and wanted more
> information. From what I have seen so far I can tell you:
> I will not turn into a Lisp fan. :-)
"a book about lisp"
Are you saying the book you bought isn't good enough to convince you to
learn Lisp? And you want me to guess what book it is? Or what?
·············@gmx.at wrote:
>> By pure coincidence I just bought a book about Lisp a few days
>> ago. I had some Lisp knowledge already and wanted more
>> information. From what I have seen so far I can tell you:
>> I will not turn into a Lisp fan. :-)
eric-and-jane-smith wrote:
> "a book about lisp"
> Are you saying the book you bought isn't good enough to convince you to
> learn Lisp?
Either that or the book he bought is good enough to convince him not to learn
Lisp.
> And you want me to guess what book it is? Or what?
No, he doesn't want you to guess what book it is. He doesn't care whether you
know what book it is.
Wait, are you saying that you want him to tell you what book it is? Or what?
--
Lew
Lew <·····@lewscanon.com> wrote in ·················@news.albasani.net:
> Either that or the book he bought is good enough to convince him not
> to learn Lisp.
You mean bad enough. It's not likely that there's any Lisp book that tries
to convince people not to learn Lisp. So, if it's a good book, it's far
more likely to convince him to learn it. A bad book can convince him not
to learn it, in the same sense that a bad math teacher can convince
students that they don't like math.
Lew wrote:
>> Either that or the book he bought is good enough to convince him not
>> to learn Lisp.
eric-and-jane-smith wrote:
> You mean bad enough.
No, I really don't. I am in the habit of saying exactly what I mean, for the
most part, and this was one of those times. I really don't think I was at all
unclear in my statement that it would be subject to misinterpretation.
> It's not likely that there's any Lisp book that tries
> to convince people not to learn Lisp. So, if it's a good book, it's far
> more likely to convince him to learn it. A bad book can convince him not
> to learn it, in the same sense that a bad math teacher can convince
> students that they don't like math.
A good book will give an accurate picture of the language, its capabilities
and its shortcomings. Whether it's trying to convince someone not to use the
language or to use it is irrelevant; an honest assessment might well convince
someone not to use it.
I certainly have encountered many informative references for languages, pretty
much all of which were partisan to their respective topics, that convinced me
not to use those languages. No reflection on the languages, necessarily, it's
just that good information allowed me to make an informed assessment whether I
should invest time and energy in them.
--
Lew
On 13 Mai, 02:42, Lew <·····@lewscanon.com> wrote:
> Lew wrote:
> >> Either that or the book he bought is good enough to convince him not
> >> to learn Lisp.
> eric-and-jane-smith wrote:
> > You mean bad enough.
>
> No, I really don't. I am in the habit of saying exactly what I mean, for the
> most part, and this was one of those times. I really don't think I was at all
> unclear in my statement that it would be subject to misinterpretation.
>
> > It's not likely that there's any Lisp book that tries
> > to convince people not to learn Lisp. So, if it's a good book, it's far
> > more likely to convince him to learn it. A bad book can convince him not
> > to learn it, in the same sense that a bad math teacher can convince
> > students that they don't like math.
>
> A good book will give an accurate picture of the language, its capabilities
> and its shortcomings. Whether it's trying to convince someone not to use the
> language or to use it is irrelevant; an honest assessment might well convince
> someone not to use it.
You hit the spot. I want objective (neutral point of view)
information.
Why someone thinks that reading a book about Lisp or learning
it, would automatically turn me into a Lisp fan, is beyond my
comprehension (In other words: Is the pope catholic?).
BTW. I took several lectures about Lisp and AI at the university.
That way I am already familiar with car, cdr, caaadr, cons, setq,
dotted pairs, propertys, s-expressions, lambda, deffun, defmacro,
programs as data and other Lisp concepts. I just don't get
enthusiastic about this concepts because I miss other concepts
which IMHO also have some value. I will not start a discussion
about this concepts since I already know how Lisp fanatics
react:
- Either a concept is present in Lisp and therefore considered
great.
- Or a concept is missing in Lisp which renders it unnecessary
and stupid.
My answer to "How should a language look like?" is Seed7.
Seed7 is far from perfect and needs improvement at many
places, but at least some basic concepts are done in a way
I think they should be done. If you find places where Seed7
should be improved, please tell me.
> I certainly have encountered many informative references for languages, pretty
> much all of which were partisan to their respective topics, that convinced me
> not to use those languages. No reflection on the languages, necessarily, it's
> just that good information allowed me to make an informed assessment whether I
> should invest time and energy in them.
I hope you invest some time to look at Seed7. :-)
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at writes:
> which IMHO also have some value. I will not start a discussion
> about this concepts since I already know how Lisp fanatics
> react:
>
> - Either a concept is present in Lisp and therefore considered
> great.
>
> - Or a concept is missing in Lisp which renders it unnecessary
> and stupid.
Hmm, I consider myself a Lisp fan and would not want to choose between
these two statements. Maybe you should refine your simplistic world
view a little qbit?
Nicolas
On 13 Mai, 10:52, Nicolas Neuss <········@math.uni-karlsruhe.de>
wrote:
> ·············@gmx.at writes:
> > which IMHO also have some value. I will not start a discussion
> > about this concepts since I already know how Lisp fanatics
> > react:
>
> > - Either a concept is present in Lisp and therefore considered
> > great.
>
> > - Or a concept is missing in Lisp which renders it unnecessary
> > and stupid.
>
> Hmm, I consider myself a Lisp fan and would not want to choose between
> these two statements. Maybe you should refine your simplistic world
> view a little qbit?
As I already said: This is not my simplisic world view.
Proof: Just tell me about great language features that are
missing in Lisp.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at writes:
> On 13 Mai, 10:52, Nicolas Neuss <········@math.uni-karlsruhe.de>
> wrote:
>> ·············@gmx.at writes:
>> > which IMHO also have some value. I will not start a discussion
>> > about this concepts since I already know how Lisp fanatics
>> > react:
>>
>> > - Either a concept is present in Lisp and therefore considered
>> > � great.
>>
>> > - Or a concept is missing in Lisp which renders it unnecessary
>> > � and stupid.
>>
>> Hmm, I consider myself a Lisp fan and would not want to choose between
>> these two statements. �Maybe you should refine your simplistic world
>> view a little qbit?
>
> As I already said: This is not my simplisic world view.
> Proof: Just tell me about great language features that are
> missing in Lisp.
Easy: As every Lisp fan knows there are important things like
multitthreading, uniform dictionary access, etc, that are not portable
across Common Lisp implementations. And there are only few libraries
compared with, say, Python.
So your problem with the too simplistic world view apparently remains.
Nicolas
On 13 May, 12:16, Nicolas Neuss <········@math.uni-karlsruhe.de>
wrote:
> ·············@gmx.at writes:
> > As I already said: This is not my simplisic world view.
> > Proof: Just tell me about great language features that are
> > missing in Lisp.
>
> Easy: As every Lisp fan knows there are important things like
> multitthreading, uniform dictionary access,
What's "uniform dictionary access" ?
--
Who's your mama?
Spiros Bousbouras <······@gmail.com> writes:
> On 13 May, 12:16, Nicolas Neuss <········@math.uni-karlsruhe.de>
> wrote:
>> ·············@gmx.at writes:
>> > As I already said: This is not my simplisic world view.
>> > Proof: Just tell me about great language features that are
>> > missing in Lisp.
>>
>> Easy: As every Lisp fan knows there are important things like
>> multitthreading, uniform dictionary access,
>
> What's "uniform dictionary access" ?
Sorry for expressing myself not very clear. I mean something like a
uniform interface for accessing tables/dictionaries (e.g. association
lists, hash-tables, vectors (mapping indices to elements), binary trees).
More precisely, I would like to have Christophe Rhodes' extensible
sequences or Scott Burson's FSet generally available.
Nicolas
Nicolas Neuss <········@math.uni-karlsruhe.de> writes:
> Spiros Bousbouras <······@gmail.com> writes:
>
>> On 13 May, 12:16, Nicolas Neuss <········@math.uni-karlsruhe.de>
>> wrote:
>>> ·············@gmx.at writes:
>>> > As I already said: This is not my simplisic world view.
>>> > Proof: Just tell me about great language features that are
>>> > missing in Lisp.
>>>
>>> Easy: As every Lisp fan knows there are important things like
>>> multitthreading, uniform dictionary access,
>>
>> What's "uniform dictionary access" ?
>
> Sorry for expressing myself not very clear. I mean something like a
> uniform interface for accessing tables/dictionaries (e.g. association
> lists, hash-tables, vectors (mapping indices to elements), binary trees).
> More precisely, I would like to have Christophe Rhodes' extensible
> sequences or Scott Burson's FSet generally available.
So you are unable to gather together the most trivial lisp code?
(defgeneric gget (dictionary key)
(:method ((dictionary hash-table) key) (gethash key dictionary))
(:method ((dictionary null) key) (values nil nil))
(:method ((dictionary cons) key)
(if (every (function consp) dictionary)
;; assume an a-list
(let ((pair (assoc key dictionary)))
(if pair
(values (cdr pair) t)
(values nil nil)))
;; assume a p-list
(getf dictionary key)))
(:method ((dictionary vector) (key integer)) (aref dictionary key))
(:documentation "Please add methods for your own containers!"))
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> So you are unable to gather together the most trivial lisp code?
No Pascal, I'm not. And I have precisely such code (under the name
DIC-REF) in my library, of course. Nevertheless, I find it a nuisance that
standard looping/iterating/referencing constructs (esp. LOOP, map, etc.)
like loop, map, etc. are not general and extensible. I know that I can
provide that myself, or use libraries like the extensible ITERATE (for the
record: I don't like this library, especially I do not like its way to use
up symbols which I want to use myself).
Nicolas
Nicolas Neuss <········@math.uni-karlsruhe.de> writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>
>> So you are unable to gather together the most trivial lisp code?
>
> No Pascal, I'm not. And I have precisely such code (under the name
> DIC-REF) in my library, of course. Nevertheless, I find it a nuisance that
> standard looping/iterating/referencing constructs (esp. LOOP, map, etc.)
> like loop, map, etc. are not general and extensible. I know that I can
> provide that myself, or use libraries like the extensible ITERATE (for the
> record: I don't like this library, especially I do not like its way to use
> up symbols which I want to use myself).
Perhaps this is the reason no such common looping construct has made
its way to the standard: nobody could find one that almost nobody
didn't like.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> Nicolas Neuss <········@math.uni-karlsruhe.de> writes:
>
>> [...] I know that I can
>> provide that myself, or use libraries like the extensible ITERATE (for the
>> record: I don't like this library, especially I do not like its way to use
>> up symbols which I want to use myself).
>
> Perhaps this is the reason no such common looping construct has made
> its way to the standard: nobody could find one that almost nobody
> didn't like.
:-) Yes, I know I'm moaning at a level of flexibility and choice where many
other programming languages can only dream of. (And also ITERATE is a
reasonable choice which I could probably adapt easily such that it does
only locally use up symbols like COLLECT, etc. I think I have even seen
such a modified ITERATE mentioned somewhere...).
Nicolas
On 13 Mai, 13:16, Nicolas Neuss <········@math.uni-karlsruhe.de>
wrote:
> ·············@gmx.at writes:
> > On 13 Mai, 10:52, Nicolas Neuss <········@math.uni-karlsruhe.de>
> > wrote:
> >> ·············@gmx.at writes:
> >> > which IMHO also have some value. I will not start a discussion
> >> > about this concepts since I already know how Lisp fanatics
> >> > react:
>
> >> > - Either a concept is present in Lisp and therefore considered
> >> > great.
>
> >> > - Or a concept is missing in Lisp which renders it unnecessary
> >> > and stupid.
>
> >> Hmm, I consider myself a Lisp fan and would not want to choose between
> >> these two statements. Maybe you should refine your simplistic world
> >> view a little qbit?
>
> > As I already said: This is not my simplisic world view.
> > Proof: Just tell me about great language features that are
> > missing in Lisp.
>
> Easy: As every Lisp fan knows there are important things like
> multitthreading, uniform dictionary access, etc, that are not portable
> across Common Lisp implementations. And there are only few libraries
> compared with, say, Python.
For which areas are libraries missing?
What about static type checking and other concepts present
in competing programming languages?
> So your problem with the too simplistic world view apparently remains.
No, I have no problem with people who have a simplistic
world view. :-)
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
On 13 May, 05:26, ·············@gmx.at wrote:
> On 13 Mai, 10:52, Nicolas Neuss <········@math.uni-karlsruhe.de>
> wrote:
[...]
> > Hmm, I consider myself a Lisp fan and would not want to choose between
> > these two statements. Maybe you should refine your simplistic world
> > view a little qbit?
> As I already said: This is not my simplisic world view.
> Proof: Just tell me about great language features that are
> missing in Lisp.
This is a really strange request, because language features aren't
arbitrarily composable. In a lot of circumstances adding one feature
means you've got to get rid of, or compromise, another feature. C-
style pointers strike me as the best example of this kind of feature;
they're a great feature for C to have, but you don't want them in a
lot of other languages because the make it so easy for you to light
your own hair on fire[1]. Common Lisp relegates them to the realm of
non-standard extensions, which is (IMO) as it should be.
There are any number of other features like that. Ease of
implementation is another feature that can be tremendously valuable,
and is one that Common Lisp doesn't pay a whole lot of attention to.
Cheers, Pillsy
[1] Or, in the case of Fortran, because it makes some important
optimizations impossible.
On Fri, 15 May 2009 06:42:09 -0700 (PDT), Pillsy <·········@gmail.com>
wrote:
>On 13 May, 05:26, ·············@gmx.at wrote:
>> On 13 Mai, 10:52, Nicolas Neuss <········@math.uni-karlsruhe.de>
>> wrote:
>[...]
>> > Hmm, I consider myself a Lisp fan and would not want to choose between
>> > these two statements. �Maybe you should refine your simplistic world
>> > view a little qbit?
>
>> As I already said: This is not my simplisic world view.
>> Proof: Just tell me about great language features that are
>> missing in Lisp.
>
>This is a really strange request, because language features aren't
>arbitrarily composable. In a lot of circumstances adding one feature
>means you've got to get rid of, or compromise, another feature. C-
>style pointers strike me as the best example of this kind of feature;
>they're a great feature for C to have, but you don't want them in a
>lot of other languages because the make it so easy for you to light
>your own hair on fire[1]. Common Lisp relegates them to the realm of
>non-standard extensions, which is (IMO) as it should be.
The problem with C's pointers is they went too far in allowing
arithmetic on them. There isn't any need for that at the source
level. Anything you can do with a C pointer you can also do more
safely with a C++ reference and indexing.
[Not that C++'s references can't also be abused - they could be made
safer. I'm just limiting the examples to the C family.]
>There are any number of other features like that. Ease of
>implementation is another feature that can be tremendously valuable,
>and is one that Common Lisp doesn't pay a whole lot of attention to.
>
>Cheers, Pillsy
>
>[1] Or, in the case of Fortran, because it makes some important
>optimizations impossible.
Source level pointer arithmetic makes those same optimizations
impossible in C.
George
On 15 May, 19:47, George Neuner <········@comcast.net> wrote:
> On Fri, 15 May 2009 06:42:09 -0700 (PDT), Pillsy <·········@gmail.com>
> wrote:
>
> >[1] Or, in the case of Fortran, because it makes some important
> >optimizations impossible.
>
> Source level pointer arithmetic makes those same optimizations
> impossible in C.
Could you give an example of an optimization which can be done
in Fortran but not in C because of pointer arithmetic?
Spiros Bousbouras wrote:
>> Source level pointer arithmetic makes those same optimizations
>> impossible in C.
>
> Could you give an example of an optimization which can be done
> in Fortran but not in C because of pointer arithmetic?
If Fortran can't point, then if it copies a stored value to a register, does
other things, and comes back to the register, it knows the register's value is
still equal to the storage location value. The routine can use the register,
efficiently.
Because C++ can point, if such a routine "does other things", one of those
things might involve pointing to that storage location and operating on it. The
register copy might become dirty. So the compiler has the odious choice to
either recopy the register, or detect where the pointer was pointing. Aliasing
values with pointers (or references) screws up all kinds of optimizations.
However, that's not really "pointer arithmetic", which means using pointers like
arrays. Maybe there's another effect...
--
Phlip
On 15 May, 20:43, Phlip <·········@gmail.com> wrote:
> Spiros Bousbouras wrote:
> >> Source level pointer arithmetic makes those same optimizations
> >> impossible in C.
>
> > Could you give an example of an optimization which can be done
> > in Fortran but not in C because of pointer arithmetic?
>
> If Fortran can't point, then if it copies a stored value to a register, does
> other things, and comes back to the register, it knows the register's value is
> still equal to the storage location value. The routine can use the register,
> efficiently.
>
> Because C++ can point, if such a routine "does other things", one of those
> things might involve pointing to that storage location and operating on it. The
> register copy might become dirty. So the compiler has the odious choice to
> either recopy the register, or detect where the pointer was pointing. Aliasing
> values with pointers (or references) screws up all kinds of optimizations.
So basically the problem is that in C you may have more than 1
pointers pointing to the same object and since the compiler
in general does not know if you do then it cannot do certain
optimizations, yes? C99 solves this problem with restricted pointers.
> However, that's not really "pointer arithmetic", which means using pointers like
> arrays. Maybe there's another effect...
--
Who's your mama?
On Fri, 15 May 2009 13:12:33 -0700 (PDT), Spiros Bousbouras
<······@gmail.com> wrote:
>On 15 May, 20:43, Phlip <·········@gmail.com> wrote:
>> Spiros Bousbouras wrote:
>> >> Source level pointer arithmetic makes those same optimizations
>> >> impossible in C.
>>
>> > Could you give an example of an optimization which can be done
>> > in Fortran but not in C because of pointer arithmetic?
>>
>> If Fortran can't point, then if it copies a stored value to a register, does
>> other things, and comes back to the register, it knows the register's value is
>> still equal to the storage location value. The routine can use the register,
>> efficiently.
>>
>> Because C++ can point, if such a routine "does other things", one of those
>> things might involve pointing to that storage location and operating on it. The
>> register copy might become dirty. So the compiler has the odious choice to
>> either recopy the register, or detect where the pointer was pointing. Aliasing
>> values with pointers (or references) screws up all kinds of optimizations.
>
>So basically the problem is that in C you may have more than 1
>pointers pointing to the same object and since the compiler
>in general does not know if you do then it cannot do certain
>optimizations, yes?
Fortran by default makes aliasing difficult. Because the only way to
refer to a value is by name or name+index, the compiler can catch
almost always catch aliasing. The only way to create an object alias
in Fortran is by somehow passing parts of the same array twice to a
subroutine and the compiler will complain about that.
In C, you can take any pointer, add or subtract an arbitrary value and
create an alias to an unrelated object of the same type. By casting
you can turn it into a pointer to any object whatsoever. You can do
this in any context - not just in argument passing - and the unrelated
object may not even be visible to the compiler in the current context.
>C99 solves this problem with restricted pointers.
Not exactly. The "restrict" keyword is a promise to the compiler that
no pointer aliases exist. The compiler typically can't verify that
beyond the local scope, so if it is not true then bad things will
happen.
>> However, that's not really "pointer arithmetic", which means using pointers like
>> arrays. Maybe there's another effect...
Pointers in C *are* synonymous with arrays by definition. Pointer
arithmetic is source level manipulation of an array's base address in
lieu of explicit indexing. It's not something that's necessary at the
source level.
George
George Neuner said:
<snip>
> In C, you can take any pointer, add or subtract an arbitrary value
> and create an alias to an unrelated object of the same type.
Similarly, in basketball you can catch the ball, run to the end, and
use a stepladder to climb up and deposit the ball through the ring.
<snip>
> Pointers in C *are* synonymous with arrays by definition.
Not so. Proof:
#include <stdio.h>
int main(void)
{
char array[] = "Hello, world";
char *pointer = array;
printf("Array is %d bytes wide\n", (int)sizeof array);
printf("Pointer is %d bytes wide\n", (int)sizeof pointer);
return 0;
}
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield wrote:
> George Neuner said:
>> In C, you can take any pointer, add or subtract an arbitrary value
>> and create an alias to an unrelated object of the same type.
> Similarly, in basketball you can catch the ball, run to the end, and
> use a stepladder to climb up and deposit the ball through the ring.
Irrelevant. In C, the act of re-pointing a pointer anywhere is undefined unless
it points to an object of its type, or one-off-the-end of an array of its type.
The undefined behavior probably includes mistakes with aliasing, so this rule
probably supports optimizing.
>> Pointers in C *are* synonymous with arrays by definition.
>
> Not so. Proof:
>
> #include <stdio.h>
>
> int main(void)
> {
> char array[] = "Hello, world";
> char *pointer = array;
> printf("Array is %d bytes wide\n", (int)sizeof array);
> printf("Pointer is %d bytes wide\n", (int)sizeof pointer);
> return 0;
> }
Irrelevant. The only problem with George's statement is it was not specific
enough. Pointer arithmetic, by the Standard's actual definition, is identical to
array indexing, because the latter so a[x] is the same as *(a + x). That's the
rule George misremembered.
--
Phlip
Phlip said:
> Richard Heathfield wrote:
>
>> George Neuner said:
>
>>> In C, you can take any pointer, add or subtract an arbitrary
>>> value and create an alias to an unrelated object of the same
>>> type.
>
>> Similarly, in basketball you can catch the ball, run to the end,
>> and use a stepladder to climb up and deposit the ball through the
>> ring.
>
> Irrelevant.
No, it's entirely relevant. The point being that you can do anything
you like if you're prepared to break the rules.
> In C, the act of re-pointing a pointer anywhere is
> undefined unless it points to an object of its type, or
> one-off-the-end of an array of its type.
Yes - the rules say you can only do pointer addition on related
objects. If you ignore the rules, the consequences are your
problem.
> The undefined behavior probably includes mistakes with aliasing,
> so this rule probably supports optimizing.
>
>>> Pointers in C *are* synonymous with arrays by definition.
>>
>> Not so. Proof:
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> char array[] = "Hello, world";
>> char *pointer = array;
>> printf("Array is %d bytes wide\n", (int)sizeof array);
>> printf("Pointer is %d bytes wide\n", (int)sizeof pointer);
>> return 0;
>> }
>
> Irrelevant.
On the contrary, it demonstrates that George's statement was
incorrect.
> The only problem with George's statement is it was not
> specific enough.
And was therefore incorrect.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Sat, 16 May 2009 00:25:42 +0000, Richard Heathfield
<···@see.sig.invalid> wrote:
>George Neuner said:
>
><snip>
>
>> In C, you can take any pointer, add or subtract an arbitrary value
>> and create an alias to an unrelated object of the same type.
>
>Similarly, in basketball you can catch the ball, run to the end, and
>use a stepladder to climb up and deposit the ball through the ring.
>
><snip>
>
>> Pointers in C *are* synonymous with arrays by definition.
>
>Not so. Proof:
>
>#include <stdio.h>
>
>int main(void)
>{
> char array[] = "Hello, world";
> char *pointer = array;
> printf("Array is %d bytes wide\n", (int)sizeof array);
> printf("Pointer is %d bytes wide\n", (int)sizeof pointer);
> return 0;
>}
>
><snip>
In C all pointers denote an array - possibly of 1 element.
A pointer to an array is a synonym for it. That doesn't mean the
pointer and the array are the same thing - just as synonyms are
different words that mean the same thing.
And to Phlip: I am not misremembering. Not only is pointer arithmetic
identical to array indexing, but the array name is, by definition, a
pointer to the array. The array name and any other pointer to the
array are interchangeable in both array indexing and in pointer
arithmetic expressions.
George
George Neuner wrote:
> And to Phlip: I am not misremembering. Not only is pointer arithmetic
> identical to array indexing, but the array name is, by definition, a
> pointer to the array.
No it isn't. You can use sizeof array, and get the length in bytes, not the
width of a pointer.
And you can overload a template with array[length], where length is a constant,
and you will get a different template instantiation for each combination of
array type and length.
Arrays are first-class objects in C++.
> The array name and any other pointer to the
> array are interchangeable in both array indexing and in pointer
> arithmetic expressions.
Array names simply "decay" into addresses (not pointers) in a variety of
convenient (and otherwise) situations.
--
Phlip
George Neuner said:
<snip>
> In C all pointers denote an array - possibly of 1 element.
Not so. Proof: null pointers are pointers, and by definition do not
denote any object.
> A pointer to an array is a synonym for it.
Not so. I don't need to prove this, since it's self-evidently false
(a pointer to an array cannot be a synonym for an array, because it
has a different type - for example, char array[42]; char *p =
&array; requires a diagnostic message). If you meant that a pointer
to *the first element of* an array is a synonym for the array, that
is true only in value contexts. It's not true for sizeof, for
example.
> That doesn't mean the
> pointer and the array are the same thing - just as synonyms are
> different words that mean the same thing.
>
> And to Phlip: I am not misremembering. Not only is pointer
> arithmetic identical to array indexing, but the array name is, by
> definition, a pointer to the array.
Close, but not quite true. If I assume you actually mean "a pointer
to the first element of the array", you're closer, but still not
quite there.
> The array name and any other pointer to the
[first element of the]
> array are interchangeable in both array indexing and in pointer
> arithmetic expressions.
Yes.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield <···@see.sig.invalid> writes:
> George Neuner said:
>
> <snip>
>
>> In C all pointers denote an array - possibly of 1 element.
>
> Not so. Proof: null pointers are pointers, and by definition do not
> denote any object.
Also function pointers.
>> A pointer to an array is a synonym for it.
>
> Not so. I don't need to prove this, since it's self-evidently false
> (a pointer to an array cannot be a synonym for an array, because it
> has a different type - for example, char array[42]; char *p =
> &array; requires a diagnostic message). If you meant that a pointer
> to *the first element of* an array is a synonym for the array, that
> is true only in value contexts. It's not true for sizeof, for
> example.
Also, some pointers to the first element *don't* behave in the same
way. For example, given
int ar[2], *ip = ar;
void *vp = ar;
ip and ar behave the same as far as indexing are concerned but vp does
not. (I know you know this -- I'm just rounding out your answer.)
>> That doesn't mean the
>> pointer and the array are the same thing - just as synonyms are
>> different words that mean the same thing.
>>
>> And to Phlip: I am not misremembering. Not only is pointer
>> arithmetic identical to array indexing, but the array name is, by
>> definition, a pointer to the array.
>
> Close, but not quite true. If I assume you actually mean "a pointer
> to the first element of the array", you're closer, but still not
> quite there.
>
>> The array name and any other pointer to the
>
> [first element of the]
>
>> array are interchangeable in both array indexing and in pointer
>> arithmetic expressions.
>
> Yes.
I disagree with the "any other pointer" part, mainly because of the
example above with void * but also because other types of pointer (in
particular char-based pointers) won't be interchangeable with the
name of the array.
Of course it is this fact that backs up the original complaint about
C. Because the compiler can't tell that a pointer (even one of an
apparently different type -- char * or void *) does not alias
something of interest its ability to optimise can be seriously
hampered.
--
Ben.
On 16 May, 00:59, George Neuner <········@comcast.net> wrote:
> On Fri, 15 May 2009 13:12:33 -0700 (PDT), Spiros Bousbouras
> <······@gmail.com> wrote:
>
> >So basically the problem is that in C you may have more than 1
> >pointers pointing to the same object and since the compiler
> >in general does not know if you do then it cannot do certain
> >optimizations, yes?
>
S N I P
>
> >C99 solves this problem with restricted pointers.
>
> Not exactly. The "restrict" keyword is a promise to the compiler that
> no pointer aliases exist. The compiler typically can't verify that
> beyond the local scope, so if it is not true then bad things will
> happen.
I agree about the "bad things" part but the problem referred to
is optimisation. Restricted pointers address this adequately as
far as I know although they do create an additional possibility
for undefined behavior as you pointed out.
[ Crossposting on comp.lang.c and comp.lang.fortran for further
comments ]
Only kidding.
George Neuner wrote:
...
> The problem with C's pointers is they went too far in allowing
> arithmetic on them. There isn't any need for that at the source
> level. Anything you can do with a C pointer you can also do more
> safely with a C++ reference and indexing.
...
How would you implement malloc, sbrk, or operating system internal
memory management using only C++ references and indexing?
Patricia
On Fri, 15 May 2009 11:58:56 -0700, Patricia Shanahan <····@acm.org>
wrote:
>George Neuner wrote:
>...
>> The problem with C's pointers is they went too far in allowing
>> arithmetic on them. There isn't any need for that at the source
>> level. Anything you can do with a C pointer you can also do more
>> safely with a C++ reference and indexing.
>...
>
>How would you implement malloc, sbrk, or operating system internal
>memory management using only C++ references and indexing?
>
>Patricia
Are you serious?
The allocator subdivides an array (the heap) by numeric indices and
returns to the application a fixed pointer (ie. a reference) to the
new subdivision. All that is needed is the ability to index an array
and create a new language level pointer/reference by taking the
address of a particular array element.
This works at all levels - OS, library allocator, etc. The OS just
returns an absolute numeric index into its (possibly virtual) memory
array. The local allocator returns a new block by indexing from the
heap base and creating a new pointer/reference.
WRT the particulars of sbrk, if the call is successful, the local
allocator adjusts the top of its array by adding the size of the sbrk
request (sbrk can return memory to the OS as well).
Turning back to C++, references can be set to any arbitrary value (by
casting from an integer value) and are type castable (ible?) to
references of a different type. Except for arithmetic, their
semantics are nearly identical to pointers so there are no type
problems with using references.
Try it for yourself. The ability to perform arithmetic on pointers is
not needed.
George
On 15 May, 19:47, George Neuner <········@comcast.net> wrote:
<snip>
> The problem with C's pointers is they went too far in allowing
> arithmetic on them. There isn't any need for that at the source
> level.
it can be a handy thing to have
> Anything you can do with a C pointer you can also do more
> safely with a C++ reference and indexing.
unsigned char *io_port = 0x60001234;
/* reset the laser cannon */
*io_port = 0x10;
*io_port + 1 = 0x55;
Now you could do this with indexing, but it is equally dangerous.
Sometimes you *really* need to stuff bits into arbitary memory
locations and however you do that it's going to be dangerous.
io_port[1] = 0x55;
poke (io_port, 1, 0x55);
<snip>
--
Nick Keighley
["Followup-To:" header set to comp.lang.lisp.]
On 2009-05-15, Pillsy <·········@gmail.com> wrote:
> On 13 May, 05:26, ·············@gmx.at wrote:
>> On 13 Mai, 10:52, Nicolas Neuss <········@math.uni-karlsruhe.de>
>> wrote:
> [...]
>> > Hmm, I consider myself a Lisp fan and would not want to choose between
>> > these two statements. Maybe you should refine your simplistic world
>> > view a little qbit?
>
>> As I already said: This is not my simplisic world view.
>> Proof: Just tell me about great language features that are
>> missing in Lisp.
>
> This is a really strange request, because language features aren't
> arbitrarily composable. In a lot of circumstances adding one feature
> means you've got to get rid of, or compromise, another feature. C-
> style pointers strike me as the best example of this kind of feature;
> they're a great feature for C to have, but you don't want them in a
> lot of other languages because the make it so easy for you to light
> your own hair on fire[1]. Common Lisp relegates them to the realm of
> non-standard extensions, which is (IMO) as it should be.
Actually, you can make C-like pointers in Lisp if you want.
http://paste.lisp.org/display/71952
You can use (ref <place>) to take the ``address'' of some expression
that refers to a place, and (deref <r>) to map such a reference
to an an expression that designates that place. The reference
is a first class value, and its existence prevents the
referenced object from disappearing; i.e. the ``pointer''
can't suddenly go bad.
I didn't implement pointer arithmetic here, because it didn't consider that a
requirement. That would be doable over vectors and arrays, and a special-case
representation of references for this situation.
The C feature of using offsetof to displace pointers within a struct would, of
course, not map nicely to Lisp objects or structs.
On Wed, 13 May 2009 00:55:30 -0700, thomas.mertes wrote:
> data and other Lisp concepts. I just don't get enthusiastic about this
> concepts because I miss other concepts which IMHO also have some value.
> I will not start a discussion about this concepts since I already know
Well, then your statement is pretty vacuous, it amounts to "I don't
like it, but I am not telling you why because then you would reason
with me."
> I hope you invest some time to look at Seed7. :-)
I did, and I can't say I see anything special about it that would make
me even consider it, I can't see any novel features in it. Also, the
claim that it is extensible is pretty empty, it seems no more
extensible than most contemporary languages (and of course it is way
less extensible than Lisp). Designing another Pascal variant in the
21th century is unnecessary. Also, listing "user defined statements
and operators" as a feature sounds like advertising you car "with
wheels included".
Tamas
On 13 Mai, 13:06, Tamas K Papp <······@gmail.com> wrote:
> On Wed, 13 May 2009 00:55:30 -0700, thomas.mertes wrote:
> > data and other Lisp concepts. I just don't get enthusiastic about this
> > concepts because I miss other concepts which IMHO also have some value.
> > I will not start a discussion about this concepts since I already know
>
> Well, then your statement is pretty vacuous, ...
http://seed7.sourceforge.net/faq.htm#lisp_comparison
Static type checking is not new, but it has some vantages
ignored by fans of dynamic typing:
http://seed7.sourceforge.net/faq.htm#static_type_checking
http://seed7.sourceforge.net/faq.htm#development_speed_and_type_checking
> > I hope you invest some time to look at Seed7. :-)
>
> I can't see any novel features in it.
Well, it is probably impossible to get any positive message
from a typical Lisp enthusiast, but there are some features.
What about the possibility to define the syntax of constructs:
http://seed7.sourceforge.net/manual/syntax.htm
> Designing another Pascal variant ...
Just because it looks like a Wirth language does not make
one. The inner workings are totally different to Pascal.
AFAIK Pascal does not have a OO system with multiple
dispatch
file:///M:/seed7_5/htdocs/manual/objects.htm
What about the (theoretic) possibility to boot a different
language:
http://seed7.sourceforge.net/faq.htm#boot_a_language
> Also, listing "user defined statements
> and operators" as a feature sounds like advertising you car "with
> wheels included".
I am talking about defining statements/operators syntactically
and semantically. I know that you think the + in (+ 1 2) is an
operator while others would see it as function. I am talking
about the infix operator + in 1 + 2. I would really be amazed
when a Lisp fan would admit that syntax matters and that
there is a difference (+ 1 2) between and 1 + 2 .
From my point of view there is a difference between round
and square wheels although both are made from rubber.
And stating that your favourite car company added the
weels already 40 years ago does not make them round.
Sorry for being that harsh, but I have been attacked by Lisp
fans to often. Generally such sarcastic flamewars lead to
nowhere. Users of many different languages should talk
about pros and cons of various features and how they are
done in this languages. Nobody should question the
intelligence or attack others just for having a different
opinion.
BTW: It is my opinion that syntax matters and that a
static type system and many other things make sense.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
On Wed, 13 May 2009 08:44:37 -0700, thomas.mertes wrote:
> On 13 Mai, 13:06, Tamas K Papp <······@gmail.com> wrote:
>> I can't see any novel features in it.
>
> Well, it is probably impossible to get any positive message from a
> typical Lisp enthusiast, but there are some features. What about the
> possibility to define the syntax of constructs:
>
> http://seed7.sourceforge.net/manual/syntax.htm
I find macros much more powerful, thanks.
> Just because it looks like a Wirth language does not make one. The inner
> workings are totally different to Pascal. AFAIK Pascal does not have a
> OO system with multiple dispatch
>
> file:///M:/seed7_5/htdocs/manual/objects.htm
Again, this is not a feature that I am missing in Lisp.
> What about the (theoretic) possibility to boot a different language:
>
> http://seed7.sourceforge.net/faq.htm#boot_a_language
DSLs are used routinely in Lisp.
> I am talking about defining statements/operators syntactically and
> semantically. I know that you think the + in (+ 1 2) is an operator
> while others would see it as function. I am talking about the infix
> operator + in 1 + 2. I would really be amazed when a Lisp fan would
> admit that syntax matters and that there is a difference (+ 1 2) between
> and 1 + 2 .
By switching to infix, you introduce the distinction, and later you
try to fix it. I would rather not create the problem in the first
place.
> Sorry for being that harsh, but I have been attacked by Lisp fans to
> often. Generally such sarcastic flamewars lead to nowhere. Users of
You are not being harsh, and you are not being attacked. Criticism
should not be taken as an attack, and I will judge your responses by
their content, not their tone.
> features and how they are done in this languages. Nobody should question
> the intelligence or attack others just for having a different opinion.
Again, there is no need to take things personally, please do not try
to claim that I am questioning your intelligence. I was just
questioning the usefulness of Seed7 from my point of view, which is an
entirely legitimate thing to do.
Tamas
On 13 Mai, 18:36, Tamas K Papp <······@gmail.com> wrote:
> On Wed, 13 May 2009 08:44:37 -0700, thomas.mertes wrote:
> > On 13 Mai, 13:06, Tamas K Papp <······@gmail.com> wrote:
> >> I can't see any novel features in it.
>
> > Well, it is probably impossible to get any positive message from a
> > typical Lisp enthusiast, but there are some features. What about the
> > possibility to define the syntax of constructs:
>
> >http://seed7.sourceforge.net/manual/syntax.htm
>
> I find macros much more powerful, thanks.
IMHO The logic of macros and syntax descriptions do only overlap in
part. Assume that the following expression is not a list but a
sequence of characters in a file:
a-b**c**d*e-f*g
Using the usual mathematic precedence rules gives the following
order of evaluation:
((a - ((b ** (c ** d)) * e)) - (f * g))
This order of evaluation is described with the following syntax
rules:
syntax expr: .(). ** .() is <- 4;
syntax expr: .(). * .() is -> 6;
syntax expr: .(). + .() is -> 7;
With just this syntax rules the expressions can be read from the
file. Sure some macros could do this as well, but that is not the
point. Most languages are turing equivalent and therefore they can
do the same things. The point is that some simple syntax rules are
able to turn a sequence of symbols into expressions and
subexpressions.
> > Just because it looks like a Wirth language does not make one. The inner
> > workings are totally different to Pascal. AFAIK Pascal does not have a
> > OO system with multiple dispatch
>
> > file:///M:/seed7_5/htdocs/manual/objects.htm
This should have been
http://seed7.sourceforge.net/manual/objects.htm
instead.
> Again, this is not a feature that I am missing in Lisp.
Interesting, you came to a conclusion although the link was not ok.
I thought that OO is present in Lisp. Maybe this is the reason you
don't miss it. Or maybe your answer was just too quick.
> > What about the (theoretic) possibility to boot a different language:
>
> >http://seed7.sourceforge.net/faq.htm#boot_a_language
>
> DSLs are used routinely in Lisp.
Lisp DSLs probably still use lists. This is not necessary when the
syntax can be changed. Please refrain from saying "You don't need
it" since a customer might have a different idea of what he needs.
> > I am talking about defining statements/operators syntactically and
> > semantically. I know that you think the + in (+ 1 2) is an operator
> > while others would see it as function. I am talking about the infix
> > operator + in 1 + 2. I would really be amazed when a Lisp fan would
> > admit that syntax matters and that there is a difference (+ 1 2) between
> > and 1 + 2 .
>
> By switching to infix, you introduce the distinction, and later you
> try to fix it.
Where you get the impression that I try to fix it? Infix is infix
and I don't need to fix it afterwards.
> I would rather not create the problem in the first
> place.
I see no problem with infix. You probably have other languages in
mind which use a relation between infix operator and corresponding
function. In Seed7 there is no corresponding function and
consequently no problem with infix operators.
> > Sorry for being that harsh, but I have been attacked by Lisp fans to
> > often. Generally such sarcastic flamewars lead to nowhere. Users of
>
> You are not being harsh, and you are not being attacked. Criticism
> should not be taken as an attack, and I will judge your responses by
> their content, not their tone.
Ok.
> > features and how they are done in this languages. Nobody should question
> > the intelligence or attack others just for having a different opinion.
>
> Again, there is no need to take things personally, please do not try
> to claim that I am questioning your intelligence. I was just
> questioning the usefulness of Seed7 from my point of view, which is an
> entirely legitimate thing to do.
I have no problem when people prefer other languages over Seed7. I
just don't like it when people shout out lound things that are not
really correct. Often wrong assumptions lead to the impression that
Seed7 contains nothing new. Seed7 is designed to imitate constructs
of other languages. It imitates statements of the Pascal/Modula/Ada
world, but the statements could also be totally different. So just
because it can look very conservative does not imply that it is a
form of Pascal. Seed7 is also designed to allow a look behind the
fence. BTW: How do the definitions of special operators like QUOTE,
IF and PROGN look like. Are they defined as macros (since they do
not evaluate all parameters they are probably not functions). In
Seed7 all predefined statements are (at least to some degree)
defined in the language. For a language from the Algol family this
is uncommon. When your goal is to immitate language constructs from
other languages syntax does matter. Seed7 was capable to emulate
the syntax and the semantic of a loop with middle exit which was
suggested by someone planing an Eiffel successor language. Sure
such things could be done with macros, preprocessors or other
technics in any language. In Seed7 this special technics were just
not necessary. The syntax is defined with a syntax statement and
the semantic is defined as function. There are other features which
are done in a different way. Mandatory static type checking and
overloading of functions are done in a way which is different to the
competition. E.g. Overloading resolution is done bottom up which
makes it easier to read and to compile programs. A reaction like
"I don't need it" to such things is just oversimplification.
It is human to just search for a reason to reject something new.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at wrote in
·········································@s28g2000vbp.googlegroups.com:
> when a Lisp fan would admit that syntax matters and that
> there is a difference (+ 1 2) between and 1 + 2 .
A typical big Lisp program partly writes itself, so the programmer
doesn't have to do as much work. In some cases more than 90% of the
program can be written by itself. (+ 1 2) is easier for it to understand
and work with, so the programmer doesn't have to do as much work on the
parts of the program that write other parts of the program.
Most Lispers don't really claim Lisp is necessarily the most
mathematically elegant or beautiful. Only that it saves huge amounts of
work, lets the programmer tackle much more ambitious projects, and yields
very high quality code at much lower cost than with other programming
languages.
Lisp has ways to use expressions such as (1 + 2), but, most experienced
Lisp programmers prefer (+ 1 2) because its advantages outweigh its
disadvantages overall, even if it seems worse at first glance.
When reading a Lisp book, you should keep in mind that a lot of Lisp
books are written by people who are in the process of learning Lisp
themselves, and were inspired to write a book about it because they found
an interesting corner of the language that made them think they had
discovered its key advantage.
Some of the best Lisp books are written by very creative people, who are
never satisfied with anything, which is what makes them creative.
Creative people tend to complain about things, even if the things they
complain about are far better than anything else they ever encountered.
Because, they compare the reality with an ideal, which they hope to
accomplish in the future, rather than comparing it with something else
that already exists.
·············@gmx.at writes:
> Static type checking is not new, but it has some vantages
> ignored by fans of dynamic typing:
Hey, guy-with-the-simple-world-view, I'm a fan of dynamic typing and
additionally I'm very happy that my usual Lisp compiler (SBCL) does quite a
lot of static type checks at compile time. I would appreciate it if it did
even more.
> I am talking about defining statements/operators syntactically
> and semantically. I know that you think the + in (+ 1 2) is an
> operator while others would see it as function.
Why do you think that? + is an ordinary function.
> I am talking about the infix operator + in 1 + 2. I would really be
> amazed when a Lisp fan would admit that syntax matters and that there is
> a difference (+ 1 2) between and 1 + 2 .
Oh, you guy-with-the-simple-world-view, as I said I'm a fan of Lisp.
Nevertheless, I admit that syntax matters and that there is a difference (+
1 2) between and 1+2. I even routinely use the infix package in Common
Lisp for more complicated arithmetic expressions, where I can write
CL-USER> (require :infix)
CL-USER> #I(2+exp(2*pi))
537.4916555247646
> [...] Nobody should question the intelligence or attack others just for
> having a different opinion.
That's the right philosophy. But you should follow it yourself, such that
it becomes easier for your opponents to take you seriously.
> BTW: It is my opinion that syntax matters and that a
> static type system and many other things make sense.
Yes, of course. And also a simple syntax and a dynamic type system make
sense. And for me, the perfect world is where you have a choice between
those options.
> Greetings Thomas Mertes
Yours, Nicolas
On 13 Mai, 18:25, Nicolas Neuss <········@math.uni-karlsruhe.de>
wrote:
> ·············@gmx.at writes:
> > Static type checking is not new, but it has some vantages
> > ignored by fans of dynamic typing:
>
> Hey, guy-with-the-simple-world-view
Would you please stop your ad hominem attacks
[Rest of mail ignored because of an ad hominem attack]
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
On 2009-05-13, ·············@gmx.at <·············@gmx.at> wrote:
> On 13 Mai, 13:06, Tamas K Papp <······@gmail.com> wrote:
>> On Wed, 13 May 2009 00:55:30 -0700, thomas.mertes wrote:
>> > data and other Lisp concepts. I just don't get enthusiastic about this
>> > concepts because I miss other concepts which IMHO also have some value.
>> > I will not start a discussion about this concepts since I already know
>>
>> Well, then your statement is pretty vacuous, ...
>
> http://seed7.sourceforge.net/faq.htm#lisp_comparison
>
> Static type checking is not new, but it has some vantages
> ignored by fans of dynamic typing:
Are you saying that all ``fans'' of dynamic typing do not know what static
typing is? If not all, then you should compile a concrete list of names,
so that you don't paint the rest with the same brush.
> http://seed7.sourceforge.net/faq.htm#static_type_checking
Completely moronic material written by someone who is appears to be complete
newbie to the static-versus-dynamic debate, and hasn't even done the
basic background googling in preparation for writing this diatribe.
> http://seed7.sourceforge.net/faq.htm#development_speed_and_type_checking
>
>> > I hope you invest some time to look at Seed7. :-)
>>
>> I can't see any novel features in it.
>
> Well, it is probably impossible to get any positive message
> from a typical Lisp enthusiast, but there are some features.
I've received lots of positive messages from Lisp enthusiasts over the years.
There must be some problem at your end.
Probable diagnosis: ignorance combined with flapping gums.
> What about the possibility to define the syntax of constructs:
CLPython:
http://common-lisp.net/project/clpython
Infix notation for Lisp:
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/infix.cl
``CGOL'' Algol-like front-end for Common Lisp:
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/cgol/0.html
Scribble: markup syntax embedded in Lisp:
http://www.cliki.net/scribble
TwinLisp: C/Java-like syntax over Common Lisp:
http://www.nongnu.org/twinlisp/
Defining new (read) syntax within a language is not ``novel''.
Anyway, read syntax isn't what Lispers understand to be real syntax anyway.
Real syntax is the configuration of the abstract syntax tree, not how it's
written.
>> Also, listing "user defined statements
>> and operators" as a feature sounds like advertising you car "with
>> wheels included".
>
> I am talking about defining statements/operators syntactically
> and semantically. I know that you think the + in (+ 1 2) is an
> operator while others would see it as function. I am talking
> about the infix operator + in 1 + 2. I would really be amazed
> when a Lisp fan would admit that syntax matters and that
> there is a difference (+ 1 2) between and 1 + 2 .
Well, be prepared to be shocked because, for instance, we widely recognize that
there is a difference between, say, 'X and (QUOTE X), or #'X and (FUNCTION X)
and even that this difference is useful.
However, we just don't think that anyone with two brain cells
to rub together finds the difference /interesting/,
which is not to say that the difference isn't /useful/.
A wooden wedge to hold a door open is useful, but uninteresting. See?
In any case, we have programmable read syntax, and when that isn't good enough,
you can write yourself an entire custom scanner.
> Sorry for being that harsh, but I have been attacked by Lisp
> fans to often.
That simply because the internet has an ``I'm a misinformed moron'' button
which produces a predictable, repeatable result. If you keep pushing it,
you will keep getting the same result.
On 13 Mai, 23:44, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-05-13, ·············@gmx.at <·············@gmx.at> wrote:
>
> > On 13 Mai, 13:06, Tamas K Papp <······@gmail.com> wrote:
> >> On Wed, 13 May 2009 00:55:30 -0700, thomas.mertes wrote:
> >> > data and other Lisp concepts. I just don't get enthusiastic about this
> >> > concepts because I miss other concepts which IMHO also have some value.
> >> > I will not start a discussion about this concepts since I already know
>
> >> Well, then your statement is pretty vacuous, ...
>
> >http://seed7.sourceforge.net/faq.htm#lisp_comparison
>
> > Static type checking is not new, but it has some vantages
> > ignored by fans of dynamic typing:
>
> Are you saying that all ``fans'' of dynamic typing do not know what static
> typing is?
No.
[snip]
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Kaz Kylheku wrote:
...
> Completely moronic material written by someone who is appears to be complete
> newbie to the static-versus-dynamic debate, and hasn't even done the
> basic background googling in preparation for writing this diatribe.
...
> There must be some problem at your end.
>
> Probable diagnosis: ignorance combined with flapping gums.
...
> That simply because the internet [sic] has an ``I'm a misinformed moron'' button
> which [sic] produces a predictable, repeatable result. If you keep pushing it,
> you will keep getting the same result.
Plonk.
--
Lew
On 2009-05-14, Lew <·····@lewscanon.com> wrote:
> Kaz Kylheku wrote:
> ...
>> Completely moronic material written by someone who is appears to be complete
>> newbie to the static-versus-dynamic debate, and hasn't even done the
>> basic background googling in preparation for writing this diatribe.
> ...
>> There must be some problem at your end.
>>
>> Probable diagnosis: ignorance combined with flapping gums.
> ...
>> That simply because the internet [sic] has an ``I'm a misinformed moron'' button
I'm tired of capitalizing ``the internet''. It's about time to stop doing it.
There is no good reason to. We don't capitalize ``the world'', for instance,
or ``the power grid''.
So you can [sic] that where the sun don't shine. Pardon me, ``doesn't''.
>> which [sic] produces a predictable, repeatable result. If you keep pushing it,
Not sure what you are bitching about here. Since ``which'' is spelled
correctly, I suppose you are bemoaning the lack of a comma. Well, I have
news for you: it doesn't belong there.
A comma is used before which when its antecedent is the preceding clause as a
whole. Here, it just refers to ``button'', so the comma is not appropriate.
Go repeat seventh grade.
>> you will keep getting the same result.
>
> Plonk.
A petulant overture. Nobody gives a rat's what's in your kill file.
Kaz Kylheku wrote:
> I'm tired of capitalizing ``the internet''. It's about time to stop doing it.
> There is no good reason to. We don't capitalize ``the world'', for instance,
> or ``the power grid''.
Wired's style guide no longer capitalizes the interthing - for exactly the same
reason...
Phlip wrote:
Kaz Kylheku wrote:
>> I'm tired of capitalizing ``the internet''. It's about time to stop
>> doing it.
>> There is no good reason to. We don't capitalize ``the world'', for
>> instance,
>> or ``the power grid''.
Neither "world" nor "power grid" are coined proper nouns as "Internet" is,
referring as it does to a specific network given its name via a standards
document, namely RFC 675. It is, of course, your right to be wrong.
> Wired's style guide no longer capitalizes the interthing - for exactly
> the same reason...
I don't recognize Wired as the ultimate arbiter of English usage. If they
chose to spell my name "lew" instead of "Lew", it wouldn't change the fact
that the latter is correct, referring to a specific entity, coincidentally
also ratified by a standards document.
--
Lew
Lew wrote:
>> Wired's style guide no longer capitalizes the interthing - for exactly
>> the same reason...
>
> I don't recognize Wired as the ultimate arbiter of English usage. If
> they chose to spell my name "lew" instead of "Lew", it wouldn't change
> the fact that the latter is correct, referring to a specific entity,
> coincidentally also ratified by a standards document.
The compression technique called "huffman encoding" has achieved the same
status. (But Wired is just another tool of The Man...)
On 2009-05-14, Lew <·····@lewscanon.com> wrote:
> Phlip wrote:
> Kaz Kylheku wrote:
>>> I'm tired of capitalizing ``the internet''. It's about time to stop
>>> doing it.
>>> There is no good reason to. We don't capitalize ``the world'', for
>>> instance,
>>> or ``the power grid''.
>
> Neither "world" nor "power grid" are coined proper nouns as "Internet" is,
> referring as it does to a specific network given its name via a standards
> document, namely RFC 675. It is, of course, your right to be wrong.
Evidently, folks, sometimes ``plonk'' means ``I will henceforth follow up to
your articles, but with a double >> before all your text instead of
a single > .''
Maybe this twit should read the RFC's that explain the difference between
e-mail and Usenet, and then get a real newsreader with proper killfile support.
"Kaz Kylheku" <········@gmail.com> wrote in message
······················@gmail.com...
> On 2009-05-13, ·············@gmx.at <·············@gmx.at> wrote:
>> Well, it is probably impossible to get any positive message
>> from a typical Lisp enthusiast, but there are some features.
>
> I've received lots of positive messages from Lisp enthusiasts over the
> years.
Lisp users do seem to be a rather fanatical lot, according to what I see in
comp.programming. I see that as a bigger turn-off than the language itself
(which is almost devoid of syntax so increasing complexity in other areas).
>> What about the possibility to define the syntax of constructs:
>
> CLPython:
...
> Infix notation for Lisp:
...
> ``CGOL'' Algol-like front-end for Common Lisp:
...
> Scribble: markup syntax embedded in Lisp:
...
> TwinLisp: C/Java-like syntax over Common Lisp:
...
All seem to be attempts to add that missing syntax to Lisp...
--
Bart
BartC wrote:
> "Kaz Kylheku" <········@gmail.com> wrote in message
> ······················@gmail.com...
>> On 2009-05-13, ·············@gmx.at <·············@gmx.at> wrote:
>
>>> Well, it is probably impossible to get any positive message
>>> from a typical Lisp enthusiast, but there are some features.
>>
>> I've received lots of positive messages from Lisp enthusiasts over the
>> years.
>
> Lisp users do seem to be a rather fanatical lot, according to what I see
> in comp.programming. I see that as a bigger turn-off than the language
> itself ...
cue Joey Buttafucco
> (which is almost devoid of syntax so increasing complexity in
> other areas).
Yep, two good examples being the crazy street patterns of Boston and
Washington, DC.
>
>>> What about the possibility to define the syntax of constructs:
>>
>> CLPython:
> ...
>> Infix notation for Lisp:
> ...
>> ``CGOL'' Algol-like front-end for Common Lisp:
> ...
>> Scribble: markup syntax embedded in Lisp:
> ...
>> TwinLisp: C/Java-like syntax over Common Lisp:
> ...
>
> All seem to be attempts to add that missing syntax to Lisp...
>
Don't forget Dylan!
Hallo Thomas,
This:
> http://seed7.sourceforge.net/faq.htm#development_speed_and_type_checking
Quoting from this text (author: Thomas):
"When comparing compile-time and runtime type checking it can be
concluded that dynamic typed languages save some programming time
by omitting type declarations, but this time must be paid back with
massive interest rates to do the debugging."
and this:
> BTW: It is my opinion that syntax matters and that a
> static type system and many other things make sense.
... gives quite some insight into the coding approach and coding style
chosen.
If you code with dynamic typing mind you will not have these "massive
interest rates to do debugging". Been there, done that: 20 years of C
coding (and C++, and ...) and 12 years of Common Lisp.
How many years, or better, applications actually in production use, do
you have with dynamic typed languages?
>
> Greetings Thomas Mertes
>
> Seed7 Homepage: http://seed7.sourceforge.net
> Seed7 - The extensible programming language: User defined statements
> and operators, abstract data types, templates without special
> syntax, OO with interfaces and multiple dispatch, statically typed,
> interpreted or compiled, portable, runs under linux/unix/windows.
Ah - Mac OS X?
Mit besten Gr��en (with best regards)
Frank
On 13 Mai, 21:51, Frank GOENNINGER <······@googlemail.com> wrote:
> Hallo Thomas,
>
> This:
>
> >http://seed7.sourceforge.net/faq.htm#development_speed_and_type_checking
>
> Quoting from this text (author: Thomas):
>
> "When comparing compile-time and runtime type checking it can be
> concluded that dynamic typed languages save some programming time
> by omitting type declarations, but this time must be paid back with
> massive interest rates to do the debugging."
>
> and this:
>
> > BTW: It is my opinion that syntax matters and that a
> > static type system and many other things make sense.
>
> ... gives quite some insight into the coding approach and coding style
> chosen.
Come on. From this two sentences you think you have insight into my
coding approach. I would say you probably don't have the slightest
clue what I use as coding approach.
> If you code with dynamic typing mind you will not have these "massive
> interest rates to do debugging".
With dynamic typing in mind you probably will not make any errors.
Do you ignore possible type errors and just omit code coveage tests?
> Been there, done that: 20 years of C
C is probably not the best language to see an advantage in a
static type system.
> coding (and C++, and ...) and 12 years of Common Lisp.
If you wanted to impress me you should have started coding much
earlier. I started to study computer science in 1980 and I have
programmed since 1978 in many languages. I have more than 20 years
C/C++ experience, approx. 12 years Pascal and also in many other
languages (Java, ...) . About dynamic languages: The predecessor
of Seed7 was a dynamic language and I used it for more then 12
years. So I can also say "Been there, done that". Just that I
introduced static type checks and other things to a dynamic
language. Seed7 still has dynamic features. It took me a very
long to find it out: Static and dynamic features can be combined,
but it is necessary to explicitely state when you want to do
something dynamic. You define DYNAMIC functions which dispatch
at runtime. See
http://seed7.sourceforge.net/manual/objects.htm
Do you want to establish yourself as higher ranking than me?
Does it make your arguments (where are they anyway) better?
Cool down, I belive that you have knowledge, but I have also
knowledge.
> How many years, or better, applications actually in production use, do
> you have with dynamic typed languages?
See above
> > Greetings Thomas Mertes
>
> > Seed7 Homepage: http://seed7.sourceforge.net
> > Seed7 - The extensible programming language: User defined statements
> > and operators, abstract data types, templates without special
> > syntax, OO with interfaces and multiple dispatch, statically typed,
> > interpreted or compiled, portable, runs under linux/unix/windows.
>
> Ah - Mac OS X?
What do you mean with that sentence?
Do you own a mac or assume that I use one?
Well, I don't use Mac OS X, but I have reports that Seed7 can be
compiled on Mac OS X. You just need to install XCODE and then you
can use the makefile mk_osx.mak (Until now I was not able to check
it, but the chances are intact).
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at writes:
> On 13 Mai, 21:51, Frank GOENNINGER <······@googlemail.com> wrote:
>> Hallo Thomas,
>>
>> This:
>>
>> >http://seed7.sourceforge.net/faq.htm#development_speed_and_type_checking
>>
>> Quoting from this text (author: Thomas):
>>
>> "When comparing compile-time and runtime type checking it can be
>> concluded that dynamic typed languages save some programming time
>> by omitting type declarations, but this time must be paid back with
>> massive interest rates to do the debugging."
>>
>> and this:
>>
>> > BTW: It is my opinion that syntax matters and that a
>> > static type system and many other things make sense.
>>
>> ... gives quite some insight into the coding approach and coding style
>> chosen.
>
> Come on. From this two sentences you think you have insight into my
> coding approach. I would say you probably don't have the slightest
> clue what I use as coding approach.
Well, it does tell that you rely on the compiler to check the type of an
object. I do say that a pure static typing is a PITA when aiming at
reusable code. I had to do coding where I could not foresee all possible
data types being used - just "objects".
>> If you code with dynamic typing mind you will not have these "massive
>> interest rates to do debugging".
>
> With dynamic typing in mind you probably will not make any errors.
Huh? Oh my. Did you ever really do any reasonably sized app for
production use? Wow - I will not let my fellow co-workers here or read
that statement of yours. They might be asking for doing dynamic typing
/only/ in the future...
> Do you ignore possible type errors and just omit code coveage tests?
When strictly needed then I am asking my long-term pal for help (assert).
>> Been there, done that: 20 years of C
>
> C is probably not the best language to see an advantage in a
> static type system.
Which language do you have in mind as being appropriate ?
>
>> coding (and C++, and ...) and 12 years of Common Lisp.
>
> If you wanted to impress me you should have started coding much
> earlier.
Sorry. That's a thing you need to address to my parents. They haven't
been together earlier, so ...
> I started to study computer science in 1980 and I have
> programmed since 1978 in many languages. I have more than 20 years
> C/C++ experience, approx. 12 years Pascal and also in many other
> languages (Java, ...) . About dynamic languages: The predecessor
> of Seed7 was a dynamic language and I used it for more then 12
> years. So I can also say "Been there, done that".
And Seed7 was the ultimate result of all this experience?
> Just that I
> introduced static type checks and other things to a dynamic
> language. Seed7 still has dynamic features. It took me a very
> long to find it out: Static and dynamic features can be combined,
> but it is necessary to explicitely state when you want to do
> something dynamic. You define DYNAMIC functions which dispatch
> at runtime. See
>
> http://seed7.sourceforge.net/manual/objects.htm
And Lisp does it the other way: Give freedom to the programmer and
provide ways to limit freedom when she explicitely asks for it. You
know - Lisp comes with Bondage Included.
> Do you want to establish yourself as higher ranking than me?
> Does it make your arguments (where are they anyway) better?
> Cool down, I belive that you have knowledge, but I have also
> knowledge.
Now you're going psycho. Another case of inferiority complex.
>
>> How many years, or better, applications actually in production use, do
>> you have with dynamic typed languages?
>
> See above
I looked. But I couldn't find reference to an application. You want me
to name one of mine ? (Show-me-yours-and-I'll-show-you-mine games are so
exciting ;-)
>
>> > Greetings Thomas Mertes
>>
>> > Seed7 Homepage: http://seed7.sourceforge.net
>> > Seed7 - The extensible programming language: User defined statements
>> > and operators, abstract data types, templates without special
>> > syntax, OO with interfaces and multiple dispatch, statically typed,
>> > interpreted or compiled, portable, runs under linux/unix/windows.
>>
>> Ah - Mac OS X?
>
> What do you mean with that sentence?
> Do you own a mac or assume that I use one?
> Well, I don't use Mac OS X, but I have reports that Seed7 can be
> compiled on Mac OS X. You just need to install XCODE and then you
> can use the makefile mk_osx.mak (Until now I was not able to check
> it, but the chances are intact).
Ok, I got hooked. So I downloaded Seed7 source code from Sourceforge. I
then issued a
····@ccde007 ~/Downloads/seed7/src
$ make -f mk_osx.mak
and got:
cc -O2 -g -Wall -Wstrict-prototypes -Winline -Wconversion -Wshadow -Wpointer-arith -c hi.c
hi.c:28:21: error: version.h: No such file or directory
In file included from hi.c:35:
sigutl.h:37: warning: function declaration isn�t a prototype
In file included from hi.c:36:
data.h:137: warning: function declaration isn�t a prototype
In file included from hi.c:37:
infile.h:95: warning: function declaration isn�t a prototype
infile.h:96: warning: function declaration isn�t a prototype
infile.h:97: warning: function declaration isn�t a prototype
infile.h:98: warning: function declaration isn�t a prototype
infile.h:99: warning: function declaration isn�t a prototype
infile.h:100: warning: function declaration isn�t a prototype
infile.h:101: warning: function declaration isn�t a prototype
infile.h:102: warning: function declaration isn�t a prototype
infile.h:103: warning: function declaration isn�t a prototype
infile.h:104: warning: function declaration isn�t a prototype
In file included from hi.c:38:
syvarutl.h:63: warning: function declaration isn�t a prototype
syvarutl.h:64: warning: function declaration isn�t a prototype
In file included from hi.c:39:
identutl.h:43: warning: function declaration isn�t a prototype
identutl.h:44: warning: function declaration isn�t a prototype
identutl.h:45: warning: function declaration isn�t a prototype
identutl.h:46: warning: function declaration isn�t a prototype
In file included from hi.c:40:
entutl.h:54: warning: function declaration isn�t a prototype
entutl.h:55: warning: function declaration isn�t a prototype
entutl.h:56: warning: function declaration isn�t a prototype
entutl.h:57: warning: function declaration isn�t a prototype
entutl.h:58: warning: function declaration isn�t a prototype
entutl.h:59: warning: function declaration isn�t a prototype
entutl.h:60: warning: function declaration isn�t a prototype
entutl.h:61: warning: function declaration isn�t a prototype
entutl.h:62: warning: function declaration isn�t a prototype
In file included from hi.c:41:
findid.h:51: warning: function declaration isn�t a prototype
findid.h:52: warning: function declaration isn�t a prototype
findid.h:53: warning: function declaration isn�t a prototype
findid.h:54: warning: function declaration isn�t a prototype
findid.h:55: warning: function declaration isn�t a prototype
In file included from hi.c:42:
symbol.h:67: warning: function declaration isn�t a prototype
symbol.h:69: warning: function declaration isn�t a prototype
symbol.h:70: warning: function declaration isn�t a prototype
In file included from hi.c:43:
analyze.h:35: warning: function declaration isn�t a prototype
analyze.h:36: warning: function declaration isn�t a prototype
In file included from hi.c:44:
traceutl.h:74: warning: function declaration isn�t a prototype
traceutl.h:75: warning: function declaration isn�t a prototype
traceutl.h:76: warning: function declaration isn�t a prototype
traceutl.h:77: warning: function declaration isn�t a prototype
traceutl.h:78: warning: function declaration isn�t a prototype
traceutl.h:79: warning: function declaration isn�t a prototype
traceutl.h:80: warning: function declaration isn�t a prototype
traceutl.h:81: warning: function declaration isn�t a prototype
traceutl.h:82: warning: function declaration isn�t a prototype
traceutl.h:83: warning: function declaration isn�t a prototype
traceutl.h:84: warning: function declaration isn�t a prototype
traceutl.h:85: warning: function declaration isn�t a prototype
traceutl.h:86: warning: function declaration isn�t a prototype
traceutl.h:87: warning: function declaration isn�t a prototype
traceutl.h:88: warning: function declaration isn�t a prototype
traceutl.h:89: warning: function declaration isn�t a prototype
traceutl.h:90: warning: function declaration isn�t a prototype
traceutl.h:91: warning: function declaration isn�t a prototype
traceutl.h:92: warning: function declaration isn�t a prototype
traceutl.h:93: warning: function declaration isn�t a prototype
traceutl.h:94: warning: function declaration isn�t a prototype
traceutl.h:95: warning: function declaration isn�t a prototype
traceutl.h:96: warning: function declaration isn�t a prototype
traceutl.h:97: warning: function declaration isn�t a prototype
In file included from hi.c:45:
exec.h:40: warning: function declaration isn�t a prototype
exec.h:41: warning: function declaration isn�t a prototype
exec.h:42: warning: function declaration isn�t a prototype
exec.h:43: warning: function declaration isn�t a prototype
exec.h:44: warning: function declaration isn�t a prototype
exec.h:45: warning: function declaration isn�t a prototype
exec.h:46: warning: function declaration isn�t a prototype
In file included from hi.c:46:
option.h:60: warning: function declaration isn�t a prototype
In file included from hi.c:47:
runerr.h:50: warning: function declaration isn�t a prototype
runerr.h:51: warning: function declaration isn�t a prototype
runerr.h:52: warning: function declaration isn�t a prototype
runerr.h:53: warning: function declaration isn�t a prototype
runerr.h:54: warning: function declaration isn�t a prototype
runerr.h:55: warning: function declaration isn�t a prototype
runerr.h:56: warning: function declaration isn�t a prototype
runerr.h:57: warning: function declaration isn�t a prototype
In file included from hi.c:49:
flt_rtl.h:61: warning: function declaration isn�t a prototype
flt_rtl.h:62: warning: function declaration isn�t a prototype
flt_rtl.h:63: warning: function declaration isn�t a prototype
flt_rtl.h:64: warning: function declaration isn�t a prototype
flt_rtl.h:65: warning: function declaration isn�t a prototype
flt_rtl.h:66: warning: function declaration isn�t a prototype
flt_rtl.h:67: warning: function declaration isn�t a prototype
flt_rtl.h:68: warning: function declaration isn�t a prototype
flt_rtl.h:69: warning: function declaration isn�t a prototype
In file included from hi.c:50:
scr_drv.h:58: warning: function declaration isn�t a prototype
scr_drv.h:59: warning: function declaration isn�t a prototype
scr_drv.h:60: warning: function declaration isn�t a prototype
scr_drv.h:61: warning: function declaration isn�t a prototype
scr_drv.h:62: warning: function declaration isn�t a prototype
scr_drv.h:63: warning: function declaration isn�t a prototype
scr_drv.h:64: warning: function declaration isn�t a prototype
scr_drv.h:65: warning: function declaration isn�t a prototype
scr_drv.h:66: warning: function declaration isn�t a prototype
scr_drv.h:67: warning: function declaration isn�t a prototype
scr_drv.h:68: warning: function declaration isn�t a prototype
scr_drv.h:69: warning: function declaration isn�t a prototype
scr_drv.h:70: warning: function declaration isn�t a prototype
hi.c:60: warning: function declaration isn�t a prototype
make: *** [hi.o] Error 1
This is on OS X 10.5.6 with Xcode 3.1.2 (the latest one). So, aside from
the compile warnings, there's a whole file missing here (hint:
version.h).
As I was *really* hooked I took the trouble and fired up Xcode, created
an new project and imported all source files into it.
The first run of a build showed that even more files are missing:
version.h, gmp.h - at that point I decided to give up.
Based on the 1111 errors and 809 warning the build run gave me I'd
estimate more than a day of effort to get this to compile on OS X.
As it stands a lot of the errors are depending on gmp.h...
At least I tried.
Frank
On 14 Mai, 14:26, Frank GOENNINGER <······@googlemail.com> wrote:
> ·············@gmx.at writes:
> > On 13 Mai, 21:51, Frank GOENNINGER <······@googlemail.com> wrote:
> >> ... gives quite some insight into the coding approach and coding style
> >> chosen.
>
> > Come on. From this two sentences you think you have insight into my
> > coding approach. I would say you probably don't have the slightest
> > clue what I use as coding approach.
>
> Well, it does tell that you rely on the compiler to check the type of an
> object. I do say that a pure static typing is a PITA when aiming at
> reusable code. I had to do coding where I could not foresee all possible
> data types being used - just "objects".
In this case you might use templates.
> >> If you code with dynamic typing mind you will not have these "massive
> >> interest rates to do debugging".
>
> > With dynamic typing in mind you probably will not make any errors.
>
> Huh? Oh my. Did you ever really do any reasonably sized app for
> production use?
Here I used a concept known as sarcasm.
See http://en.wikipedia.org/wiki/Sarcasm
> >> Been there, done that: 20 years of C
>
> > C is probably not the best language to see an advantage in a
> > static type system.
>
> Which language do you have in mind as being appropriate ?
I just wanted to point out that automatic casts and void * are big
holes in a type system. Therefore type errors may be undetected.
> >> coding (and C++, and ...) and 12 years of Common Lisp.
>
> > If you wanted to impress me you should have started coding much
> > earlier.
>
> Sorry. That's a thing you need to address to my parents. They haven't
> been together earlier, so ...
>
> > I started to study computer science in 1980 and I have
> > programmed since 1978 in many languages. I have more than 20 years
> > C/C++ experience, approx. 12 years Pascal and also in many other
> > languages (Java, ...) . About dynamic languages: The predecessor
> > of Seed7 was a dynamic language and I used it for more then 12
> > years. So I can also say "Been there, done that".
>
> And Seed7 was the ultimate result of all this experience?
No. It is just the beginning...
Seed7 should grow and everybody is invited to help.
> > Just that I
> > introduced static type checks and other things to a dynamic
> > language. Seed7 still has dynamic features. It took me a very
> > long to find it out: Static and dynamic features can be combined,
> > but it is necessary to explicitely state when you want to do
> > something dynamic. You define DYNAMIC functions which dispatch
> > at runtime. See
>
> > http://seed7.sourceforge.net/manual/objects.htm
>
> And Lisp does it the other way: Give freedom to the programmer and
> provide ways to limit freedom when she explicitely asks for it. You
> know - Lisp comes with Bondage Included.
Seed7 allows dynamic things based on a static type system.
It is just necessary to say where you want dynamic dispatch or
for which types you want a template instantiated.
> > Do you want to establish yourself as higher ranking than me?
> > Does it make your arguments (where are they anyway) better?
> > Cool down, I belive that you have knowledge, but I have also
> > knowledge.
>
> Now you're going psycho. Another case of inferiority complex.
Come on. You started to talk how experienced you are.
Ask my family if I have an inferiority complex or just the
opposite. :-)
In general: Personal attacks lead to nowhere.
Can we agree to ommit them.
> >> How many years, or better, applications actually in production use, do
> >> you have with dynamic typed languages?
>
> > See above
>
> I looked. But I couldn't find reference to an application.
The programs that I developed for various companys since 1988 are
not available in the Internet. Besides Seed7 I did some development
for Wine. As I said the predecessor of Seed7 (named HAL) was highly
dynamic. I used HAL for various hobby programs for approx. a dozen
years. But I missed the compiler telling me about type errors before
executing the program. Therefore I turned the HAL interpreter (hence
I still use the name hi) into a Seed7 interpreter. I ported most HAL
programs to Seed7 except for some text adventure games and other
stuff. As soon as Seed7 will be able to support this programs I will
port them to Seed7 as well.
> You want me
> to name one of mine ? (Show-me-yours-and-I'll-show-you-mine games are so
> exciting ;-)
No, I am not interested.
> >> Ah - Mac OS X?
>
> > What do you mean with that sentence?
> > Do you own a mac or assume that I use one?
> > Well, I don't use Mac OS X, but I have reports that Seed7 can be
> > compiled on Mac OS X. You just need to install XCODE and then you
> > can use the makefile mk_osx.mak (Until now I was not able to check
> > it, but the chances are intact).
>
> Ok, I got hooked. So I downloaded Seed7 source code from Sourceforge. I
> then issued a
>
> ····@ccde007 ~/Downloads/seed7/src
> $ make -f mk_osx.mak
>
> and got:
>
> cc -O2 -g -Wall -Wstrict-prototypes -Winline -Wconversion -Wshadow -Wpointer-arith -c hi.c
> hi.c:28:21: error: version.h: No such file or directory
> ...
You forgot a 'make depend'. The normal way of compiling would be:
make -f mk_osx.mak depend
make -f mk_osx.mak
Since the failed attempt produced some unneeded files it is
necessary to do:
make -f mk_osx.mak clean
make -f mk_osx.mak depend
make -f mk_osx.mak
Maybe I should add a more detailed description to the files
seed7/read_me and seed7/src/read_me.txt .
Sorry for the trouble. I hope you have a second try.
> This is on OS X 10.5.6 with Xcode 3.1.2 (the latest one). So, aside from
> the compile warnings, there's a whole file missing here (hint:
> version.h).
The file version.h is generated with 'make depend'
> As I was *really* hooked I took the trouble and fired up Xcode, created
> an new project and imported all source files into it.
>
> The first run of a build showed that even more files are missing:
> version.h, gmp.h - at that point I decided to give up.
The aproach with 'make' was the right one.
A tool like Xcode tries to compile every *.c file in a directory.
Even the ones that are provided as alternative solution for other
operating systems or other librarys. Since Seed7 can be compiled
under Windows also there are driver files for graphics, console,
keyboard, directory access and other stuff in several variations.
The makefile decides which files are used and which are ignored.
> Based on the 1111 errors and 809 warning the build run gave me I'd
> estimate more than a day of effort to get this to compile on OS X.
With
make -f mk_osx.mak clean
make -f mk_osx.mak depend
make -f mk_osx.mak
It should not take that long.
> As it stands a lot of the errors are depending on gmp.h...
GMP is the GNU Multiple Precision Arithmetic Library which could be
used as an alternative to the built-in big_rtl.c library. Both
support unlimited precision integers (at least as long as there is
enough memory).
> At least I tried.
Don't give up. If you have questions, just ask.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at writes:
> On 14 Mai, 14:26, Frank GOENNINGER <······@googlemail.com> wrote:
>> ·············@gmx.at writes:
>> > On 13 Mai, 21:51, Frank GOENNINGER <······@googlemail.com> wrote:
>> >> ... gives quite some insight into the coding approach and coding style
>> >> chosen.
>>
>> > Come on. From this two sentences you think you have insight into my
>> > coding approach. I would say you probably don't have the slightest
>> > clue what I use as coding approach.
>>
>> Well, it does tell that you rely on the compiler to check the type of an
>> object. I do say that a pure static typing is a PITA when aiming at
>> reusable code. I had to do coding where I could not foresee all possible
>> data types being used - just "objects".
>
> In this case you might use templates.
I admit having no clue about Seed7 templates. If they are like C++
templates then I have to say no, I will definetly not expose myself to
that kind of pain again. I do know better solutions: Common Lisp.
>> >> If you code with dynamic typing mind you will not have these "massive
>> >> interest rates to do debugging".
>>
>> > With dynamic typing in mind you probably will not make any errors.
>>
>> Huh? Oh my. Did you ever really do any reasonably sized app for
>> production use?
>
> Here I used a concept known as sarcasm.
> See http://en.wikipedia.org/wiki/Sarcasm
Hehe, yeah. Problem is that with your writing style noone knows when you
are emtting sarcasm or sincere statements.
>
>> >> Been there, done that: 20 years of C
>>
>> > C is probably not the best language to see an advantage in a
>> > static type system.
>>
>> Which language do you have in mind as being appropriate ?
>
> I just wanted to point out that automatic casts and void * are big
> holes in a type system. Therefore type errors may be undetected.
Oha - now I know I was very fond of using void * and 4-star-programming
in C to get reasonable speed for sorting and searching functions while
not having to write separate functions for each new data type that came along.
[snip]
> Seed7 should grow and everybody is invited to help.
Ah, I do smell a business here. What would be daily rates for the help?
[snip]
>
>> > Do you want to establish yourself as higher ranking than me?
>> > Does it make your arguments (where are they anyway) better?
>> > Cool down, I belive that you have knowledge, but I have also
>> > knowledge.
>>
>> Now you're going psycho. Another case of inferiority complex.
>
> Come on. You started to talk how experienced you are.
> Ask my family if I have an inferiority complex or just the
> opposite. :-)
No. Not the opposite, unfortunately. If you were a case of megalomania
then you'd straight refuse to post followups to my posts and had written
here that I am below your mental niveau. You didn't, and even fell for
this tempting line...
>
> In general: Personal attacks lead to nowhere.
> Can we agree to ommit them.
They are what makes Usenet the real Usenet. Besides, my statement was
just pure observation and personal opinion. Taking it as an insult only
comes from a - hm, how to say this without being interpreted as personal
attach again - well, maybe you suggest something yourself here and the
whole bunch of readers can stop laughing as laughing would be a kind of
reaction highee educated people than me classified as a human reaction
on stimuli .... eh - where was i ?
[snip]
>>
>> Ok, I got hooked. So I downloaded Seed7 source code from Sourceforge. I
>> then issued a
>>
>> ····@ccde007 ~/Downloads/seed7/src
>> $ make -f mk_osx.mak
>>
>> and got:
>>
>> cc -O2 -g -Wall -Wstrict-prototypes -Winline -Wconversion -Wshadow -Wpointer-arith -c hi.c
>> hi.c:28:21: error: version.h: No such file or directory
>> ...
>
> You forgot a 'make depend'. The normal way of compiling would be:
>
> make -f mk_osx.mak depend
> make -f mk_osx.mak
>
> Since the failed attempt produced some unneeded files it is
> necessary to do:
>
> make -f mk_osx.mak clean
> make -f mk_osx.mak depend
> make -f mk_osx.mak
Ooookaaaayyy - so I did as you told me. Results:
····@ccde007 ~/Downloads/seed7/src
$ make -f mk_osx.mak clean
rm *.o *.a depend a_depend b_depend c_depend version.h
rm: *.o: No such file or directory
rm: *.a: No such file or directory
rm: depend: No such file or directory
rm: a_depend: No such file or directory
rm: b_depend: No such file or directory
rm: c_depend: No such file or directory
rm: version.h: No such file or directory
make: *** [clean] Error 1
Hm. Okay. Some suggestions for changes:
1. In the makefile, change this:
clean:
rm *.o *.a depend a_depend b_depend c_depend version.h
into:
RM = rm -f
clean:
$(RM) *.o *.a depend a_depend b_depend c_depend version.h
2. Use a simple script to detect on which platform you are. Then select
the appropriate makefile and execute. No README to be maintained, no
nothing, even better user experience.
>
> Maybe I should add a more detailed description to the files
> seed7/read_me and seed7/src/read_me.txt .
No. As just said.
>
> Sorry for the trouble. I hope you have a second try.
Oh, sure. You are talking to a Lisper here. We guys are dedicated and
determined people. ;-)
[snipped details on build process]
>> Based on the 1111 errors and 809 warning the build run gave me I'd
>> estimate more than a day of effort to get this to compile on OS X.
>
> With
>
> make -f mk_osx.mak clean
> make -f mk_osx.mak depend
> make -f mk_osx.mak
>
> It should not take that long.
Confirmed. Took about 30 seconds total.
HI INTERPRETER Version 4.5.4741 Copyright (c) 1990-2009 Thomas Mertes
262 /Users/frgo/Downloads/seed7/lib/syntax.s7i
3518 /Users/frgo/Downloads/seed7/lib/seed7_05.s7i
32 level.sd7
3812 lines total
254133 lines per second
1699814 bytes
Current level is 4741
>
>> As it stands a lot of the errors are depending on gmp.h...
>
> GMP is the GNU Multiple Precision Arithmetic Library which could be
> used as an alternative to the built-in big_rtl.c library. Both
> support unlimited precision integers (at least as long as there is
> enough memory).
Knew that. Ah - we don't need a GMP to do unlimited precision integers
in Common Lisp. It's in the ANSI Standard - yada yada, sorry, couldn't
resist. :-)
>
>> At least I tried.
>
> Don't give up. If you have questions, just ask.
No more questions open. I just delivered answers:
Yes, you could ease the build process.
Yes, it compiles and runs on OS X.
Yes, it runs ok on OS X.
I do hope I haven't been insulting by providing these answers. Gee -
this *is* Usenet. Get used to it - no, not you - all the lurkers and
anonymuous readers here -
>
> Greetings Thomas Mertes
Hope to meet you eventually (in the English meaning, not the false German
"translation" ;-). I'll be not be in Ennepetal though for some
time.
Back to doing my own pet project: Cello NX. An application kit for
building GUIs based on hardware-accelerated OpenGL graphics based on
Cello from Ken Tilton based on Celtk from Ken Tilton and on Ltk based on
Cells from the same Ken and providing a wholly dynamic way of
implementing things being free of type bondage. Yes. I mean it.
Frank
Frank GOENNINGER wrote:
> They are what makes Usenet the real Usenet. Besides, my statement was
> just pure observation and personal opinion. Taking it as an insult only
> comes from a - hm, how to say this without being interpreted as personal
> attach again - well, maybe you suggest something yourself here and the
> whole bunch of readers can stop laughing as laughing would be a kind of
> reaction highee educated people than me classified as a human reaction
> on stimuli .... eh - where was i ?
Rambling incoherently.
Seamus MacRae <··········@live.ca.nospam> writes:
> Frank GOENNINGER wrote:
>> They are what makes Usenet the real Usenet. Besides, my statement was
>> just pure observation and personal opinion. Taking it as an insult only
>> comes from a - hm, how to say this without being interpreted as personal
>> attach again - well, maybe you suggest something yourself here and the
>> whole bunch of readers can stop laughing as laughing would be a kind of
>> reaction highee educated people than me classified as a human reaction
>> on stimuli .... eh - where was i ?
>
> Rambling incoherently.
Isn't Usenet wonderful ? You learn something new every day. For some it
means learning something new about themselves, well, maybe not every day.
Oh, btw, either we end this thread now or we give it a more appropriate
topic ...
Frank
On 14 Mai, 17:36, Frank GOENNINGER <······@googlemail.com> wrote:
> ·············@gmx.at writes:
> > On 14 Mai, 14:26, Frank GOENNINGER <······@googlemail.com> wrote:
> >> ·············@gmx.at writes:
> >> > On 13 Mai, 21:51, Frank GOENNINGER <······@googlemail.com> wrote:
> >> >> ... gives quite some insight into the coding approach and coding style
> >> >> chosen.
>
> >> > Come on. From this two sentences you think you have insight into my
> >> > coding approach. I would say you probably don't have the slightest
> >> > clue what I use as coding approach.
>
> >> Well, it does tell that you rely on the compiler to check the type of an
> >> object. I do say that a pure static typing is a PITA when aiming at
> >> reusable code. I had to do coding where I could not foresee all possible
> >> data types being used - just "objects".
>
> > In this case you might use templates.
>
> I admit having no clue about Seed7 templates. If they are like C++
> templates then I have to say no, I will definetly not expose myself to
> that kind of pain again. I do know better solutions: Common Lisp.
I see C++ templates also as ugly kludge. Seed7 templates are just
functions which are executed at compile time. This functions can
use types as parameters or result and usually have declaration
statements in the body. Normal functions are called explicit
therefore Seed7 template functions are also called explicit.
const proc: DEFINE_MAX (in type: aType is func
begin
const func aType: max (in aType: val1, in aType: val2) is func
result
var aType: result is aType.value;
begin
if val1 > val2 then
result := val1;
else
result := val2;
end if;
end func;
end func;
Instatiation is done with
DEFINE_MAX(integer);
DEFINE_MAX(myType);
Afterwards max(number, 3) is available. Another example where a
template defines a statement can be found here:
http://seed7.sourceforge.net/examples/for_decl.htm
BTW: In many languages the concept of an array is hardcoded in the
compiler. In Seed7 arrays are implemented as template. The array
template is defined in a library.
[snip]
> > Seed7 should grow and everybody is invited to help.
>
> Ah, I do smell a business here. What would be daily rates for the help?
In virtual money you can pay big rates. :-) Additionally I can offer
a place in the (soon to be created) hall of fame.
[snip]
> Ooookaaaayyy - so I did as you told me. Results:
>
> ····@ccde007 ~/Downloads/seed7/src
> $ make -f mk_osx.mak clean
> rm *.o *.a depend a_depend b_depend c_depend version.h
> rm: *.o: No such file or directory
> rm: *.a: No such file or directory
> rm: depend: No such file or directory
> rm: a_depend: No such file or directory
> rm: b_depend: No such file or directory
> rm: c_depend: No such file or directory
> rm: version.h: No such file or directory
> make: *** [clean] Error 1
>
> Hm. Okay. Some suggestions for changes:
>
> 1. In the makefile, change this:
> clean:
> rm *.o *.a depend a_depend b_depend c_depend version.h
>
> into:
>
> RM = rm -f
>
> clean:
> $(RM) *.o *.a depend a_depend b_depend c_depend version.h
Good idea.
> 2. Use a simple script to detect on which platform you are. Then select
> the appropriate makefile and execute. No README to be maintained, no
> nothing, even better user experience.
I started with a script for Windows (yes a *.bat file). Under
Windows several compilers and make utilitys need support. I am
not finished with the script and it would also need input
from the user. "Do you want to use MSVC or Mingw with gmake,
nmake or make?".
For an unix like OS such a script would be easier.
[snip]
> Confirmed. Took about 30 seconds total.
>
> HI INTERPRETER Version 4.5.4741 Copyright (c) 1990-2009 Thomas Mertes
> 262 /Users/frgo/Downloads/seed7/lib/syntax.s7i
> 3518 /Users/frgo/Downloads/seed7/lib/seed7_05.s7i
> 32 level.sd7
> 3812 lines total
> 254133 lines per second
> 1699814 bytes
> Current level is 4741
Great. To check the functionality the following program can
be used.
cd /Users/frgo/Downloads/seed7/prg
./hi chk_all
When all goes well you can do
./hi panic
and tell me how many monsters you have killed.
> >> As it stands a lot of the errors are depending on gmp.h...
>
> > GMP is the GNU Multiple Precision Arithmetic Library which could be
> > used as an alternative to the built-in big_rtl.c library. Both
> > support unlimited precision integers (at least as long as there is
> > enough memory).
>
> Knew that. Ah - we don't need a GMP to do unlimited precision integers
> in Common Lisp. It's in the ANSI Standard - yada yada, sorry, couldn't
> resist. :-)
Seed7 doesn't need GMP either. The build-in bigInteger support
works without GMP. Using the GMP instead of the built-in bigInteger
support is just an option. In the Seed7 programs you don't see any
difference.
> >> At least I tried.
>
> > Don't give up. If you have questions, just ask.
>
> No more questions open. I just delivered answers:
> Yes, you could ease the build process.
> Yes, it compiles and runs on OS X.
> Yes, it runs ok on OS X.
Thank you for the information.
> Hope to meet you eventually (in the English meaning, not the false German
> "translation" ;-). I'll be not be in Ennepetal though for some
> time.
I found Ennepetal with Google. Now I have to reason about the
meaning of 'meet' in different languages. :-)
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at writes:
> Great. To check the functionality the following program can
> be used.
>
> cd /Users/frgo/Downloads/seed7/prg
> ./hi chk_all
Results:
····@ccde007 ~/Downloads/seed7/prg
$ ../src/hi chk_all
HI INTERPRETER Version 4.5.4741 Copyright (c) 1990-2009 Thomas Mertes
262 /Users/frgo/Downloads/seed7/lib/syntax.s7i
3518 /Users/frgo/Downloads/seed7/lib/seed7_05.s7i
70 /Users/frgo/Downloads/seed7/lib/shell.s7i
227 chk_all.sd7
4077 lines total
239823 lines per second
1755426 bytes
compiling the compilerhi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
- okay
chkinthi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
- okay
chkstrhi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
- okay
chkprchi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
- okay
chkbighi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
- okay
chkboolhi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
- okay
chksethi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
- okay
chkexchi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
- okay
Is it now ok or is there an error ?!?!?
> When all goes well you can do
>
> ./hi panic
>
> and tell me how many monsters you have killed.
Daredevil that I am I decided to have it a go. Pacman in a
terminal. Nice game, so 20th century.
2 monsters only, though ;-)
Cheers
Frank
On 15 Mai, 14:29, Frank GOENNINGER <······@googlemail.com> wrote:
> ·············@gmx.at writes:
> > Great. To check the functionality the following program can
> > be used.
>
> > cd /Users/frgo/Downloads/seed7/prg
> > ./hi chk_all
>
> Results:
>
> ····@ccde007 ~/Downloads/seed7/prg
> $ ../src/hi chk_all
> HI INTERPRETER Version 4.5.4741 Copyright (c) 1990-2009 Thomas Mertes
> 262 /Users/frgo/Downloads/seed7/lib/syntax.s7i
> 3518 /Users/frgo/Downloads/seed7/lib/seed7_05.s7i
> 70 /Users/frgo/Downloads/seed7/lib/shell.s7i
> 227 chk_all.sd7
> 4077 lines total
> 239823 lines per second
> 1755426 bytes
> compiling the compilerhi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> - okay
> chkinthi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
...
> hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> - okay
>
> Is it now ok or is there an error ?!?!?
Good question. On other Windows/Linux/Unix computers there are no
such errors. Naturally I cannot exclude the possibility that the
errors are caused by the hi interpreter or the Seed7 library. The hi
interpreter and the Seed7 runtime library always check the return of
malloc (for != NULL). When malloc is not able to allocate memory an
exception or an error message followed by exit(), should happen.
Since the error messages above do not come from the hi interpreter
or the Seed7 runtime library they are probably generated by the Mac
OS libc. The malloc issues this errors but is probably capable to
return memory afterwards. Otherwise some Seed7 messages would have
shown up.
Googling shows that others also get this errors:
http://www.macosxhints.ch/forums/showthread.php?t=12392
http://bugs.python.org/issue2901
http://lists.macosforge.org/pipermail/macports-users/2008-April/009915.html
http://trac.macports.org/ticket/18073
http://discussions.apple.com/thread.jspa?messageID=9128509
http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=13499
All these seem to be related to Mac OS. Maybe running a check
(E.g.: chkint.sd7) alone (without being called from chk_all.sd7)
would give more information:
./hi chkint
./hi comp chkint
./chkint
This three lines start the check program for integers with the
interpreter, compile the check program and start the executable
of it. When './hi chkint' has the same output as './chkint' then
this is a hint that the malloc error messages are just to be
considered as warnings internal to the malloc function. In this
case shutting the errors would help (I don't know how to do this).
> > When all goes well you can do
>
> > ./hi panic
>
> > and tell me how many monsters you have killed.
>
> Daredevil that I am I decided to have it a go. Pacman in a
> terminal. Nice game, so 20th century.
>
> 2 monsters only, though ;-)
You need more practice.
Did you succeed landing on the moon?
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
On 15 Mai, 14:29, Frank GOENNINGER <······@googlemail.com> wrote:
> ·············@gmx.at writes:
> > Great. To check the functionality the following program can
> > be used.
>
> > cd /Users/frgo/Downloads/seed7/prg
> > ./hi chk_all
>
> Results:
>
> ····@ccde007 ~/Downloads/seed7/prg
> $ ../src/hi chk_all
> HI INTERPRETER Version 4.5.4741 Copyright (c) 1990-2009 Thomas Mertes
> 262 /Users/frgo/Downloads/seed7/lib/syntax.s7i
> 3518 /Users/frgo/Downloads/seed7/lib/seed7_05.s7i
> 70 /Users/frgo/Downloads/seed7/lib/shell.s7i
> 227 chk_all.sd7
> 4077 lines total
> 239823 lines per second
> 1755426 bytes
> compiling the compilerhi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> - okay
> chkinthi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
...
> hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> - okay
>
> Is it now ok or is there an error ?!?!?
Good question. On other Windows/Linux/Unix computers there are no
such errors. Naturally I cannot exclude the possibility that the
errors are caused by the hi interpreter or the Seed7 library. The hi
interpreter and the Seed7 runtime library always check the return of
malloc (for != NULL). When malloc is not able to allocate memory an
exception or an error message followed by exit(), should happen.
Since the error messages above do not come from the hi interpreter
or the Seed7 runtime library they are probably generated by the Mac
OS libc. The malloc issues this errors but is probably capable to
return memory afterwards. Otherwise some Seed7 messages would have
shown up.
Googling shows that others also get this errors:
http://www.macosxhints.ch/forums/showthread.php?t=12392
http://bugs.python.org/issue2901
http://lists.macosforge.org/pipermail/macports-users/2008-April/009915.html
http://trac.macports.org/ticket/18073
http://discussions.apple.com/thread.jspa?messageID=9128509
http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=13499
All these seem to be related to Mac OS. Maybe running a check
(E.g.: chkint.sd7) alone (without being called from chk_all.sd7)
would give more information:
./hi chkint
./hi comp chkint
./chkint
This three lines start the check program for integers with the
interpreter, compile the check program and start the executable
of it. When './hi chkint' has the same output as './chkint' then
this is a hint that the malloc error messages are just to be
considered as warnings internal to the malloc function. In this
case shutting the errors would help (I don't know how to do this).
> > When all goes well you can do
>
> > ./hi panic
>
> > and tell me how many monsters you have killed.
>
> Daredevil that I am I decided to have it a go. Pacman in a
> terminal. Nice game, so 20th century.
>
> 2 monsters only, though ;-)
You need more practice.
Did you succeed landing on the moon?
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
On 15 Mai, 15:38, ·············@gmx.at wrote:
> On 15 Mai, 14:29, Frank GOENNINGER <······@googlemail.com> wrote:
>
> > ·············@gmx.at writes:
> > > Great. To check the functionality the following program can
> > > be used.
>
> > > cd /Users/frgo/Downloads/seed7/prg
> > > ./hi chk_all
>
> > Results:
>
> > ····@ccde007 ~/Downloads/seed7/prg
> > $ ../src/hi chk_all
> > HI INTERPRETER Version 4.5.4741 Copyright (c) 1990-2009 Thomas Mertes
> > 262 /Users/frgo/Downloads/seed7/lib/syntax.s7i
> > 3518 /Users/frgo/Downloads/seed7/lib/seed7_05.s7i
> > 70 /Users/frgo/Downloads/seed7/lib/shell.s7i
> > 227 chk_all.sd7
> > 4077 lines total
> > 239823 lines per second
> > 1755426 bytes
> > compiling the compilerhi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> > *** error: can't allocate region
> > *** set a breakpoint in malloc_error_break to debug
> > - okay
> > chkinthi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> > *** error: can't allocate region
> > *** set a breakpoint in malloc_error_break to debug
> > hi(3598) malloc: *** mmap(size=4000002048) failed (error code=12)
> > *** error: can't allocate region
[snip]
I don't know why my message was transmitted two times, but I have an
idea how the error messages occur:
The test program (chk_all.sd7) starts other programs one by one. It
does this with popen(). The system function popen() opens a pipe and
the result of the command execution can be read from this pipe. To
read (hopefully) the whole pipe into a string the function 'gets'
is called with the request to read 999999999 characters. The Seed7
function 'gets' is implemented with the C function filGets()
(in file_rtl.c). The function filGets() is really low level (other
interpreters/librarys probably also have similar functions) and
uses several strategies to do its job. In order to work reasonable
good in the common case (reading just some characters) memory for
the requied maximum length is requested with malloc(). After the
data is read the result string is shrinked to the actual size (with
realloc). When the memory cannot be requested a different strategy
is used. In this case the function trys to find out the number of
available characters (which is possible for a regular file but not
for a pipe). If this fails also a third strategy is used. A smaller
block is requested, this block is filled with data and resized in a
loop. So it is nothing special when a malloc fails in the filGets()
function. There are alternative code paths to provide the requested
functionality.
The point is that the Mac OS malloc() complains when it is not
capable to do its job. This is not according to the specification
of malloc(). According to all definitions of malloc it should just
return NULL when it cannot allocate the requested amount of memory.
Did I mention that other operating systems did not have the
slightest problems when I tell them to malloc huge amounts of
memory. Either they deliver it or they return NULL. No performance
problem or error message.
One solution would be: Find out a way to tell Mac OS malloc()
that it should behave according to the specification (stop
complaining). Maybe there is a compiler flag, a #define a callback
function or something else. When this is not possible a work
around is necessary.
To code around this bug of Mac OS it is necessary to find out
the maximum blocksize that can be requested with malloc without
complains. Then the function filGets() could use this limit to
avoid strategy 1 and switch to strategy 2 and 3 immediate.
Hopefully I can add some fix to the next release.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: John B. Matthews
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <nospam-A7FF7A.14102615052009@news.aioe.org>
In article
<····································@z19g2000vbz.googlegroups.com>,
·············@gmx.at wrote:
[snip]
> The test program (chk_all.sd7) starts other programs one by one. It
> does this with popen(). The system function popen() opens a pipe and
> the result of the command execution can be read from this pipe. To
> read (hopefully) the whole pipe into a string the function 'gets'
> is called with the request to read 999999999 characters. The Seed7
> function 'gets' is implemented with the C function filGets()
> (in file_rtl.c). The function filGets() is really low level (other
> interpreters/librarys probably also have similar functions) and
> uses several strategies to do its job. In order to work reasonable
> good in the common case (reading just some characters) memory for
> the requied maximum length is requested with malloc(). After the
> data is read the result string is shrinked to the actual size (with
> realloc). When the memory cannot be requested a different strategy
> is used. In this case the function trys to find out the number of
> available characters (which is possible for a regular file but not
> for a pipe). If this fails also a third strategy is used. A smaller
> block is requested, this block is filled with data and resized in a
> loop. So it is nothing special when a malloc fails in the filGets()
> function. There are alternative code paths to provide the requested
> functionality.
Limiting the length to 0x1FFFFFFF (~0.5 GiB) in gets() eliminates the
warning:
$ include "seed7_05.s7i";
include "shell.s7i";
const proc: main is func
local
var file: outFile is STD_NULL;
begin
outFile := popen("./hi -q echo.sd7 echo test", "r");
writeln(gets(outFile, 16#1FFFFFFF));
end func;
There are a number of warnings when compiling fil_rtl.c, but I don't see
a connection:
fil_rtl.c: In function ‘getBigFileLengthUsingSeek’:
fil_rtl.c:263: warning: passing argument 1 of ‘bigFromUInt64’ as
unsigned due to prototype
fil_rtl.c:265: warning: passing argument 1 of ‘bigFromUInt32’ with
different width due to prototype
fil_rtl.c: In function ‘filBigLng’:
fil_rtl.c:315: warning: passing argument 1 of ‘bigFromUInt64’ as
unsigned due to prototype
fil_rtl.c:317: warning: passing argument 1 of ‘bigFromUInt32’ with
different width due to prototype
fil_rtl.c: In function ‘filBigTell’:
fil_rtl.c:389: warning: passing argument 1 of ‘bigFromUInt64’ as
unsigned due to prototype
fil_rtl.c:391: warning: passing argument 1 of ‘bigFromUInt32’ with
different width due to prototype
fil_rtl.c: In function ‘filSetbuf’:
fil_rtl.c:848: warning: passing argument 4 of ‘setvbuf’ as unsigned due
to prototype
> The point is that the Mac OS malloc() complains when it is not
> capable to do its job. This is not according to the specification
> of malloc(). According to all definitions of malloc it should just
> return NULL when it cannot allocate the requested amount of memory.
> Did I mention that other operating systems did not have the
> slightest problems when I tell them to malloc huge amounts of
> memory. Either they deliver it or they return NULL. No performance
> problem or error message.
I think it does return NULL; the helpful message appears on stderr.
> One solution would be: Find out a way to tell Mac OS malloc()
> that it should behave according to the specification (stop
> complaining). Maybe there is a compiler flag, a #define a callback
> function or something else. When this is not possible a work
> around is necessary.
Turning off the alarm still leaves one curious about the smoke:-)
> To code around this bug of Mac OS it is necessary to find out
> the maximum blocksize that can be requested with malloc without
> complains. Then the function filGets() could use this limit to
> avoid strategy 1 and switch to strategy 2 and 3 immediate.
>
> Hopefully I can add some fix to the next release.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
On 15 Mai, 20:10, "John B. Matthews" <······@nospam.invalid> wrote:
> In article
> <····································@z19g2000vbz.googlegroups.com>,
>
> ·············@gmx.at wrote:
>
> [snip]
>
> > The test program (chk_all.sd7) starts other programs one by one. It
> > does this with popen(). The system function popen() opens a pipe and
> > the result of the command execution can be read from this pipe. To
> > read (hopefully) the whole pipe into a string the function 'gets'
> > is called with the request to read 999999999 characters. The Seed7
> > function 'gets' is implemented with the C function filGets()
> > (in file_rtl.c). The function filGets() is really low level (other
> > interpreters/librarys probably also have similar functions) and
> > uses several strategies to do its job. In order to work reasonable
> > good in the common case (reading just some characters) memory for
> > the requied maximum length is requested with malloc(). After the
> > data is read the result string is shrinked to the actual size (with
> > realloc). When the memory cannot be requested a different strategy
> > is used. In this case the function trys to find out the number of
> > available characters (which is possible for a regular file but not
> > for a pipe). If this fails also a third strategy is used. A smaller
> > block is requested, this block is filled with data and resized in a
> > loop. So it is nothing special when a malloc fails in the filGets()
> > function. There are alternative code paths to provide the requested
> > functionality.
>
> Limiting the length to 0x1FFFFFFF (~0.5 GiB) in gets() eliminates the
> warning:
>
> $ include "seed7_05.s7i";
> include "shell.s7i";
>
> const proc: main is func
> local
> var file: outFile is STD_NULL;
> begin
> outFile := popen("./hi -q echo.sd7 echo test", "r");
> writeln(gets(outFile, 16#1FFFFFFF));
> end func;
Great. I will use this limit in filGets().
> There are a number of warnings when compiling fil_rtl.c, but I don't see
> a connection:
>
> fil_rtl.c: In function 'getBigFileLengthUsingSeek':
> fil_rtl.c:263: warning: passing argument 1 of 'bigFromUInt64' as
> unsigned due to prototype
> fil_rtl.c:265: warning: passing argument 1 of 'bigFromUInt32' with
> different width due to prototype
> fil_rtl.c: In function 'filBigLng':
> fil_rtl.c:315: warning: passing argument 1 of 'bigFromUInt64' as
> unsigned due to prototype
> fil_rtl.c:317: warning: passing argument 1 of 'bigFromUInt32' with
> different width due to prototype
> fil_rtl.c: In function 'filBigTell':
> fil_rtl.c:389: warning: passing argument 1 of 'bigFromUInt64' as
> unsigned due to prototype
> fil_rtl.c:391: warning: passing argument 1 of 'bigFromUInt32' with
> different width due to prototype
> fil_rtl.c: In function 'filSetbuf':
> fil_rtl.c:848: warning: passing argument 4 of 'setvbuf' as unsigned due
> to prototype
You are right: There is no connection to the malloc error.
Regarding the warnings: For some reason your C compiler is not
capable to evaluate the expression
sizeof(offsettype) == 8
at compile time. So the C compiler is complaining about things in
unreachable code. The other warnings can be avoided with casts.
I will try to remove this warnings.
BTW: Thank you for the list of warnings you sent by mail. I will
take a closer look at the list, but at first sight I consider the
warnings harmless. I will try to reduce them nevertheless.
> > The point is that the Mac OS malloc() complains when it is not
> > capable to do its job. This is not according to the specification
> > of malloc(). According to all definitions of malloc it should just
> > return NULL when it cannot allocate the requested amount of memory.
> > Did I mention that other operating systems did not have the
> > slightest problems when I tell them to malloc huge amounts of
> > memory. Either they deliver it or they return NULL. No performance
> > problem or error message.
>
> I think it does return NULL; the helpful message appears on stderr.
This supports my theory. About being helpful I have a different
view. I do not consider something, which violates the specification,
as helpful. Imagine what happens when every function decides to
write to stderr under some conditions. The programmer should know
what he/she is doing. I don't like when some library or OS thinks it
is smarter than the programmer. When functions start complaining to
stderr the program does not have the possibility to silently provide
an alternate solution.
> > One solution would be: Find out a way to tell Mac OS malloc()
> > that it should behave according to the specification (stop
> > complaining). Maybe there is a compiler flag, a #define a callback
> > function or something else. When this is not possible a work
> > around is necessary.
>
> Turning off the alarm still leaves one curious about the smoke:-)
There is no smoke. The program can choose an alternate solution
or raise an exception.
Many thanks for your help.
I still have some questions:
Do you have other ideas regarding Seed7?
Which parts of Seed7 need improvement?
Is the documentation sufficient?
Which librarys do you need when you are programming?
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Lew
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gumq8e$jlt$2@news.albasani.net>
·············@gmx.at wrote:
> BTW: Thank you for the list of warnings you sent by mail. I will
> take a closer look at the list, but at first sight I consider the
> warnings harmless. I will try to reduce them nevertheless.
Warnings are never harmless. If they were harmless, there wouldn't be any
warnings.
I've seen major bugs, in C programs and other languages, that were revealed
"only" through warnings.
The attitude that "warnings are harmless" is a major problem in the software
industry and one that needs to be stomped hard. It's nothing but
carelessness. Well, laziness. Negligence, regardless.
--
Lew
On 16 Mai, 18:39, Lew <·····@lewscanon.com> wrote:
> ·············@gmx.at wrote:
> > BTW: Thank you for the list of warnings you sent by mail. I will
> > take a closer look at the list, but at first sight I consider the
> > warnings harmless. I will try to reduce them nevertheless.
>
> Warnings are never harmless. If they were harmless, there wouldn't be any
> warnings.
I don't consider all warnings as harmless. I was referring to
specific warnings which were mailed by John B. Matthews. When
compiling with gcc (which is also used also under Mac OS X) I use
the following options to get as much warnings as possible:
-Wall -Wstrict-prototypes -Winline -Wconversion
-Wshadow -Wpointer-arith
I could have used the strategy of many other projects: Just specify
a lower warning level. But I prefer to see as much warnings as
possible. Exactly for the reason you mention below (warnings may
be a hint for real errors). Examples of warnings happening during
the compilation of the Seed7 (hi) interpreter:
drwlib.c:253: warning: passing argument 5 of 'drwArc' as 'float'
rather than 'double' due to prototype
This warnings happens every time the formal and the actual parameter
are just float instead of double. In total there are 20 such
warnings.
identutl.c:107: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness
This warning happens when a functions with a formal 'char *'
parameter gets an actual parameter of type 'unsigned char *'.
In total there are 16 such warnings.
ref_data.c:838: warning: pointer targets in assignment differ in
signedness
This warning happens when a 'char *' expression is assigned to a
'unsigned char *' variable or vice versa. In total there are 5 such
warnings.
> I've seen major bugs, in C programs and other languages, that were revealed
> "only" through warnings.
>
> The attitude that "warnings are harmless" is a major problem in the software
> industry and one that needs to be stomped hard. It's nothing but
> carelessness. Well, laziness. Negligence, regardless.
I agree. OTOH I am not sure that it is possible to get rid of all
warnings. It would be nice to get your help to examine all warnings.
To see a list of errors just download and compile the Seed7 package.
A place in the (soon to be created) hall of fame is the reward. :-)
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: John B. Matthews
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <nospam-DF2952.13422317052009@news.aioe.org>
In article
<····································@s20g2000vbp.googlegroups.com>,
·············@gmx.at wrote:
> On 16 Mai, 18:39, Lew <·····@lewscanon.com> wrote:
> > ·············@gmx.at wrote:
> > > BTW: Thank you for the list of warnings you sent by mail. I will
> > > take a closer look at the list, but at first sight I consider the
> > > warnings harmless. I will try to reduce them nevertheless.
> >
> > Warnings are never harmless. If they were harmless, there wouldn't
> > be any warnings.
>
> I don't consider all warnings as harmless. I was referring to
> specific warnings which were mailed by John B. Matthews. When
> compiling with gcc (which is also used also under Mac OS X) I use
> the following options to get as much warnings as possible:
[example warnings]
> > I've seen major bugs, in C programs and other languages, that were
> > revealed "only" through warnings.
> >
> > The attitude that "warnings are harmless" is a major problem in the
> > software industry and one that needs to be stomped hard. It's
> > nothing but carelessness. Well, laziness. Negligence, regardless.
>
> I agree. OTOH I am not sure that it is possible to get rid of all
> warnings.
The large number of warnings is confounding, although that may be a
limitation of the implicit conversions provided by the implementation
language. A later version of the compiler (4.3.4) finds more than 500
such warnings; it's hard to see a new warning when it arises.
> It would be nice to get your help to examine all warnings.
Often, that requires rather close reading of preprocessor directives,
detailed understanding of external libraries, and even trying to infer
the programmer's intent.
I look forward to upcoming releases of seed7.
For reference, the usual practice in Java is to limit the warning to
the narrowest possible scope and (often) to denote why it may be
irrelevant. For example, a widening primitive conversion might be
safely ignored [1]. In contrast, a narrowing primitive conversion must
be given an explicit cast to preclude a compile-time error [1].
Finally, a genuinely harmless warning may be suppressed by the
annotation @SuppressWarnings [2, 3].
[1]<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html>
[2]<http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html>
[3]Chapter 5, item 24:<http://java.sun.com/docs/books/effective/>
[...]
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
On 17 Mai, 19:42, "John B. Matthews" <······@nospam.invalid> wrote:
> In article
> <····································@s20g2000vbp.googlegroups.com>,
> ·············@gmx.at wrote:
> > On 16 Mai, 18:39, Lew <·····@lewscanon.com> wrote:
> > > ·············@gmx.at wrote:
> > > > BTW: Thank you for the list of warnings you sent by mail. I will
> > > > take a closer look at the list, but at first sight I consider the
> > > > warnings harmless. I will try to reduce them nevertheless.
>
> > > Warnings are never harmless. If they were harmless, there wouldn't
> > > be any warnings.
>
> > I don't consider all warnings as harmless. I was referring to
> > specific warnings which were mailed by John B. Matthews. When
> > compiling with gcc (which is also used also under Mac OS X) I use
> > the following options to get as much warnings as possible:
> [example warnings]
> > > I've seen major bugs, in C programs and other languages, that were
> > > revealed "only" through warnings.
>
> > > The attitude that "warnings are harmless" is a major problem in the
> > > software industry and one that needs to be stomped hard. It's
> > > nothing but carelessness. Well, laziness. Negligence, regardless.
>
> > I agree. OTOH I am not sure that it is possible to get rid of all
> > warnings.
>
> The large number of warnings is confounding, although that may be a
> limitation of the implicit conversions provided by the implementation
> language. A later version of the compiler (4.3.4) finds more than 500
> such warnings; it's hard to see a new warning when it arises.
>
> > It would be nice to get your help to examine all warnings.
>
> Often, that requires rather close reading of preprocessor directives,
> detailed understanding of external libraries, and even trying to infer
> the programmer's intent.
>
> I look forward to upcoming releases of seed7.
I just released seed7_05_20090524.tgz. :-)
In the function filGets I used your limit of 0.5 MB.
Maybe I will reduce this limit further, since big mallocs
which are later realloced to something small may have
a negative impact on the heap structure.
I did many changes to reduce the number of C warnings, but
there are still some of them. Since I don't have gcc 4.3.4 it
would be helpful to get a List of its warnings.
Thanks in advance for your efforts.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
On 25 Mai, 10:59, ·············@gmx.at wrote:
> In the function filGets I used your limit of 0.5 MB.
I actually use your limit of 0x1FFFFFFF.
So it is ~0.5 GiB not 0.5 MB.
Sorry for the typo.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Dimiter "malkia" Stanev
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gvkbhs$iqg$1@malkia.motzarella.org>
·············@gmx.at wrote:
> On 25 Mai, 10:59, ·············@gmx.at wrote:
>> In the function filGets I used your limit of 0.5 MB.
>
> I actually use your limit of 0x1FFFFFFF.
> So it is ~0.5 GiB not 0.5 MB.
> Sorry for the typo.
>
> Greetings Thomas Mertes
>
> Seed7 Homepage: http://seed7.sourceforge.net
> Seed7 - The extensible programming language: User defined statements
> and operators, abstract data types, templates without special
> syntax, OO with interfaces and multiple dispatch, statically typed,
> interpreted or compiled, portable, runs under linux/unix/windows.
FYI: Vista 64 with seed7, VS2008, HP Z800 Workstation 6GB RAM
D:\p\seed7\prg>d:\cygwin\bin\time -p ..\src\hi chk_all.sd7
HI INTERPRETER Version 4.5.4853 Copyright (c) 1990-2009 Thomas Mertes
262 D:/p/seed7/lib/syntax.s7i
3518 D:/p/seed7/lib/seed7_05.s7i
70 D:/p/seed7/lib/shell.s7i
227 chk_all.sd7
4077 lines total
271800 lines per second
1755374 bytes
compiling the compiler - okay
chkint - okay
chkstr - okay
chkprc - okay
chkbig - okay
chkbool - okay
chkset - okay
chkexc - okay
real 17.59
user 0.00
sys 0.10
On 27 Mai, 23:32, "Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
> ·············@gmx.at wrote:
> > On 25 Mai, 10:59, ·············@gmx.at wrote:
> >> In the function filGets I used your limit of 0.5 MB.
>
> > I actually use your limit of 0x1FFFFFFF.
> > So it is ~0.5 GiB not 0.5 MB.
> > Sorry for the typo.
>
> > Greetings Thomas Mertes
>
> > Seed7 Homepage: http://seed7.sourceforge.net
> > Seed7 - The extensible programming language: User defined statements
> > and operators, abstract data types, templates without special
> > syntax, OO with interfaces and multiple dispatch, statically typed,
> > interpreted or compiled, portable, runs under linux/unix/windows.
>
> FYI: Vista 64 with seed7, VS2008, HP Z800 Workstation 6GB RAM
>
> D:\p\seed7\prg>d:\cygwin\bin\time -p ..\src\hi chk_all.sd7
>
> HI INTERPRETER Version 4.5.4853 Copyright (c) 1990-2009 Thomas Mertes
> 262 D:/p/seed7/lib/syntax.s7i
> 3518 D:/p/seed7/lib/seed7_05.s7i
> 70 D:/p/seed7/lib/shell.s7i
> 227 chk_all.sd7
> 4077 lines total
> 271800 lines per second
> 1755374 bytes
> compiling the compiler - okay
> chkint - okay
> chkstr - okay
> chkprc - okay
> chkbig - okay
> chkbool - okay
> chkset - okay
> chkexc - okay
>
> real 17.59
> user 0.00
> sys 0.10
Great. Good to know that Seed7 works also under Vista.
Which compiler and which makefile did you use?
Have you tried some of the example programs?
When you write a Seed7 program just ask me for support.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: John B. Matthews
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <nospam-7E4AC7.09571225052009@news.aioe.org>
In article
<····································@q16g2000yqg.googlegroups.com>,
·············@gmx.at wrote:
> On 17 Mai, 19:42, "John B. Matthews" <······@nospam.invalid> wrote:
[...]
> > I look forward to upcoming releases of seed7.
>
> I just released seed7_05_20090524.tgz. :-)
> In the function filGets I used your limit of 0.5 [GiB].
> Maybe I will reduce this limit further, since big mallocs
> which are later realloced to something small may have
> a negative impact on the heap structure.
>
> I did many changes to reduce the number of C warnings, but
> there are still some of them. Since I don't have gcc 4.3.4 it
> would be helpful to get a List of its warnings.
>
> Thanks in advance for your efforts.
The new gets limit appears to be effective. For reference: compiling
seed7_05_20090524 on Mac OS X 10.5.7, using gcc version 4.0.1 (Apple
Inc. build 5490), I obtained 75 warnings [emailed]. This is about half
of the number in the previous version. In contrast, gcc version 4.3.4
20090225 (prerelease) offers 482 warnings [emailed].
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
On 25 Mai, 15:57, "John B. Matthews" <······@nospam.invalid> wrote:
> In article
> <····································@q16g2000yqg.googlegroups.com>,
>
>
>
>
>
> ·············@gmx.at wrote:
> > On 17 Mai, 19:42, "John B. Matthews" <······@nospam.invalid> wrote:
> [...]
> > > I look forward to upcoming releases of seed7.
>
> > I just released seed7_05_20090524.tgz. :-)
> > In the function filGets I used your limit of 0.5 [GiB].
> > Maybe I will reduce this limit further, since big mallocs
> > which are later realloced to something small may have
> > a negative impact on the heap structure.
>
> > I did many changes to reduce the number of C warnings, but
> > there are still some of them. Since I don't have gcc 4.3.4 it
> > would be helpful to get a List of its warnings.
>
> > Thanks in advance for your efforts.
>
> The new gets limit appears to be effective. For reference: compiling
> seed7_05_20090524 on Mac OS X 10.5.7, using gcc version 4.0.1 (Apple
> Inc. build 5490), I obtained 75 warnings [emailed]. This is about half
> of the number in the previous version. In contrast, gcc version 4.3.4
> 20090225 (prerelease) offers 482 warnings [emailed].
Thank you very much for the list of warnings. I used it to reduce the
number of warnings in the new release (seed7_05_20090607.tgz).
It would be nice to get your assistance again.
Can you repeat the test and send me a list of C warnings
produced by the new release?
Thanks in advance for your efforts.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: John B. Matthews
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <nospam-10DCB5.09560808062009@news.aioe.org>
In article
<····································@h28g2000yqd.googlegroups.com>,
·············@gmx.at wrote:
> On 25 Mai, 15:57, "John B. Matthews" <······@nospam.invalid> wrote:
> > In article
> > <····································@q16g2000yqg.googlegroups.com>,
> > ·············@gmx.at wrote:
> > > On 17 Mai, 19:42, "John B. Matthews" <······@nospam.invalid> wrote:
[...]
> > The new gets limit appears to be effective. For reference:
> > compiling seed7_05_20090524 on Mac OS X 10.5.7, using gcc version
> > 4.0.1 (Apple Inc. build 5490), I obtained 75 warnings [emailed].
> > This is about half of the number in the previous version. In
> > contrast, gcc version 4.3.4 20090225 (prerelease) offers 482
> > warnings [emailed].
>
> Thank you very much for the list of warnings. I used it to reduce the
> number of warnings in the new release (seed7_05_20090607.tgz).
>
> It would be nice to get your assistance again. Can you repeat the
> test and send me a list of C warnings produced by the new release?
>
> Thanks in advance for your efforts.
You've got mail, albeit smaller than last time. :-)
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: Dimiter "malkia" Stanev
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gvkb7t$g4v$1@malkia.motzarella.org>
Lew wrote:
> ·············@gmx.at wrote:
>> BTW: Thank you for the list of warnings you sent by mail. I will
>> take a closer look at the list, but at first sight I consider the
>> warnings harmless. I will try to reduce them nevertheless.
>
> Warnings are never harmless. If they were harmless, there wouldn't be
> any warnings.
TRUE! Then again talk about moving all your Visual Studio 2003 -> 2005
or 2008 and having the CRT complain about every standard "C" library
function :)
Would it get fixed (e.g. fopen_s instead of fopen). I guess NO! It's
still not safe even with fopen_s...
And now Microsoft are going to abolish the memcpy (memset?) functions...
WTF?
But in general - YES - In my regular job (www.treyarch.com) - we enforce
every warning to be an error - only couple of exclusions - usually for
3rd party source code, used only by the internal tools.
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87my8yb4lg.fsf@blp.benpfaff.org>
Lew <·····@lewscanon.com> writes:
> Warnings are never harmless. If they were harmless, there wouldn't be
> any warnings.
Nonsense. If warnings always indicated a real problem, then
there would be no need for compiler options to enable and disable
them.
--
Ben Pfaff
http://benpfaff.org
From: John B. Matthews
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <nospam-2142DA.21085228052009@news.aioe.org>
In article <··············@blp.benpfaff.org>,
Ben Pfaff <···@cs.stanford.edu> wrote:
> Lew <·····@lewscanon.com> writes:
>
> > Warnings are never harmless. If they were harmless, there wouldn't
> > be any warnings.
>
> Nonsense. If warnings always indicated a real problem, then there
> would be no need for compiler options to enable and disable them.
I must demur. Warnings always indicate the potential for harm.
Additional analysis is required to determine if that potential applies
to a particular usage. In this case, control over warnings at the level
of the compilation unit is an artifact of the development language and
implementation. The author prudently enables most warnings, eliminating
them when possible. When an anomaly was recently observed, it was the
author's familiarity with the source that allowed him to dismiss the
remaining warnings as likely culprits and address the matter directly.
Another developer maintaining the code would surely prefer as few
warnings as possible, compiler options notwithstanding.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87r5y88za1.fsf@blp.benpfaff.org>
"John B. Matthews" <······@nospam.invalid> writes:
> In article <··············@blp.benpfaff.org>,
> Ben Pfaff <···@cs.stanford.edu> wrote:
>
>> Lew <·····@lewscanon.com> writes:
>>
>> > Warnings are never harmless. If they were harmless, there wouldn't
>> > be any warnings.
>>
>> Nonsense. If warnings always indicated a real problem, then there
>> would be no need for compiler options to enable and disable them.
>
> I must demur. Warnings always indicate the potential for harm.
Potential for harm, perhaps. Actual harm, no. I read Lew's
claim as the latter.
--
Ben Pfaff
http://benpfaff.org
From: John B. Matthews
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <nospam-B8B1D7.07554429052009@news.aioe.org>
In article <··············@blp.benpfaff.org>,
Ben Pfaff <···@cs.stanford.edu> wrote:
> "John B. Matthews" <······@nospam.invalid> writes:
>
> > In article <··············@blp.benpfaff.org>,
> > Ben Pfaff <···@cs.stanford.edu> wrote:
> >
> >> Lew <·····@lewscanon.com> writes:
> >>
> >> > Warnings are never harmless. If they were harmless, there wouldn't
> >> > be any warnings.
> >>
> >> Nonsense. If warnings always indicated a real problem, then there
> >> would be no need for compiler options to enable and disable them.
> >
> > I must demur. Warnings always indicate the potential for harm.
>
> Potential for harm, perhaps. Actual harm, no. I read Lew's
> claim as the latter.
Ah, I read the statement as a universal negative: No warning is
harmless; you inferred the equivalent obverse: all warnings are harmful.
Harm may be difficult to quantify, and I maintain that the measure of
harm requires some analysis. Whether a particular warning is ignored or
cured, the burden of documenting the decision falls to the programmer.
Stuart & Richard Heathfield informatively discuss a concrete example in
this thread.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <NKidnST02qoo44LXnZ2dnUVZ8r2dnZ2d@bt.com>
John B. Matthews said:
> In article <··············@blp.benpfaff.org>,
> Ben Pfaff <···@cs.stanford.edu> wrote:
>
>> Lew <·····@lewscanon.com> writes:
>>
>> > Warnings are never harmless. If they were harmless, there
>> > wouldn't be any warnings.
>>
>> Nonsense. If warnings always indicated a real problem, then
>> there would be no need for compiler options to enable and disable
>> them.
>
> I must demur. Warnings always indicate the potential for harm.
Please explain the potential for harm in:
struct tm foo = {0};
that causes this message:
foo.c:6: warning: missing initializer
foo.c:6: warning: (near initialization for `foo.tm_min')
and which vanishes when the code is changed to:
struct tm foo = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
which has precisely the same meaning as the prior code *except
that*, if for some reason the definition of foo changes to add more
fields, the former code does not need to be changed, and is
therefore superior.
> Additional analysis is required to determine if that potential
> applies to a particular usage.
Please explain *any* circumstance in which struct structname = {0};
justifies the diagnostic message (above) that GCC generates for it.
Mostly I agree with your position, but some compilers, by generating
rather silly warnings in some circumstances, make it very difficult
to agree with you completely.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
From: Kaz Kylheku
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <20090610033142.875@gmail.com>
On 2009-05-29, Richard Heathfield <···@see.sig.invalid> wrote:
> John B. Matthews said:
>> I must demur. Warnings always indicate the potential for harm.
>
> Please explain the potential for harm in:
>
> struct tm foo = {0};
>
> that causes this message:
>
> foo.c:6: warning: missing initializer
> foo.c:6: warning: (near initialization for `foo.tm_min')
>
> and which vanishes when the code is changed to:
>
> struct tm foo = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
... and then the DS9K compiler has a warning for this one:
foo.c:6: warning: silly initializer, use {0).
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <WoCdnRxUMdogfoLXnZ2dnUVZ8rFi4p2d@bt.com>
Kaz Kylheku said:
> On 2009-05-29, Richard Heathfield <···@see.sig.invalid> wrote:
>> John B. Matthews said:
>>> I must demur. Warnings always indicate the potential for harm.
>>
>> Please explain the potential for harm in:
>>
>> struct tm foo = {0};
>>
>> that causes this message:
>>
>> foo.c:6: warning: missing initializer
>> foo.c:6: warning: (near initialization for `foo.tm_min')
>>
>> and which vanishes when the code is changed to:
>>
>> struct tm foo = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
>
> ... and then the DS9K compiler has a warning for this one:
>
> foo.c:6: warning: silly initializer, use {0).
Um, quite so. Having played the game of "keep ALL compilers happy",
I decided that not only could I not win it, but I couldn't even
break even. Personally, I wish they would all introduce a
diagnostic mode, say -minimalist or -W0 or whatever, which showed
*all* required diagnostic messages and *no* others. I wouldn't
always use such a mode (personally, I find some of the
non-mandatory messages very useful indeed), but I would certainly
find use for it on many occasions.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Fri, 29 May 2009 06:26:29 +0000, Richard Heathfield wrote:
> John B. Matthews said:
>
>> In article <··············@blp.benpfaff.org>,
>> Ben Pfaff <···@cs.stanford.edu> wrote:
>>
>>> Lew <·····@lewscanon.com> writes:
>>
>> I must demur. Warnings always indicate the potential for harm.
>
> Please explain the potential for harm in:
>
> struct tm foo = {0};
>
> that causes this message:
>
> foo.c:6: warning: missing initializer foo.c:6: warning: (near
> initialization for `foo.tm_min')
>
> and which vanishes when the code is changed to:
>
> struct tm foo = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
>
> which has precisely the same meaning as the prior code *except that*, if
> for some reason the definition of foo changes to add more fields, the
> former code does not need to be changed, and is therefore superior.
>
>> Additional analysis is required to determine if that potential applies
>> to a particular usage.
>
> Please explain *any* circumstance in which struct structname = {0};
> justifies the diagnostic message (above) that GCC generates for it.
>
> Mostly I agree with your position, but some compilers, by generating
> rather silly warnings in some circumstances, make it very difficult to
> agree with you completely.
Some warnings, like the one above can be a nuisance.
Another one which is mostly harmless is:
for (cnt=0; cp = fgets(buff, sizeof buff, fp); cnt++) {}
-->> warning: suggest parentheses around assignment used as truth value
Well, there *could* be cases where this warning is wanted.
I don't like excessive parentheses either.
AvK
On 30 May, 13:46, Moi <····@invalid.address.org> wrote:
<snip>
> Some warnings, like the one above can be a nuisance.
> Another one which is mostly harmless is:
>
> for (cnt=0; cp = fgets(buff, sizeof buff, fp); cnt++) {}
>
> -->> warning: suggest parentheses around assignment used as truth value
>
> Well, there *could* be cases where this warning is wanted.
> I don't like excessive parentheses either.
yes but most of us have made the mistake of using = for ==.
I even went though a later phase of using == for =!
I consider that C made a poor choice when selecting these
operators
assignment is :=
equality is =
--
Nick Keighley
"ALGOL 60 was a language so far ahead of its time that it
was not only an improvement on its predecessors but also
on nearly all its successors".
--C.A.R. Hoare
On 1 Jun., 11:13, ····················@hotmail.com wrote:
> On 30 May, 13:46, Moi <····@invalid.address.org> wrote:
>
> <snip>
>
> > Some warnings, like the one above can be a nuisance.
> > Another one which is mostly harmless is:
>
> > for (cnt=0; cp = fgets(buff, sizeof buff, fp); cnt++) {}
>
> > -->> warning: suggest parentheses around assignment used as truth value
>
> > Well, there *could* be cases where this warning is wanted.
> > I don't like excessive parentheses either.
>
> yes but most of us have made the mistake of using = for ==.
> I even went though a later phase of using == for =!
> I consider that C made a poor choice when selecting these
> operators
>
> assignment is :=
> equality is =
This is one thing and the other thing is:
The habbit of silently ignoring values.
While it can have an advantage that assignments return
a value it can also have disadvantages. Sure when
assignments just return void some "elegant" code needs
to be written in a longer way, but at least some errors like
the one mentioned above do not happen.
Therefore I prefer assignments without result and no
implicit casts (like a cast to void which just ignores a
value).
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Stuart
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4a1f957b$1_1@glkas0286.greenlnk.net>
"Richard Heathfield" <···@see.sig.invalid> wrote in message
·····································@bt.com...
> John B. Matthews said:
>
>> In article <··············@blp.benpfaff.org>,
>> Ben Pfaff <···@cs.stanford.edu> wrote:
>>
>>> Lew <·····@lewscanon.com> writes:
>>>
>>> > Warnings are never harmless. If they were harmless, there
>>> > wouldn't be any warnings.
>>>
>>> Nonsense. If warnings always indicated a real problem, then
>>> there would be no need for compiler options to enable and disable
>>> them.
>>
>> I must demur. Warnings always indicate the potential for harm.
>
> Please explain the potential for harm in:
>
> struct tm foo = {0};
>
> that causes this message:
>
> foo.c:6: warning: missing initializer
> foo.c:6: warning: (near initialization for `foo.tm_min')
>
> and which vanishes when the code is changed to:
>
> struct tm foo = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
>
> which has precisely the same meaning as the prior code *except
> that*, if for some reason the definition of foo changes to add more
> fields, the former code does not need to be changed, and is
> therefore superior.
>
>> Additional analysis is required to determine if that potential
>> applies to a particular usage.
>
> Please explain *any* circumstance in which struct structname = {0};
> justifies the diagnostic message (above) that GCC generates for it.
>
> Mostly I agree with your position, but some compilers, by generating
> rather silly warnings in some circumstances, make it very difficult
> to agree with you completely.
Not all would agree that it is superior. If additional fields are added to
foo some [particularly those in the high-integrity domain] consider it
prudent to review assignments to a structure (particularly initializations).
Having the compiler nag you if you have overlooked some case buried deep
within your code is considered a 'superior' code design.
In the first type of initialization it is not clear whether the author's
understanding of foo matches the current definition of foo (i.e. whether any
additional fields have been added). [The warning might be better expressed
though].
In the second case it would be obvious whether there is a mismatch and the
compiler need only issue a message if the code is clearly wrong.
Where code does lead to nuisance warnings [for instance where the design
constraints of foo will _always_ require it to be initialized to 0, and
there is a high expectation that foo will continually change during the life
of the code, so the first form of initialiation is desirable], a method for
coping with this is to annotate the code (at the point the warning would be
raised) to explain the warning and justify why it is appropriate to
disregard it. Some developers even have tools to automatically filter such
warnings (comparing the warnings of a new build with those expected for any
build).
I expect this sounds like an awful lot of fuss for a great many
programmers - but for some it is a way of life!
Regards
Stuart
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <p-GdndqgweKNMoLXnZ2dnUVZ8n2dnZ2d@bt.com>
Stuart said:
<snip>
> Not all would agree that [ = {0} ] is superior [ to = { 0, 0, 0,
> 0, 0, ... } ]. If additional fields are
> added to foo some [particularly those in the high-integrity
> domain] consider it prudent to review assignments to a structure
> (particularly initializations). Having the compiler nag you if you
> have overlooked some case buried deep within your code is
> considered a 'superior' code design.
Well, you got me there. I don't agree with you, but I do agree that
you have a defensible position!
> In the first type of initialization it is not clear whether the
> author's understanding of foo matches the current definition of
> foo (i.e. whether any additional fields have been added). [The
> warning might be better expressed though].
Good modularisation makes it reasonably easy to ensure that one has
dealt with all the ramifications of adding a member to a struct.
(Irrelevant aside: I had the devil's own job stopping that sentence
from ending with a preposition; I eventually solved it by changing
from the passive voice to the active.)
> In the second case it would be obvious whether there is a mismatch
> and the compiler need only issue a message if the code is clearly
> wrong.
If zero-initialisation is required, = {0} does the trick elegantly
and well. The only reason this wouldn't Do The Right Thing is if
some fields were required to be initialised to non-zero values.
I favour blanket zero-initialisation followed by specific
assignments to members not because I like to make work for myself,
but because - as you say - new members might be added, and this can
introduce bugs. Consider:
struct foo { int height; int weight; int shoesize; int quux; int
quuux; int quuuux; };
struct foo bar = { 190, 81, 12, 0, 0, 0 };
(My imagination failed for the names of the last three fields, but
basically they represent any old fields that need starting values
of 0.)
Now we maintain the struct:
struct foo { int height; int weight; int iq; int shoesize; int quux;
int quuux; int quuuux; };
and we maintain the initialisation, with the intent of inserting 115
as the IQ (might be a teacher, or a police officer, or a council
official - how many readers have I just offended, I wonder?):
struct foo bar = { 190, 115, 81, 12, 0, 0, 0 };
We've put this in the wrong place, but the compiler won't tell us
that. Far better to do this:
struct foo bar = {0};
bar.height = 190;
bar.weight = 81;
bar.shoesize = 12;
bar.iq = 115; /* rjh, 29/5/2009, Change Request 2139707B */
That way, every value is associated directly with the name of the
member, making it easier to get things right.
(The blanket initialisation covers quux, quuux, and quuuux. If they
require non-zero values, those can be added to the list.)
C99 allows us to do something similar within the struct initialiser
itself:
struct foo bar = { .height = 190, .weight = 81, .iq = 115, .shoesize
= 12, 0, 0, 0 };
which is fine provided we remember that any undesignated
initialisers that follow a designated initialiser will not "jump
back" to fill in the gaps (any members in such gaps will be
zero-initialised in the absence of any other initialisation within
a part-initialisation), so it's still possible to screw this up:
struct foo bar = { .height = 190, 81, 12};
struct foo bar = { .height = 190, .iq = 115, 81, 12 };
which gives us a shoesize of 81 and a weight of 0. Here, it is
possible that full initialisation might save you by giving you a
diagnostic message:
struct foo bar = { .height = 190, .iq = 115, 81, 12, 0, 0, 0 };
It would surprise me if this code were not to generate a diagnostic
message for "too many initializers", but I can't immediately prove
from the Standard that it must (I'm not particularly familiar with
C99, and don't even have a C99 compiler).
And of course this technique does depend on your having a C99
compiler (or a compiler that includes some C99 features).
So, in the continuing absence of C99, my own preferred method is
blanket initialisation followed by explicit assignment to named
members. It would be silly to get religious about it, but as a
general guideline I find it helpful.
> Where code does lead to nuisance warnings [for instance where the
> design
> constraints of foo will _always_ require it to be initialized to
> 0, and there is a high expectation that foo will continually
> change during the life of the code, so the first form of
> initialiation is desirable], a method for coping with this is to
> annotate the code (at the point the warning would be raised) to
> explain the warning and justify why it is appropriate to
> disregard it.
Which is pretty much what I do (although the one about missing
initialisers is so common in my code that I don't even see those
warnings any more unless I'm really concentrating!).
> Some developers even have tools to automatically
> filter such warnings (comparing the warnings of a new build with
> those expected for any build).
I have worked in such environments, and found it a good way to do
things.
> I expect this sounds like an awful lot of fuss for a great many
> programmers - but for some it is a way of life!
In places where it's done, it's routine and nobody bats an eyelid.
In places where it isn't done, proposing its introduction will
normally earn you nothing more than a blank look from your PHB.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
From: Stuart
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4a1fbbe7$1_1@glkas0286.greenlnk.net>
"Richard Heathfield" <···@see.sig.invalid> wrote in message
·····································@bt.com...
> Stuart said:
>
> <snip>
>
>> Not all would agree that [ = {0} ] is superior [ to = { 0, 0, 0,
>> 0, 0, ... } ]. If additional fields are
>> added to foo some [particularly those in the high-integrity
>> domain] consider it prudent to review assignments to a structure
>> (particularly initializations). Having the compiler nag you if you
>> have overlooked some case buried deep within your code is
>> considered a 'superior' code design.
>
> Well, you got me there. I don't agree with you, but I do agree that
> you have a defensible position!
>
>> In the first type of initialization it is not clear whether the
>> author's understanding of foo matches the current definition of
>> foo (i.e. whether any additional fields have been added). [The
>> warning might be better expressed though].
>
> Good modularisation makes it reasonably easy to ensure that one has
> dealt with all the ramifications of adding a member to a struct.
<snip>
I agree with using good modularization as a primary way of managing
complexity and maintenance of programs. Even so, some choices over the way
in which some things are done (such as structure initialization) can
maximise the 'help' you get from a compiler in spotting mistakes in your
code at the expense of a 'little' extra effort in writing the code. If a
program was proving difficult to maintain because small changes were leading
to a lot of 'knock-on' effects, that may be an indication that the original
design is not properly modularized and abstracted.
>> In the second case it would be obvious whether there is a mismatch
>> and the compiler need only issue a message if the code is clearly
>> wrong.
>
> If zero-initialisation is required, = {0} does the trick elegantly
> and well. The only reason this wouldn't Do The Right Thing is if
> some fields were required to be initialised to non-zero values.
> I favour blanket zero-initialisation followed by specific
> assignments to members not because I like to make work for myself,
> but because - as you say - new members might be added, and this can
> introduce bugs.
The difficulty is whether you (or the compiler) can be certain that you have
performed all the necessary non-zero assignments. In the domain I work in
the general recommendation is to assign to complete structures (rather than
to individual fileds) where possible and avoid the use of default cases
(which might not be valid in an extension).
> Consider:
>
> struct foo { int height; int weight; int shoesize; int quux; int
> quuux; int quuuux; };
>
> struct foo bar = { 190, 81, 12, 0, 0, 0 };
>
> (My imagination failed for the names of the last three fields, but
> basically they represent any old fields that need starting values
> of 0.)
>
> Now we maintain the struct:
>
> struct foo { int height; int weight; int iq; int shoesize; int quux;
> int quuux; int quuuux; };
>
> and we maintain the initialisation, with the intent of inserting 115
> as the IQ (might be a teacher, or a police officer, or a council
> official - how many readers have I just offended, I wonder?):
>
> struct foo bar = { 190, 115, 81, 12, 0, 0, 0 };
>
> We've put this in the wrong place, but the compiler won't tell us
> that. Far better to do this:
>
> struct foo bar = {0};
> bar.height = 190;
> bar.weight = 81;
> bar.shoesize = 12;
> bar.iq = 115; /* rjh, 29/5/2009, Change Request 2139707B */
>
> That way, every value is associated directly with the name of the
> member, making it easier to get things right.
>
> C99 allows us to do something similar within the struct initialiser
> itself:
>
> struct foo bar = { .height = 190, .weight = 81, .iq = 115, .shoesize
> = 12, 0, 0, 0 };
>
> which is fine provided we remember that any undesignated
> initialisers that follow a designated initialiser will not "jump
> back" to fill in the gaps (any members in such gaps will be
> zero-initialised in the absence of any other initialisation within
> a part-initialisation), so it's still possible to screw this up:
>
> struct foo bar = { .height = 190, 81, 12};
> struct foo bar = { .height = 190, .iq = 115, 81, 12 };
>
> which gives us a shoesize of 81 and a weight of 0. Here, it is
> possible that full initialisation might save you by giving you a
> diagnostic message:
>
> struct foo bar = { .height = 190, .iq = 115, 81, 12, 0, 0, 0 };
Well that would be why I prefer Ada with its named association in aggregates
;-)
Bar : Foo := (height => 190, iq => 115, weight => 81, shoesize => 81,
...);
it does not matter about the order and it has strict rules about ambiguity
caused by mixing named and positional values (in array aggregates and
sub-program calls).
> It would surprise me if this code were not to generate a diagnostic
> message for "too many initializers", but I can't immediately prove
> from the Standard that it must (I'm not particularly familiar with
> C99, and don't even have a C99 compiler).
Perhaps someone else might chip in!
> And of course this technique does depend on your having a C99
> compiler (or a compiler that includes some C99 features).
Or avoiding C and using something much more robust like Ada ;-)
> So, in the continuing absence of C99, my own preferred method is
> blanket initialisation followed by explicit assignment to named
> members. It would be silly to get religious about it, but as a
> general guideline I find it helpful.
I agree that it is silly to get religious about it, I have had to fight
several battles where people have interpreted generally good advice
[applicable to general design] as an absolute rule. A classic in Ada is the
prohibition on Unchecked_Conversion - a language feature which has very
practical use in specific cases but is not something you want to see
peppered throughout the code (as it circumvents the strong typing of Ada).
Unfortunately it often gets a 'universal ban'.
My main purpose in raising the point was to present a different viewpoint.
People need to make informed decisions that best meet the needs of their
programme.
Regards
--
Stuart
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <q7udnfzxHdL-WYLXnZ2dnUVZ8i-dnZ2d@bt.com>
Stuart said:
<snip>
> The difficulty is whether you (or the compiler) can be certain
> that you have performed all the necessary non-zero assignments.
I don't think it's possible for the compiler to tell, unless you've
installed the Telepathy plug-in.
<snip>
>> And of course this technique [designated initializers]
>> does depend on your having a C99
>> compiler (or a compiler that includes some C99 features).
>
> Or avoiding C and using something much more robust like Ada ;-)
Now now... language wars > /dev/null please!
<snip>
> My main purpose in raising the point was to present a different
> viewpoint. People need to make informed decisions that best meet
> the needs of their programme.
I think you've done that admirably well, and yes they do (but all
too often, no they don't!).
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gvp07r$uqd$2@news.eternal-september.org>
Richard Heathfield wrote:
> Stuart said:
[missing attribution, to Richard I think]
>>> And of course this technique [designated initializers]
>>> does depend on your having a C99
>>> compiler (or a compiler that includes some C99 features).
>> Or avoiding C and using something much more robust like Ada ;-)
>
> Now now... language wars > /dev/null please!
It's far, far too late for that my friend.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gvp06h$uqd$1@news.eternal-september.org>
Stuart wrote:
> Where code does lead to nuisance warnings [for instance where the design
> constraints of foo will _always_ require it to be initialized to 0, and
> there is a high expectation that foo will continually change during the life
> of the code, so the first form of initialiation is desirable], a method for
> coping with this is to annotate the code (at the point the warning would be
> raised) to explain the warning and justify why it is appropriate to
> disregard it.
Alternatively, one could avoid the issue entirely with struct tm *foo =
calloc(sizeof(struct tm)), albeit having to replace tm.bar with tm->bar
elsewhere in the code.
> Some developers even have tools to automatically filter such warnings
> (comparing the warnings of a new build with those expected for any build).
>
> I expect this sounds like an awful lot of fuss for a great many programmers
> - but for some it is a way of life!
How unfortunate.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <lbKdnUK2tLD4jr3XnZ2dnUVZ8iFi4p2d@bt.com>
Seamus MacRae said:
> Stuart wrote:
>> Where code does lead to nuisance warnings [for instance where the
>> design
>> constraints of foo will _always_ require it to be initialized to
>> 0, and there is a high expectation that foo will continually
>> change during the life of the code, so the first form of
>> initialiation is desirable], a method for coping with this is to
>> annotate the code (at the point the warning would be raised) to
>> explain the warning and justify why it is appropriate to
>> disregard it.
>
> Alternatively, one could avoid the issue entirely with struct tm
> *foo = calloc(sizeof(struct tm)), albeit having to replace tm.bar
> with tm->bar elsewhere in the code.
Firstly, the preferred idiom is:
struct tm *foo = calloc(sizeof *foo);
which (for all types other than void *, for which sizeof is a bit
pointless anyway) survives a foo type change without editing.
Secondly, although all-bits-zero does indeed represent 0.0 or NULL
on many platforms, it is not guaranteed by the C Standard so to do.
Those who must cater for unusual platforms cannot necessarily rely
on calloc to initialise all members to 0-of-the-correct-type for
them.
>> Some developers even have tools to automatically filter such
>> warnings (comparing the warnings of a new build with those
>> expected for any build).
>>
>> I expect this sounds like an awful lot of fuss for a great many
>> programmers - but for some it is a way of life!
>
> How unfortunate.
I've worked in environments like that, and found it quite workable.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
From: Ben Bacarisse
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87eiu76ado.fsf@bsb.me.uk>
Richard Heathfield <···@see.sig.invalid> writes:
<snip>
>> Alternatively, one could avoid the issue entirely with struct tm
>> *foo = calloc(sizeof(struct tm)), albeit having to replace tm.bar
>> with tm->bar elsewhere in the code.
>
> Firstly, the preferred idiom is:
>
> struct tm *foo = calloc(sizeof *foo);
Nit-pick: I think you mean
struct tm *foo = calloc(1, sizeof *foo);
--
Ben.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <MYWdnboGP7QDyb3XnZ2dnUVZ8uGdnZ2d@bt.com>
Ben Bacarisse said:
> Richard Heathfield <···@see.sig.invalid> writes:
> <snip>
>>> Alternatively, one could avoid the issue entirely with struct tm
>>> *foo = calloc(sizeof(struct tm)), albeit having to replace
>>> tm.bar with tm->bar elsewhere in the code.
>>
>> Firstly, the preferred idiom is:
>>
>> struct tm *foo = calloc(sizeof *foo);
>
> Nit-pick: I think you mean
>
> struct tm *foo = calloc(1, sizeof *foo);
Thanks. I hardly ever call oc, so (as I'm sure you guessed) the
above is basically an accidental conflation with malloc. The
message, however, is the same - sizeof *foo beats
sizeof(typenamethatcouldchangeinfuture).
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gvss9q$nff$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>
>> Stuart wrote:
>>> Where code does lead to nuisance warnings [for instance where the
>>> design
>>> constraints of foo will _always_ require it to be initialized to
>>> 0, and there is a high expectation that foo will continually
>>> change during the life of the code, so the first form of
>>> initialiation is desirable], a method for coping with this is to
>>> annotate the code (at the point the warning would be raised) to
>>> explain the warning and justify why it is appropriate to
>>> disregard it.
>> Alternatively, one could avoid the issue entirely with struct tm
>> *foo = calloc(sizeof(struct tm)), albeit having to replace tm.bar
>> with tm->bar elsewhere in the code.
>
> Firstly, the preferred idiom is:
>
> struct tm *foo = calloc(sizeof *foo);
Surely not? That dereferences an uninitialized pointer, thereby invoking
undefined behavior. Even though it doesn't read or write through it.
> Secondly, although all-bits-zero does indeed represent 0.0 or NULL
> on many platforms, it is not guaranteed by the C Standard so to do.
Have you ever seen a reasonably modern system where it wasn't? Then
again, dereferencing a bad pointer without actually reading or writing
through it doesn't tend to cause h/w exceptions on modern machines either.
In the meantime, though, assigning it {0} causes warnings, as you noted.
>>> Some developers even have tools to automatically filter such
>>> warnings (comparing the warnings of a new build with those
>>> expected for any build).
>>>
>>> I expect this sounds like an awful lot of fuss for a great many
>>> programmers - but for some it is a way of life!
>> How unfortunate.
>
> I've worked in environments like that, and found it quite workable.
Now I know why so much C software is crash-prone and generally buggy.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <LqCdnVrkBr9Qpb_XnZ2dnUVZ8rednZ2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
<snip>
>> Firstly, the preferred idiom is:
>>
>> struct tm *foo = calloc(sizeof *foo);
[calloc takes two args, of course - mea culpa]
> Surely not? That dereferences an uninitialized pointer, thereby
> invoking undefined behavior.
Surely not! The sizeof operator does not evaluate its operand, so
dereferencing does not and in fact cannot take place. Ref:
3.3.3.4 The sizeof operator
[...]
Semantics
The sizeof operator yields the size (in bytes) of its operand,
which may be an expression or the parenthesized name of a type. The
size is determined from the type of the operand, which is not
itself evaluated.
> Even though it doesn't read or write through it.
If you don't read the value itself (and sizeof does not), you can't
evaluate it, so you can't read through it or write through it.
>> Secondly, although all-bits-zero does indeed represent 0.0 or
>> NULL on many platforms, it is not guaranteed by the C Standard so
>> to do.
>
> Have you ever seen a reasonably modern system where it wasn't?
Have you ever seen a reasonably modern system that had precisely the
same architecture in all respects as the most common architecture
of the previous generation? There are real systems where NULL is
not all-bits-zero, and real systems where 0.0 is not all-bits-zero.
In the absence of a guarantee from Silicon Valley that this will
never, ever, ever happen again, I will continue to assume the worst
when writing code that I need to be maximally portable.
> Then again, dereferencing a bad pointer without actually reading
> or writing through it doesn't tend to cause h/w exceptions on
> modern machines either.
Strawman argument. Nobody in this discussion has dereferenced a bad
pointer.
> In the meantime, though, assigning it {0} causes warnings, as you
> noted.
>
>>>> Some developers even have tools to automatically filter such
>>>> warnings (comparing the warnings of a new build with those
>>>> expected for any build).
>>>>
>>>> I expect this sounds like an awful lot of fuss for a great many
>>>> programmers - but for some it is a way of life!
>>> How unfortunate.
>>
>> I've worked in environments like that, and found it quite
>> workable.
>
> Now I know why so much C software is crash-prone and generally
> buggy.
Yes, it's at least partly because there are people who don't know
the semantics of sizeof, but who still insist on writing in C.
Alternatively, we *could* play nice and back off the "in the
absence of evidence to the contrary I'll just assume you're a
moron" tone and discuss this like grown-ups. Your call.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gvufjo$rng$1@news.eternal-september.org>
Richard Heathfield wrote:
[snip]
Stop attacking me.
>>> Firstly, the preferred idiom is:
>>>
>>> struct tm *foo = calloc(sizeof *foo);
>> Surely not? That dereferences an uninitialized pointer, thereby
>> invoking undefined behavior.
>
> Surely not! The sizeof operator does not evaluate its operand
It must at least partly do so, in order to know what size of thing *foo
is referring to.
>>> Secondly, although all-bits-zero does indeed represent 0.0 or
>>> NULL on many platforms, it is not guaranteed by the C Standard so
>>> to do.
>> Have you ever seen a reasonably modern system where it wasn't?
>
> Have you ever seen a reasonably modern system that had precisely the
> same architecture in all respects as the most common architecture
> of the previous generation? There are real systems where NULL is
> not all-bits-zero
Yes, but are any of them in widespread use?
> and real systems where 0.0 is not all-bits-zero.
Not IEEE754-compatible ones.
> In the absence of a guarantee from Silicon Valley that this will
> never, ever, ever happen again, I will continue to assume the worst
> when writing code that I need to be maximally portable.
And I will continue to use Java when writing code that I need to be
maximally portable. C is for systems-level stuff now. :-)
>> Then again, dereferencing a bad pointer without actually reading
>> or writing through it doesn't tend to cause h/w exceptions on
>> modern machines either.
>
> Strawman argument.
Do not personally attack me or accuse me of intellectually dishonest
behavior again. You have been warned.
>>>>> Some developers even have tools to automatically filter such
>>>>> warnings (comparing the warnings of a new build with those
>>>>> expected for any build).
>>>>>
>>>>> I expect this sounds like an awful lot of fuss for a great many
>>>>> programmers - but for some it is a way of life!
>>>> How unfortunate.
>>> I've worked in environments like that, and found it quite
>>> workable.
>> Now I know why so much C software is crash-prone and generally
>> buggy.
>
> Yes, it's at least partly because there are people who don't know
> [rest of personal attacks deleted]
Stop attacking me.
You've said your piece and I've said mine. Move on.
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87k53x16r6.fsf@blp.benpfaff.org>
Seamus MacRae <··········@live.ca.invalid> writes:
> Richard Heathfield wrote:
>>>> Firstly, the preferred idiom is:
>>>>
>>>> struct tm *foo = calloc(sizeof *foo);
>>> Surely not? That dereferences an uninitialized pointer, thereby
>>> invoking undefined behavior.
>>
>> Surely not! The sizeof operator does not evaluate its operand
>
> It must at least partly do so, in order to know what size of thing
> *foo is referring to.
No. The ANSI C89 standard says this:
The sizeof operator yields the size (in bytes) of its
operand, which may be an expression or the parenthesized name
of a type. The size is determined from the type of the
operand, which is not itself evaluated. The result is an
integer constant.
C99 has an exception for variable-length arrays.
--
Ben Pfaff
http://benpfaff.org
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <Rfednb44hfv3VL_XnZ2dnUVZ8qdi4p2d@bt.com>
Ben Pfaff said:
> Seamus MacRae <··········@live.ca.invalid> writes:
>
>> Richard Heathfield wrote:
>>>>> Firstly, the preferred idiom is:
>>>>>
>>>>> struct tm *foo = calloc(sizeof *foo);
>>>> Surely not? That dereferences an uninitialized pointer, thereby
>>>> invoking undefined behavior.
>>>
>>> Surely not! The sizeof operator does not evaluate its operand
>>
>> It must at least partly do so, in order to know what size of
>> thing *foo is referring to.
>
> No. The ANSI C89 standard says this:
>
> The sizeof operator yields the size (in bytes) of its
> operand, which may be an expression or the parenthesized name
> of a type. The size is determined from the type of the
> operand, which is not itself evaluated. The result is an
> integer constant.
If you look at the grandparent article (my reply, to which Seamus
wrote a reply, to which you wrote a reply), you will find that very
text quoted. He has snipped it, giving no indication that he has
read or understood it, and now he's claiming that it's wrong.
> C99 has an exception for variable-length arrays.
Yes, but the context is calloc for allocating a single struct tm -
no VLAs involved.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h00aob$jsm$3@news.eternal-september.org>
Richard Heathfield wrote:
> Ben Pfaff said:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>> Richard Heathfield wrote:
>>>>>> Firstly, the preferred idiom is:
>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>> Surely not? That dereferences an uninitialized pointer, thereby
>>>>> invoking undefined behavior.
>>>> Surely not! The sizeof operator does not evaluate its operand
>>> It must at least partly do so, in order to know what size of
>>> thing *foo is referring to.
>> No.
>
> If you look at the grandparent article (my reply, to which Seamus
> wrote a reply, to which you wrote a reply), you will find
Very boring. Can we get back to discussing the original topic please?
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <xr6dnYtqn76WZL7XnZ2dnUVZ8sVi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Ben Pfaff said:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>> Richard Heathfield wrote:
>>>>>>> Firstly, the preferred idiom is:
>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>> thereby invoking undefined behavior.
>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>> It must at least partly do so, in order to know what size of
>>>> thing *foo is referring to.
>>> No.
>>
>> If you look at the grandparent article (my reply, to which Seamus
>> wrote a reply, to which you wrote a reply), you will find
>
> Very boring.
You consider authoritative information that proves you wrong to be
boring? When I find authoritative information that proves me wrong,
I consider it not only interesting but enlightening, as it allows
me to learn something new.
> Can we get back to discussing the original topic please?
You mean seeking a computer-programming job in Sunnyvale CA? Sure,
go for it; don't let me stop you.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h040j8$knc$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>
>> Richard Heathfield wrote:
>>> Ben Pfaff said:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>> Richard Heathfield wrote:
>>>>>>>> Firstly, the preferred idiom is:
>>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>>> thereby invoking undefined behavior.
>>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>>> It must at least partly do so, in order to know what size of
>>>>> thing *foo is referring to.
>>>> No.
>>> If you look at the grandparent article (my reply, to which Seamus
>>> wrote a reply, to which you wrote a reply), you will find
>> Very boring.
>
> You consider [yet another personal attack] to be boring?
Yes, I consider personal attacks to be boring. I thought we were here to
discuss Lisp and Java, not to flame one another. I'm only interested in
the former. Please discuss the former or please go away. Either way
please stop publicly badmouthing me!
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <NPKdncANhtXPA7jXnZ2dnUVZ8r5i4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>
>>> Richard Heathfield wrote:
>>>> Ben Pfaff said:
>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>> Richard Heathfield wrote:
>>>>>>>>> Firstly, the preferred idiom is:
>>>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>>>> thereby invoking undefined behavior.
>>>>>>> Surely not! The sizeof operator does not evaluate its
>>>>>>> operand
>>>>>> It must at least partly do so, in order to know what size of
>>>>>> thing *foo is referring to.
>>>>> No.
>>>> If you look at the grandparent article (my reply, to which
>>>> Seamus wrote a reply, to which you wrote a reply), you will
>>>> find
>>> Very boring.
>>
>> You consider [yet another personal attack] to be boring?
Incorrect elision.
> Yes, I consider personal attacks to be boring.
It wasn't intended as a personal attack. Nevertheless, you seem to
be taking it that way. If you consider what you think to be
personal attacks to be boring, why do you discuss them so much?
> I thought we were here to discuss Lisp and Java,
I thought we were here to discuss programming. (Hint: this is
cross-posted to comp.programming.)
> not to flame one another.
I haven't flamed you. I haven't even /begun/ to turn up the heat.
(You have, by introducing expletives.) I have done only two things
in this subthread: (a) tried to explain the semantics of sizeof to
you, and (b) played a straight bat against your histrionics.
> I'm only interested in the former. Please discuss the former or
> please go away. Either way please stop publicly badmouthing me!
I /am/ discussing programming - specifically, sizeof. What I am not
doing is badmouthing you. You're doing that yourself.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0666r$mjp$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> Richard Heathfield wrote:
>>>>> Ben Pfaff said:
>>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>>> Richard Heathfield wrote:
>>>>>>>>>> Firstly, the preferred idiom is:
>>>>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>>>>> thereby invoking undefined behavior.
>>>>>>>> Surely not! The sizeof operator does not evaluate its
>>>>>>>> operand
>>>>>>> It must at least partly do so, in order to know what size of
>>>>>>> thing *foo is referring to.
>>>>>> No.
>>>>> If you look at the grandparent article (my reply, to which
>>>>> Seamus wrote a reply, to which you wrote a reply), you will
>>>>> find
>>>> Very boring.
>>> You consider [yet another personal attack] to be boring?
>
> Incorrect
No. The incorrect person here is you. You were supposed to respond to my
post by shutting up. Instead, you attacked me again.
Now you are going to hell.
>> Yes, I consider personal attacks to be boring.
>
> It wasn't intended as a personal attack.
The hell it wasn't.
Your dislike for me is quite evident. Your posts drip with it. Take this
to private email or I will make your internet provider shut you up.
> Nevertheless, you seem to
> be taking it that way. If you consider what you think to be
> personal attacks to be boring, why do you discuss them so much?
I am not discussing them. I have no interest now in discussing anything
with you. The problem is you keep interpreting my rebuttals as
discussion. They are not. You keep making statements about me in public
that are in error. I therefore post a correction. The intended audience
of that correction does NOT include you, it includes everybody else that
might be misled about me by the bad things you said. I would prefer it
in fact if you DID NOT read my posts -- then you wouldn't reply to
"discuss" my perceived-by-you shortcomings some more, and I wouldn't
have to post yet another correction.
>> I thought we were here to discuss Lisp and Java,
>
> I thought we were here to discuss programming.
If you want to discuss programming, go right ahead, but leave my name
out of it and don't insinuate anything about me indirectly, either.
>> not to flame one another.
>
> I haven't flamed you.
A blatant lie.
> I haven't even /begun/ to turn up the heat.
Is that a threat?
It better not be.
> (You have, by introducing expletives.) I have done only two things
> in this subthread: (a) [implied insult deleted], and (b) [insult
> deleted]
Yes, that's right, you've done only two things: insult me and insult me
some more. Needless to say, insults are off-topic in all three
newsgroups you're spewing them into.
>> I'm only interested in the former. Please discuss the former or
>> please go away. Either way please stop publicly badmouthing me!
>
> I /am/ discussing programming.
No.
> What I am not doing is badmouthing you.
A lie.
> You're doing that yourself.
Another lie. Where have I posted any negative statement about myself? I
haven't. In fact, the opposite -- I've posted *denials* that various
such statements apply.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <dNGdnW_hwKyKMLvXnZ2dnUVZ8rGdnZ2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
<snip>
>> Incorrect
>
> No. The incorrect person here is you. You were supposed to respond
> to my post by shutting up.
Perhaps you think that's what's supposed to happen, but I'm entitled
to hold, and do hold, a different viewpoint.
> Instead, you attacked me again.
Well, if you count a correction as an attack, I'm surprised you're
not used to being "attacked" by now.
> Now you are going to hell.
I don't think so.
>>> Yes, I consider personal attacks to be boring.
>>
>> It wasn't intended as a personal attack.
>
> The hell it wasn't.
It isn't up to you to decide what my intentions are.
> Your dislike for me is quite evident.
I have no personal animosity towards you whatsoever. I'm beginning
to pity you, but I don't dislike you. I do dislike the way you
"argue", but that's different from disliking you.
> Your posts drip with it.
No, they don't.
> Take this to private email or I will make your internet provider
> shut you up.
If you feel so strongly that this is an appropriate matter for
private email, why have I not received any emails from you? Oh, and
good luck getting an ISP to inconvenience a customer for /not/
breaking any rules.
>> Nevertheless, you seem to
>> be taking it that way. If you consider what you think to be
>> personal attacks to be boring, why do you discuss them so much?
>
> I am not discussing them.
Yes, you are. It's patently evident that you are. Hence this long,
long, long long long long subthread.
> I have no interest now in discussing
> anything with you.
You can stop any time you like.
> The problem is you keep interpreting my
> rebuttals as discussion. They are not.
Er, actually rebuttals *are* part of discussion. But according to my
dictionary, to make a rebuttal normally includes offering some kind
of opposing evidence. I haven't seen much evidence from your side,
and what there has been has been easily refuted.
> You keep making statements
> about me in public that are in error.
I've only made two statements about you in public that I consider to
be particularly important. One is that you clearly don't understand
sizeof, and the other is that you have demonstrably lied.
> I therefore post a correction. The intended audience of that
> correction does NOT include you,
Then why post it where I can read it? Why not email all the people
you intend to read it? (If you answer as I expect you to answer,
you will know why I too, eschew email for this purpose.)
> it includes everybody else that might be misled about
> me by the bad things you said. I would prefer it in fact if you
> DID NOT read my posts
Then you're sure picking a funny group to post them in.
<snip>
>>> I thought we were here to discuss Lisp and Java,
>>
>> I thought we were here to discuss programming.
>
> If you want to discuss programming, go right ahead, but leave my
> name out of it and don't insinuate anything about me indirectly,
> either.
Okay, let's do that. The sizeof operator does not evaluate its
operand. The operand of sizeof is an operand to sizeof, not an
argument to sizeof. Proofs have already been posted.
>>> not to flame one another.
>>
>> I haven't flamed you.
>
> A blatant lie.
No, sir, that is not so.
>> I haven't even /begun/ to turn up the heat.
>
> Is that a threat?
No, it's a rebuttal.
> It better not be.
It isn't. Turning up the heat would be counter-productive, as you
have amply demonstrated.
>
>> (You have, by introducing expletives.) I have done only two
>> things in this subthread: (a) [implied insult deleted], and (b)
>> [insult deleted]
>
> Yes, that's right, you've done only two things: insult me and
> insult me some more.
No, I've done only two *important* things, and one of those was to
demonstrate that you don't understand sizeof. The other was to
demonstrate that you have lied. I don't believe I've insulted you
at all, except in jest (yes, the "buffoon" thing was an attempt at
irony, which appears to have passed you by).
> Needless to say, insults are off-topic in all
> three newsgroups you're spewing them into.
Yes, but then I'm not in the habit of insulting people, so that's
all right then.
>
>>> I'm only interested in the former. Please discuss the former or
>>> please go away. Either way please stop publicly badmouthing me!
>>
>> I /am/ discussing programming.
>
> No.
It's sizeof, remember?
>
>> What I am not doing is badmouthing you.
>
> A lie.
No, sir.
>
>> You're doing that yourself.
>
> Another lie. Where have I posted any negative statement about
> myself?
Everything you write about yourself comes across to me as being
negative. I doubt whether I'm the only one who interprets it in
that way.
> I haven't. In fact, the opposite -- I've posted *denials*
> that various such statements apply.
So? What has that to do with anything? It's not what you say or even
what you deny. It's how you say it.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Kaz Kylheku
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <20090615112004.741@gmail.com>
On 2009-06-03, Richard Heathfield <···@see.sig.invalid> wrote:
> I have no personal animosity towards you whatsoever. I'm beginning
> to pity you, but I don't dislike you. I do dislike the way you
> "argue", but that's different from disliking you.
On the other hand, not me. I tend to despise what others pity. (With
clear exceptions---like, for instance, bear cubs who lost their mother to a
poacher's rifle, that sort of thing---but not in this case).
:)
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p00k$tek$2@news.eternal-september.org>
Kaz Kylheku wrote:
> On 2009-06-03, Richard Heathfield <···@see.sig.invalid> wrote:
>> I have no personal animosity towards you whatsoever. I'm beginning
>> to pity you, but I don't dislike you.
There is nothing pitiable about me.
>> I do dislike the way you "argue", but that's different from disliking you.
As explained previously, you're discovering an intentional deterrence.
He's supposed to react to it by knowing better than to argue with me in
the future. Unfortunately, the deterrence only works on people that are
intelligent enough to be capable of pattern recognition and learning
from the results of their actions.
> On the other hand, not me. I tend to despise what others pity. (With
> clear exceptions---like, for instance, bear cubs who lost their mother to a
> poacher's rifle, that sort of thing---but not in this case).
Since there is nothing pitiable about me, this fails to be relevant.
P.S. Please desist from trying to misdirect rebuttals of your insults so
that they'd fail to reach 2/3 of the audience of your insults. That's
playing dirty.
On 10 June, 20:02, Seamus MacRae <··········@live.ca.invalid> wrote:
> Kaz Kylheku wrote:
> > On 2009-06-03, Richard Heathfield <····@see.sig.invalid> wrote:
> >> I have no personal animosity towards you whatsoever. I'm beginning
> >> to pity you, but I don't dislike you.
>
> There is nothing pitiable about me.
<giggle>
> >> I do dislike the way you "argue", but that's different from disliking you.
>
> As explained previously, you're discovering an intentional deterrence.
a what?
> He's supposed to react to it by knowing better than to argue with me in
> the future.
or?
> Unfortunately, the deterrence only works on people that are
> intelligent enough to be capable of pattern recognition and learning
> from the results of their actions.
but the only result is that you got more and more funny!
I fail to see the deterence!
<snip>
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u5lk$iab$1@news.eternal-september.org>
Nick Keighley wrote:
> On 10 June, 20:02, Seamus MacRae <··········@live.ca.invalid> wrote:
>> Kaz Kylheku wrote:
>>> On 2009-06-03, Richard Heathfield <····@see.sig.invalid> wrote:
>
>>>> I have no personal animosity towards you whatsoever. I'm beginning
>>>> to pity you, but I don't dislike you.
>> There is nothing pitiable about me.
>
> [childish response deleted]
>
>>>> I do dislike the way you "argue", but that's different from disliking you.
>> As explained previously, you're discovering an intentional deterrence.
>
> a what?
http://www.merriam-webster.com/dictionary/deterrence
>> He's supposed to react to it by knowing better than to argue with me in
>> the future.
>
> or?
Or he continues to endure the pain and frustration that he noted. It's
his choice.
>> Unfortunately, the deterrence only works on people that are
>> intelligent enough to be capable of pattern recognition and learning
>> from the results of their actions.
>
> but the only result is that [childish namecalling deleted]
You clearly require more assistance than I can presently provide.
http://maps.google.ca/maps?q=england psychiatrist
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0ovra$tek$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Incorrect
>> No. The incorrect person here is you. You were supposed to respond
>> to my post by shutting up.
>
> Perhaps
There's no "perhaps" about it.
>> Instead, you attacked me again.
>
> Well, if you count a correction as an attack
I count a "correction" as an attack. A correction, no, but a
"correction", yes. I am aware that the distinction is subtle.
>> Now you are going to hell.
>
> I don't think so.
That isn't for you to decide. (Or are you now claiming to be Saint
Peter, too?)
>>>> Yes, I consider personal attacks to be boring.
>>> It wasn't intended as a personal attack.
>> The hell it wasn't.
>
> It isn't up to you to decide
I wasn't deciding; I was merely observing.
>> Your dislike for me is quite evident.
>
> I have no personal animosity towards you whatsoever.
This, of course, is a blatant lie. Your behavior speaks volumes about
your opinions and emotions, and it is a more trustworthy indicator of
those things than your explicit claims about same.
> I do dislike the way you "argue"
That is normal. It's a deterrent. You are not supposed to argue with me;
consequently, I have made it such that doing so results in an unpleasant
wading-through-tar sort of frustrating feeling in the arguer, to
discourage them from continuing and from picking a second fight with me
at any later date.
>> Your posts drip with it.
>
> No, they don't.
This, of course, is another lie.
>> Take this to private email or I will make your internet provider
>> shut you up.
>
> If you feel so strongly that this is an appropriate matter for
> private email, why have I not received any emails from you?
You first. I'm not going to respond privately to rebut a public
accusation/insult made against me, for the obvious reason that the
rebuttal has to be part of the public record to be effective. If you
want me to rebut in private, you have to insult me in private. (Of
course, then I also get the option of just ignoring you instead.)
> Oh, and good luck getting an ISP to inconvenience a customer for
> /not/ breaking any rules.
Did you forget the bit where I quoted chapter and verse from your
provider's AUP and pointed out the parts you might be seen as violating?
>>> Nevertheless, you seem to
>>> be taking it that way. If you consider what you think to be
>>> personal attacks to be boring, why do you discuss them so much?
>> I am not discussing them.
>
> Yes, you are.
No, I am not. I am publicly rebutting them.
>> I have no interest now in discussing
>> anything with you.
>
> You can stop any time you like.
I have stopped. This is not a discussion; it is a public rebuttal of
public statements that you made. Its audience is not you; its audience
is everyone else, the people that you might otherwise successfully
mislead about me.
>> The problem is you keep interpreting my
>> rebuttals as discussion. They are not.
>
> Er, actually rebuttals *are* part of discussion.
These ones are not. My position on the topic of my own mental
functioning is not amenable to negotiation or compromise. Nor,
apparently, is yours. Therefore discussing is futile. Rebuttal, on the
other hand, is not.
> I haven't seen much evidence from your side
The evidence is in the self-evident fact of my intelligence. You may
have noticed my erudition and correct spelling and grammar, which
already puts me in the top percentile of usenet users as near as I can
tell. I have also used forms of logic and demonstrated knowledge that
would not generally be available to the man you wish to publicly portray
me as, but which clearly ARE available to the man I actually am.
>> You keep making statements
>> about me in public that are in error.
>
> I've only made two statements about you in public that I consider to
> be particularly important. [insults deleted]
You have lied about me repeatedly, including by calling me a liar. I
don't care that you have limited your repertoire of vicious lies to only
a handful. Even just one would have been one too many.
>> I therefore post a correction. The intended audience of that
>> correction does NOT include you,
>
> Then why post it where I can read it?
Unfortunately, there does not seem to be a "post message for everyone
else in specified newsgroups but hide it from the author of the post I'm
quoting" function in Thunderbird.
>> it includes everybody else that might be misled about
>> me by the bad things you said. I would prefer it in fact if you
>> DID NOT read my posts
>
> Then you're sure picking a funny group to post them in.
I have no choice as to what groups to post them in; to be read by the
same people that you're trying to mislead about me, they must be posted
as replies to your attack posts, in the same sets of newsgroups.
>>>> I thought we were here to discuss Lisp and Java,
>>> I thought we were here to discuss programming.
>> If you want to discuss programming, go right ahead, but leave my
>> name out of it and don't insinuate anything about me indirectly,
>> either.
>
> Okay, let's do that.
Okay.
> [calls me a liar]
Failed. You just insinuated something about me.
>>>> not to flame one another.
>>> I haven't flamed you.
>> A blatant lie.
>
> [calls me a liar]
No, you're the liar, remember?
>>> I haven't even /begun/ to turn up the heat.
>> Is that a threat?
>
> No
Liar.
>> It better not be.
>
> It isn't. [insult deleted]
Liar.
>>> (You have, by introducing expletives.) I have done only two
>>> things in this subthread: (a) [implied insult deleted], and (b)
>>> [insult deleted]
>> Yes, that's right, you've done only two things: insult me and
>> insult me some more.
>
> No, I've done only two *important* things, and one of those was to
> [insult me]. The other was to [insult me].
But insulting me is NOT important.
> I don't believe I've insulted you at all
You just did. Twice. AGAIN.
> except in jest
Oh. So this whole thread is just a JOKE to you? Well, having my
professional skills publicly tarnished by baseless accusations does not
amuse me, and this whole flamewar probably has utterly failed to amuse
anyone else. So if you intended this as a joke, it looks like you've
failed at that, too.
>> Needless to say, insults are off-topic in all
>> three newsgroups you're spewing them into.
>
> Yes, but then I'm not in the habit of insulting people, so that's
> all right then.
Okay, so to you, spewing off-topic insults into three newsgroups is
perfectly acceptable behavior so long as you only do it occasionally and
do not make a habit of it?
People say that about smoking, too. Then whine when they get diagnosed
with cancer.
>>>> I'm only interested in the former. Please discuss the former or
>>>> please go away. Either way please stop publicly badmouthing me!
>>> I /am/ discussing programming.
>> No.
>
> It's sizeof, remember?
I'm talking about your obsession with publicly "correcting" me, publicly
calling me names, and more generally trying to publicly humiliate me for
the heinous crime of failing to agree with all of your opinions.
>>> What I am not doing is badmouthing you.
>> A lie.
>
> [calls me a liar]
No, you're the liar, remember?
>>> You're doing that yourself.
>> Another lie. Where have I posted any negative statement about
>> myself?
>
> Everything you write about yourself comes across to me as being
> negative.
That's because you're wacko, so everything you read seems to you to mean
the opposite of what it actually means.
>> I haven't. In fact, the opposite -- I've posted *denials*
>> that various such statements apply.
>
> So? What has that to do with anything?
It disproves one of your lies. That's what.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh302hv.1k0o.willem@snail.stack.nl>
Here are some excerpts that clearly indicate the nature of Seamus.
I've also included some parts he quoted, but changed by replacing
significant parts by comments in square brackets.
Seamus MacRae wrote:
) That is normal. It's a deterrent. You are not supposed to argue with me;
) consequently, I have made it such that doing so results in an unpleasant
) wading-through-tar sort of frustrating feeling in the arguer, to
) discourage them from continuing and from picking a second fight with me
) at any later date.
...
) I have stopped. This is not a discussion; it is a public rebuttal of
) public statements that you made. Its audience is not you; its audience
) is everyone else, the people that you might otherwise successfully
) mislead about me.
...
) The evidence is in the self-evident fact of my intelligence. You may
) have noticed my erudition and correct spelling and grammar, which
) already puts me in the top percentile of usenet users as near as I can
) tell. I have also used forms of logic and demonstrated knowledge that
) would not generally be available to the man you wish to publicly portray
) me as, but which clearly ARE available to the man I actually am.
...
) Okay.
)
)> [calls me a liar]
)
) Failed. You just insinuated something about me.
...
)> No, I've done only two *important* things, and one of those was to
)> [insult me]. The other was to [insult me].
)
) But insulting me is NOT important.
...
)> It's sizeof, remember?
)
) I'm talking about your obsession with publicly "correcting" me, publicly
) calling me names, and more generally trying to publicly humiliate me for
) the heinous crime of failing to agree with all of your opinions.
...
) That's because you're wacko, so everything you read seems to you to mean
) the opposite of what it actually means.
...
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u5nh$iab$2@news.eternal-september.org>
Willem wrote:
> Here are some excerpts that clearly indicate the nature of Seamus.
Yes, an intelligent man but one with little patience for certain sorts
of nonsense coming from other people.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh358ae.e12.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> Here are some excerpts that clearly indicate the nature of Seamus.
)
) Yes, an intelligent man but one with little patience for certain sorts
) of nonsense coming from other people.
Then why do you change around what other people write
when you are replying to them ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h10mr2$jpm$1@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Here are some excerpts that clearly indicate the nature of Seamus.
> )
> ) Yes, an intelligent man but one with little patience for certain sorts
> ) of nonsense coming from other people.
>
> Then why do you
Why do you keep harassing me?
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h00ama$jsm$2@news.eternal-september.org>
Ben Pfaff wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>
>> Richard Heathfield wrote:
>>>>> Firstly, the preferred idiom is:
>>>>>
>>>>> struct tm *foo = calloc(sizeof *foo);
>>>> Surely not? That dereferences an uninitialized pointer, thereby
>>>> invoking undefined behavior.
>>> Surely not! The sizeof operator does not evaluate its operand
>> It must at least partly do so, in order to know what size of thing
>> *foo is referring to.
>
> No.
Unevaluated, "*foo" is merely a pointer dereference operation. It is not
a value whose size may be measured.
Seamus MacRae <··········@live.ca.invalid> writes:
> Ben Pfaff wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>
>>> Richard Heathfield wrote:
>>>>>> Firstly, the preferred idiom is:
>>>>>>
>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>> Surely not? That dereferences an uninitialized pointer, thereby
>>>>> invoking undefined behavior.
>>>> Surely not! The sizeof operator does not evaluate its operand
>>> It must at least partly do so, in order to know what size of thing
>>> *foo is referring to.
>>
>> No.
>
> Unevaluated, "*foo" is merely a pointer dereference operation. It is
> not a value whose size may be measured.
That's true: it is not a value at all. It is an expression whose
size _can_ be measured.
Since you have rejected the evidence of direct quotes from the C
language standard I don't expect you'll take my word for it. If you
want to go on arguing about what sizeof *foo means I'd like to know
what sources of information you _would_ believe. I.e. where do get your
information from, and what do you consider a definitive source for
resolving questions like this?
--
Ben.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0410t$r16$1@news.eternal-september.org>
Ben Bacarisse wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>> Ben Pfaff wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>> Richard Heathfield wrote:
>>>>>>> Firstly, the preferred idiom is:
>>>>>>>
>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>> Surely not? That dereferences an uninitialized pointer, thereby
>>>>>> invoking undefined behavior.
>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>> It must at least partly do so, in order to know what size of thing
>>>> *foo is referring to.
>>> No.
>> Unevaluated, "*foo" is merely a pointer dereference operation. It is
>> not a value whose size may be measured.
>
> That's true: it is not a value at all. It is an expression whose
> size _can_ be measured.
How can you measure the size of something you don't actually have? Don't
forget C99 added variable-length arrays.
> Since you have rejected
I reject any claim that implies that I'm some sort of doofus, especially
if that claim was made publicly.
> I'd like to know what sources of information you _would_ believe.
When the discussion has become a platform for launching personal
attacks, I *won't* believe any information whatsoever that says
something hostile about me. So you can get that idea right out of your
head, right now. I've no interest in "discussing" myself at all -- I
will ignore the subject unless someone else brings it up, and then I
will defend myself to the maximum extent possible, without any
negotiation or compromise. Whether I am, or am not, whatever nasty thing
you may be thinking is not up for debate: I am not, and that is final,
and I will not budge on that score.
Unfortunately, I know that some people seem to consider such an attitude
a challenge or even an affront and will try ever-more-strenuously to
assert forcefully in public their own, negative opinion of me. Be
warned: any who do so become the subjects of complaints to their
internet providers for posting large volumes of off-topic posts, since
that's what they inevitably do if they get a bee in their bonnet about
publicly badmouthing me.
I suggest you just Let. The matter. Drop. instead of pursuing it.
> I.e. where do get your information from, and what do you consider a
> definitive source for resolving questions like this?
There is no question in my mind whatsoever that whatever hostile things
you're thinking about me, and probably plotting to say about me, are not
true in the slightest. You will not convince me otherwise. If you try to
back me into some sort of corner pushing for a public negative
evaluation of me I will shove right back and harder. Perhaps you'd like
a taste of being on the receiving end of the kind of flak you seem to be
contemplating letting loose? Perhaps you'll find out.
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87tz2ytmhm.fsf@blp.benpfaff.org>
Seamus MacRae <··········@live.ca.invalid> writes:
> How can you measure the size of something you don't actually have?
You can know the size of an int without knowing the value of that
int.
--
A bicycle is one of the world's beautiful machines, beautiful machines
are art, and art is civilisation, good living, and balm to the soul.
--Elisa Francesca Roselli
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0667s$mjp$2@news.eternal-september.org>
Ben Pfaff wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>
>> How can you measure the size of something you don't actually have?
>
> You can know the size of an int without knowing the value of that
> int.
You cannot know the size of a variable-length array without knowing the
value of that array.
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <8763fdqo8c.fsf@blp.benpfaff.org>
Seamus MacRae <··········@live.ca.invalid> writes:
> Ben Pfaff wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>
>>> How can you measure the size of something you don't actually have?
>>
>> You can know the size of an int without knowing the value of that
>> int.
>
> You cannot know the size of a variable-length array without knowing
> the value of that array.
Variable-length arrays are a special case; in fact, they are the
only special case. Otherwise, in C, sizeof needs only the type
of an object to determine its size.
By the way, the "value" of an array is not very meaningful in C.
Possibly, you mean the elements or the contents of an array, but
that's not true: it doesn't matter what the contents of the array
are. In the end, all you need to know the size of a
variable-length array is the number of elements in it and the
type of those elements.
--
"The fact is, technical people are better off not looking at patents. If
you don't know what they cover and where they are, you won't be knowingly
infringing on them. If somebody sues you, you change the algorithm or you
just hire a hit-man to whack the stupid git." --Linus Torvalds
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p01h$tek$3@news.eternal-september.org>
Ben Pfaff wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>
>> Ben Pfaff wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>
>>>> How can you measure the size of something you don't actually have?
>>> You can know the size of an int without knowing the value of that
>>> int.
>> You cannot know the size of a variable-length array without knowing
>> the value of that array.
>
> Variable-length arrays are a special case
That they exist at all suffices.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <dNGdnW7hwKwQMLvXnZ2dnUVZ8rFi4p2d@bt.com>
Seamus MacRae said:
> Ben Pfaff wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>
>>> How can you measure the size of something you don't actually
>>> have?
>>
>> You can know the size of an int without knowing the value of that
>> int.
>
> You cannot know the size of a variable-length array without
> knowing the value of that array.
I have read Ben's reply, and agree with it, and will not duplicate
it here. This reply is just to point out that the original context
was sizeof *foo, where foo was a pointer to a struct tm. It was not
a VLA, or a pointer to a VLA. The objection is therefore irrelevant
to the current discussion.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p041$tek$4@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>
>> Ben Pfaff wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>
>>>> How can you measure the size of something you don't actually
>>>> have?
>>> You can know the size of an int without knowing the value of that
>>> int.
>> You cannot know the size of a variable-length array without
>> knowing the value of that array.
>
> I have read Ben's reply, and agree with it
"You can know the size of an int without knowing the value of that int"
is true enough; everybody probably agrees with it.
It is also irrelevant.
The important point is that you cannot know the size of a thing *in
general* without knowing the value of it.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <NPKdncMNhtWJArjXnZ2dnUVZ8r5i4p2d@bt.com>
Seamus MacRae said:
> Ben Bacarisse wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>> Ben Pfaff wrote:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>> Richard Heathfield wrote:
>>>>>>>> Firstly, the preferred idiom is:
>>>>>>>>
>>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>>> thereby invoking undefined behavior.
>>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>>> It must at least partly do so, in order to know what size of
>>>>> thing *foo is referring to.
>>>> No.
>>> Unevaluated, "*foo" is merely a pointer dereference operation.
>>> It is not a value whose size may be measured.
>>
>> That's true: it is not a value at all. It is an expression whose
>> size _can_ be measured.
>
> How can you measure the size of something you don't actually have?
By knowing its type.
> Don't forget C99 added variable-length arrays.
Right, but that's irrelevant to the case in point.
>> Since you have rejected
>
> I reject any claim that implies that I'm some sort of doofus,
> especially if that claim was made publicly.
The C Standard doesn't even mention you, let alone call you a
doofus.
>
>> I'd like to know what sources of information you _would_ believe.
>
> When the discussion has become a platform for launching personal
> attacks, I *won't* believe any information whatsoever that says
> something hostile about me.
As far as I'm aware, the C Standard says nothing whatsoever about
you in any way, shape or form, let alone anything hostile.
> So you can get that idea right out of
> your head, right now. I've no interest in "discussing" myself at
> all -- I will ignore the subject unless someone else brings it up,
Great! So we can talk about sizeof without reference to
personalities. That works for me.
> and then I will defend myself to the maximum extent possible,
> without any negotiation or compromise. Whether I am, or am not,
> whatever nasty thing you may be thinking is not up for debate: I
> am not, and that is final, and I will not budge on that score.
I am delighted to hear it, and would not contradict you for the
world. Nevertheless, this discussion is *not* about you. It's about
sizeof.
<big ol' snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Kaz Kylheku
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <20090614132058.476@gmail.com>
On 2009-06-02, Richard Heathfield <···@see.sig.invalid> wrote:
> The C Standard doesn't even mention you, let alone call you a
> doofus.
You're arguing with a mentally ill individual who believes that all expression
of disagreement constitutes a personal attack.
There is no way you can word a paragraph which disagrees with a statement he
made in such a way that it will not be construed as a personal attack,
and used as an opportunity to start another subthread about this favorite
subject of his.
His recommendation (as he explicitly stated in another article) is that when
you disagree with something, you should just let it be. One person has said his
piece, the other has said his, and leave it at that. That is how you avoid
making an attack.
And yet he insists that he wants to be part of a debate (whatever that
means, without the possibility of proper disagreement).
I.e. he expects to be granted a waiver from all of Usenet, allowing him the
privilege of having the last word, regardless of what B.S. he posts.
Good luck.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <B-idnau9kYXiNrjXnZ2dnUVZ8jBi4p2d@bt.com>
Kaz Kylheku said:
> On 2009-06-02, Richard Heathfield <···@see.sig.invalid> wrote:
>> The C Standard doesn't even mention you, let alone call you a
>> doofus.
>
> You're arguing with a mentally ill individual who believes that
> all expression of disagreement constitutes a personal attack.
>
<snip>
> I.e. he expects to be granted a waiver from all of Usenet,
> allowing him the privilege of having the last word, regardless of
> what B.S. he posts.
>
> Good luck.
The last word is "zymotic", according to my dictionary. Since I'm
not into homebrew, I rarely have need for it, so it's really just
cluttering up the place. If he wants it, he can have it.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h066mc$qen$2@news.eternal-september.org>
Richard Heathfield wrote:
> Kaz Kylheku said:
>
>> On 2009-06-02, Richard Heathfield <···@see.sig.invalid> wrote:
>>> The C Standard doesn't even mention you, let alone call you a
>>> doofus.
>> You're arguing with a mentally ill individual
Kaz is lying about me. My health, in every respect, is excellent for my age.
>> I.e. he expects to be granted a waiver from all of Usenet,
>> allowing him the privilege of having the last word, regardless of
>> what B.S. he posts.
I do not post B.S. and it is Richard who has all but admitted he insists
on having the last word.
> If he wants it, he can have it.
I'll believe that when I see it. You shutting up about me, that is.
From: Lars Enderin
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4A26A2F5.1010509@telia.com>
Seamus MacRae wrote:
> Richard Heathfield wrote:
>> Kaz Kylheku said:
>>
>>> On 2009-06-02, Richard Heathfield <···@see.sig.invalid> wrote:
>>>> The C Standard doesn't even mention you, let alone call you a
>>>> doofus.
>>> You're arguing with a mentally ill individual
>
> Kaz is lying about me. My health, in every respect, is excellent for my
> age.
>
>>> I.e. he expects to be granted a waiver from all of Usenet,
>>> allowing him the privilege of having the last word, regardless of
>>> what B.S. he posts.
>
> I do not post B.S. and it is Richard who has all but admitted he insists
> on having the last word.
>
>> If he wants it, he can have it.
>
> I'll believe that when I see it. You shutting up about me, that is.
You missed the joke. Figures.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p05c$tek$5@news.eternal-september.org>
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Richard Heathfield wrote:
>>> Kaz Kylheku said:
>>>
>>>> On 2009-06-02, Richard Heathfield <···@see.sig.invalid> wrote:
>>>>> The C Standard doesn't even mention you, let alone call you a
>>>>> doofus.
>>>> You're arguing with a mentally ill individual
>>
>> Kaz is lying about me. My health, in every respect, is excellent for
>> my age.
>>
>>>> I.e. he expects to be granted a waiver from all of Usenet,
>>>> allowing him the privilege of having the last word, regardless of
>>>> what B.S. he posts.
>>
>> I do not post B.S. and it is Richard who has all but admitted he
>> insists on having the last word.
>>
>>> If he wants it, he can have it.
>>
>> I'll believe that when I see it. You shutting up about me, that is.
>
> You missed the joke.
I have missed nothing. There was no joke there. Only insults.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <dNGdnWjhwKxZM7vXnZ2dnUVZ8rFi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Kaz Kylheku said:
>>
>>> On 2009-06-02, Richard Heathfield <···@see.sig.invalid> wrote:
>>>> The C Standard doesn't even mention you, let alone call you a
>>>> doofus.
>>> You're arguing with a mentally ill individual
>
> Kaz is lying about me. My health, in every respect, is excellent
> for my age.
This has not been demonstrated beyond contradiction. The possibility
remains that Kaz is not lying.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p06i$tek$6@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>
>> Richard Heathfield wrote:
>>> Kaz Kylheku said:
>>>
>>>> On 2009-06-02, Richard Heathfield <···@see.sig.invalid> wrote:
>>>>> The C Standard doesn't even mention you, let alone call you a
>>>>> doofus.
>>>> You're arguing with a mentally ill individual
>> Kaz is lying about me. My health, in every respect, is excellent
>> for my age.
>
> [calls me a liar]
No, you're the liar, remember?
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h066ka$qen$1@news.eternal-september.org>
Kaz Kylheku wrote:
> On 2009-06-02, Richard Heathfield <···@see.sig.invalid> wrote:
>> The C Standard doesn't even mention you, let alone call you a
>> doofus.
>
> You're arguing with a mentally ill individual
No, he is not. Stop lying about me.
> There is no way you can word a paragraph which disagrees with a statement he
> made in such a way that it will not be construed as a personal attack,
Not if there's no charitable-to-me interpretation of that paragraph, no.
It must allow the possibility that the poster of the paragraph is wrong,
or that reasonable men may disagree about its subject matter, to not be
implying some kind of stupidity or incompetence on my part, obviously.
> and used as an opportunity to start another subthread about this favorite
> subject of his.
This is not my favorite subject. I'd much rather this sort of nonsense
didn't come up. The problem is that people like Richard occasionally
crop up that a) insist on loudly publicly broadcasting their opinions
regarding other people and b) insist on having the last word.
Such people are called "children" and should really not have
unsupervised internet access, but c'est la vie.
> His recommendation (as he explicitly stated in another article) is that when
> you disagree with something, you should just let it be. One person has said his
> piece, the other has said his, and leave it at that. That is how you avoid
> making an attack.
Yes, that's right -- if two people don't agree about something, agreeing
to disagree instead of trying to forcibly convert each other (or
evangelize to everyone else) is the mature, civilized thing to do.
Not that you'd know anything about mature, to judge by the juvenile
namecalling you've just engaged in, above.
> And yet he insists that he wants to be part of a debate
I did not.
> I.e. he expects to be granted a waiver from all of Usenet, allowing him the
> privilege of having the last word, regardless of what B.S. he posts.
I do not post B.S. and it is Richard who has all but admitted to
insisting upon having the last word.
Now butt out.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h066cg$mjp$3@news.eternal-september.org>
Richard Heathfield forgot to stop attacking me:
> Seamus MacRae said:
>> How can you measure the size of something you don't actually have?
>
> By knowing its type.
That doesn't work for variable-length arrays.
>> Don't forget C99 added variable-length arrays.
>
> Right
Well, there you go then.
>>> Since you have rejected
>> I reject any claim that implies that I'm some sort of doofus,
>> especially if that claim was made publicly.
>
> The C Standard doesn't even mention you, let alone call you a
> doofus.
No, you do. It is you that I am objecting to.
>>> I'd like to know what sources of information you _would_ believe.
>> When the discussion has become a platform for launching personal
>> attacks, I *won't* believe any information whatsoever that says
>> something hostile about me.
>
> As far as I'm aware, the C Standard says nothing whatsoever about
> you in any way, shape or form, let alone anything hostile.
No, you do. It is you that I am objecting to.
Stop trying to change the subject to the C standard, which, as you say,
is irrelevant to the matter of your insulting me repeatedly.
>> So you can get that idea right out of your head, right now. I've
>> no interest in "discussing" myself at all -- I will ignore the
>> subject unless someone else brings it up,
>
> Great!
Then will you shut up about me now?
>> and then I will defend myself to the maximum extent possible,
>> without any negotiation or compromise. Whether I am, or am not,
>> whatever nasty thing you may be thinking is not up for debate: I
>> am not, and that is final, and I will not budge on that score.
>
> I am delighted to hear it, and would not contradict you for the
> world.
Fine. Then you'll go away now and leave me in peace?
From: Lars Enderin
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4A26A08B.8000200@telia.com>
Seamus MacRae wrote:
> Richard Heathfield forgot to stop attacking me:
>> Seamus MacRae said:
>>> How can you measure the size of something you don't actually have?
>>
>> By knowing its type.
>
> That doesn't work for variable-length arrays.
>
>>> Don't forget C99 added variable-length arrays.
>>
>> Right
>
> Well, there you go then.
>
Except that Richard's statement was
>> Right, but that's irrelevant to the case in point.
Your fraudulent quoting does not prove your point, quite the opposite.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p088$tek$7@news.eternal-september.org>
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Richard Heathfield forgot to stop attacking me:
>>> Seamus MacRae said:
>>>> How can you measure the size of something you don't actually have?
>>>
>>> By knowing its type.
>>
>> That doesn't work for variable-length arrays.
>>
>>>> Don't forget C99 added variable-length arrays.
>>>
>>> Right
>>
>> Well, there you go then.
>>
> Except that
Except nothing. C99 did, indeed, add variable-length arrays.
> Your fraudulent [rest deleted]
Nothing about me is fraudulent, so the rest of your missive is null and
void. Have a nice day.
From: Lars Enderin
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4A3005DD.8080002@telia.com>
Seamus MacRae wrote:
> Lars Enderin wrote:
>> Seamus MacRae wrote:
>>> Richard Heathfield forgot to stop attacking me:
>>>> Seamus MacRae said:
>>>>> How can you measure the size of something you don't actually have?
>>>>
>>>> By knowing its type.
>>>
>>> That doesn't work for variable-length arrays.
>>>
>>>>> Don't forget C99 added variable-length arrays.
>>>>
>>>> Right
>>>
>>> Well, there you go then.
>>>
>> Except that
>
> Except nothing. C99 did, indeed, add variable-length arrays.
Which is irrelevant to the case in point, namely that the compiler knows
the size of the simple struct discussed, *without evaluating* *foo.
>> Your fraudulent [rest deleted]
>
> Nothing about me is fraudulent, so the rest of your missive is null and
> void. Have a nice day.
It's obvious that you are a fraud.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u5oj$iab$3@news.eternal-september.org>
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Lars Enderin wrote:
>>> Seamus MacRae wrote:
>>>> Richard Heathfield forgot to stop attacking me:
>>>>> Seamus MacRae said:
>>>>>> How can you measure the size of something you don't actually have?
>>>>>
>>>>> By knowing its type.
>>>>
>>>> That doesn't work for variable-length arrays.
>>>>
>>>>>> Don't forget C99 added variable-length arrays.
>>>>>
>>>>> Right
>>>>
>>>> Well, there you go then.
>>>>
>>> Except that
>>
>> Except nothing. C99 did, indeed, add variable-length arrays.
>
> Which is irrelevant
Clearly not, as demonstrated.
>>> Your fraudulent [rest deleted]
>>
>> Nothing about me is fraudulent, so the rest of your missive is null
>> and void. Have a nice day.
>
> It's obvious that you are a fraud.
I am not.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh357rn.e12.willem@snail.stack.nl>
Seamus MacRae wrote:
) Lars Enderin wrote:
)> Seamus MacRae wrote:
)>> Except nothing. C99 did, indeed, add variable-length arrays.
)>
)> Which is irrelevant
)
) Clearly not, as demonstrated.
How ? A struct can not contain a VLA, if you recall.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h10mrh$jpm$2@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Lars Enderin wrote:
> )> Seamus MacRae wrote:
> )>> Except nothing. C99 did, indeed, add variable-length arrays.
> )>
> )> Which is irrelevant
> )
> ) Clearly not, as demonstrated.
>
> How ?
Read my previous posts.
From: Lars Enderin
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4A33E0B6.8040503@telia.com>
Seamus MacRae wrote:
> Willem wrote:
>> Seamus MacRae wrote:
>> ) Lars Enderin wrote:
>> )> Seamus MacRae wrote:
>> )>> Except nothing. C99 did, indeed, add variable-length arrays.
>> )> )> Which is irrelevant
>> )
>> ) Clearly not, as demonstrated.
>>
>> How ?
>
> Read my previous posts.
Which do nothing to defend your standpoint.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h139qt$731$1@news.eternal-september.org>
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Willem wrote:
>>> Seamus MacRae wrote:
>>> ) Lars Enderin wrote:
>>> )> Seamus MacRae wrote:
>>> )>> Except nothing. C99 did, indeed, add variable-length arrays.
>>> )> )> Which is irrelevant
>>> )
>>> ) Clearly not, as demonstrated.
>>>
>>> How ?
>>
>> Read my previous posts.
>
> Which do nothing
In your eyes, maybe.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <dNGdnWnhwKzyM7vXnZ2dnUVZ8rFi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield forgot to stop attacking me:
No, Richard Heathfield doesn't attack you. If you think he's
attacking you, you're mistaken. He has consistently tried to bring
this discussion back to the semantics of sizeof, and you have
consistently tried to focus on personalities instead.
>> Seamus MacRae said:
>>> How can you measure the size of something you don't actually
>>> have?
>>
>> By knowing its type.
>
> That doesn't work for variable-length arrays.
>
>>> Don't forget C99 added variable-length arrays.
>>
>> Right
>
> Well, there you go then.
Selective quotation again. What I actually said was: "Right, but
that's irrelevant to the case in point."
>>>> Since you have rejected
>>> I reject any claim that implies that I'm some sort of doofus,
>>> especially if that claim was made publicly.
>>
>> The C Standard doesn't even mention you, let alone call you a
>> doofus.
>
> No, you do. It is you that I am objecting to.
But why focus on personalities when there's a technical discussion
to be had?
>
>>>> I'd like to know what sources of information you _would_
>>>> believe.
>>> When the discussion has become a platform for launching personal
>>> attacks, I *won't* believe any information whatsoever that says
>>> something hostile about me.
>>
>> As far as I'm aware, the C Standard says nothing whatsoever about
>> you in any way, shape or form, let alone anything hostile.
>
> No, you do. It is you that I am objecting to.
But why focus on personalities when there's a technical discussion
to be had?
> Stop trying to change the subject to the C standard, which, as you
> say, is irrelevant to the matter of your insulting me repeatedly.
I'm not trying to change the subject. I'm trying to revert it back
to what it was - i.e. a discussion of the semantics of sizeof -
despite your efforts to the contrary.
>
>>> So you can get that idea right out of your head, right now. I've
>>> no interest in "discussing" myself at all -- I will ignore the
>>> subject unless someone else brings it up,
>>
>> Great!
>
> Then will you shut up about me now?
I'm interested in discussing the semantics of sizeof.
>
>>> and then I will defend myself to the maximum extent possible,
>>> without any negotiation or compromise. Whether I am, or am not,
>>> whatever nasty thing you may be thinking is not up for debate: I
>>> am not, and that is final, and I will not budge on that score.
>>
>> I am delighted to hear it, and would not contradict you for the
>> world.
>
> Fine. Then you'll go away now and leave me in peace?
Nobody is forcing you to read my articles.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
On Jun 3, 10:15 am, Richard Heathfield <····@see.sig.invalid> wrote:
> Seamus MacRae said:
>
> > Richard Heathfield forgot to stop attacking me:
>
> No, Richard Heathfield doesn't attack you. If you think he's
> attacking you, you're mistaken. He has consistently tried to bring
> this discussion back to the semantics of sizeof, and you have
> consistently tried to focus on personalities instead.
Richard,
The emphasis in this paragraph is pertinent; the word "consistently"
stands out. A saying which is attributed to Einstein is "The
definition of insanity is doing the same thing over and over again and
expecting different results". By that definition, Seamus MacRae is
clearly demonstrating insanity. He may not in fact be insane, but his
behavior is that of an insane person; he consistently tries to answer
every perceived slight as if not doing so would harm his reputation,
even though the results are always the same.
Now the question is: are you going to continue this insanity? It only
takes one to drop a conversation, and all you need to do is to stop.
It is clear that Seamus can't stop himself. The question is: can you?
Duane
From: Paul Donnelly
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87bpp5av7d.fsf@plap.localdomain>
·····@franz.com writes:
> The emphasis in this paragraph is pertinent; the word "consistently"
> stands out. A saying which is attributed to Einstein is "The
> definition of insanity is doing the same thing over and over again and
> expecting different results". By that definition, Seamus MacRae is
> clearly demonstrating insanity. He may not in fact be insane, but his
> behavior is that of an insane person; he consistently tries to answer
> every perceived slight as if not doing so would harm his reputation,
> even though the results are always the same.
I think everybody should stop to consider that rather than a
garden-variety troll, this person you're arguing with may actually be
mentally ill. It might be better to hedge on the side of caution and
quit disturbing the disturbed.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <tpOdnTctoIg1YrvXnZ2dnUVZ8jqlnZ2d@bt.com>
Paul Donnelly said:
<snip>
>
> I think everybody should stop to consider that rather than a
> garden-variety troll, this person you're arguing with may actually
> be mentally ill. It might be better to hedge on the side of
> caution and quit disturbing the disturbed.
I'm beginning to think you might be right.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
On 4 June, 00:02, Richard Heathfield <····@see.sig.invalid> wrote:
> Paul Donnelly said:
> > I think everybody should stop to consider that rather than a
> > garden-variety troll, this person you're arguing with may actually
> > be mentally ill. It might be better to hedge on the side of
> > caution and quit disturbing the disturbed.
>
> I'm beginning to think you might be right.
trouble with that is it reinforces his idea than he
can get his own way by being badly behaved. But I can't
see you getting anywhere with this.
Hopefully he gets some sort of check in the real world.
--
Nick Keighley
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <r8mdnXTCfN9zL7rXnZ2dnUVZ8nJi4p2d@bt.com>
····················@hotmail.com said:
> On 4 June, 00:02, Richard Heathfield <····@see.sig.invalid> wrote:
>> Paul Donnelly said:
>
>> > I think everybody should stop to consider that rather than a
>> > garden-variety troll, this person you're arguing with may
>> > actually be mentally ill. It might be better to hedge on the
>> > side of caution and quit disturbing the disturbed.
>>
>> I'm beginning to think you might be right.
>
>
> trouble with that is it reinforces his idea than he
> can get his own way by being badly behaved.
His objective appears to be that of convincing people that he isn't
an idiot. I'm not convinced that his behaviour achieves this
objective.
> But I can't see you getting anywhere with this.
Well, he's not going to be persuaded about sizeof, obviously - but
that's his problem, not mine.
> Hopefully he gets some sort of check in the real world.
A dole check, perhaps?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p15e$96d$1@news.eternal-september.org>
Richard Heathfield wrote:
> ····················@hotmail.com said:
>> On 4 June, 00:02, Richard Heathfield <····@see.sig.invalid> wrote:
>>> Paul Donnelly said:
>>>> I think everybody should stop to consider that rather than a
>>>> garden-variety troll, this person you're arguing with may
>>>> actually be mentally ill. It might be better to hedge on the
>>>> side of caution and quit disturbing the disturbed.
>>> I'm beginning to think you might be right.
He is not. I am neither a troll nor insane.
>> trouble with that is it reinforces his idea than he
>> can get his own way by being badly behaved.
I am not badly behaved, and in this case "getting my way" merely means
having my rights, and the charters of three newsgroups, respected by you
rabble.
> His objective appears to be that of convincing people that he isn't
> an idiot. I'm not convinced that his behaviour achieves this
> objective.
That's because you're biased, already poisoned by the slanders of my
name. Proof positive that your, and others', behavior is the bad
behavior that is in need of opposition here.
>> Hopefully he gets some sort of check in the real world.
>
> A dole check, perhaps?
So, now one of you is threatening to blackball me in the industry? I
shall certainly be forwarding this message to my attorney. He will be
mighty interested in this, since it not only implies extortative threats
-- lie down and accept our abuse or lose your job -- but also some sort
of collusion in hiring practises. If more evidence of that turns up
during discovery, you and whoever you work for could find yourselves
staring down the barrel of a DOJ antitrust suit, and not just some
defamation, invasion of privacy, and extortion charges brought by an
ordinary individual.
From: Alf P. Steinbach
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p1s1$eo7$1@news.eternal-september.org>
* Seamus MacRae:
> Richard Heathfield wrote:
>> ····················@hotmail.com said:
>>> On 4 June, 00:02, Richard Heathfield <····@see.sig.invalid> wrote:
>>>> Paul Donnelly said:
>>>>> I think everybody should stop to consider that rather than a
>>>>> garden-variety troll, this person you're arguing with may
>>>>> actually be mentally ill. It might be better to hedge on the
>>>>> side of caution and quit disturbing the disturbed.
>>>> I'm beginning to think you might be right.
>
> He is not. I am neither a troll nor insane.
The evidence (misquoting, ignoring facts, using inflaming phrases,
reinterpreting everything and anything as personal, etc.) indicates that you're
trolling. It's amazing that Richard didn't notice even before your statement
about sizeof. I guess he did notice shortly afterwards and is just having a bit
of fun. Anyway it's a pleasure to read his articles. Not to forget, Lisp sucks. :-)
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u5pv$iab$4@news.eternal-september.org>
Alf P. Steinbach wrote:
> * Seamus MacRae:
>> Richard Heathfield wrote:
>>> ····················@hotmail.com said:
>>>> On 4 June, 00:02, Richard Heathfield <····@see.sig.invalid> wrote:
>>>>> Paul Donnelly said:
>>>>>> I think everybody should stop to consider that rather than a
>>>>>> garden-variety troll, this person you're arguing with may
>>>>>> actually be mentally ill. It might be better to hedge on the
>>>>>> side of caution and quit disturbing the disturbed.
>>>>> I'm beginning to think you might be right.
>>
>> He is not. I am neither a troll nor insane.
>
> The evidence (misquoting, ignoring facts, using inflaming phrases,
> reinterpreting everything and anything as personal, etc.) indicates that
> you're trolling.
Yes, that evidence certainly does indicate that Richard Heathfield is
trolling. But what shall we do about it?
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p0rt$402$5@news.eternal-september.org>
····················@hotmail.com wrote:
> On 4 June, 00:02, Richard Heathfield <····@see.sig.invalid> wrote:
>> Paul Donnelly said:
>
>>> I think everybody should stop to consider that rather than a
>>> garden-variety troll, this person you're arguing with may actually
>>> be mentally ill. It might be better to hedge on the side of
>>> caution and quit disturbing the disturbed.
>> I'm beginning to think you might be right.
He is not. I am neither a troll nor insane.
> trouble with that is it reinforces his idea than he
> can get his own way by being badly behaved.
There are three problems with your insinuation above:
1. It is rude.
2. I have not been "badly behaved".
3. In this instance, "getting my way" means having my rights of privacy
and publicity respected, not to mention the charters of three
newsgroups.
> Hopefully he gets some sort of check in the real world.
Is that a threat?
On 10 June, 20:17, Seamus MacRae <··········@live.ca.invalid> wrote:
> ····················@hotmail.com wrote:
> > On 4 June, 00:02, Richard Heathfield <····@see.sig.invalid> wrote:
> >> Paul Donnelly said:
> >>> I think everybody should stop to consider that rather than a
> >>> garden-variety troll, this person you're arguing with may actually
> >>> be mentally ill. It might be better to hedge on the side of
> >>> caution and quit disturbing the disturbed.
>
> >> I'm beginning to think you might be right.
>
> He is not. I am neither a troll nor insane.
>
> > trouble with that is it reinforces his idea than he
> > can get his own way by being badly behaved.
>
> There are three problems with your insinuation above:
>
> 1. It is rude.
not something I see as a problem. I operate iterated prisoner's
dilemma. You behave reasonably and I behave reasonably.
I was polite to you. You were rude to me. I no longer
see a reason to be polite to you.
> 2. I have not been "badly behaved".
foaming at the mouth just because you were unable
to admit you were wrong about an easily verifiable technical issue
seems pretty badly behaved to me.
> 3. In this instance, "getting my way" means having my rights of privacy
you are on public news group. Deal with it.
> and publicity respected,
I'm not sure how you respect publicity. Send a letter
to the newspapers?
> not to mention the charters of three
> newsgroups.
which charters of which news groups? I'm on comp.programming
> > Hopefully he gets some sort of check in the real world.
>
> Is that a threat?
no, just an observation. In the real world people don't put
up with this sort of bratty behaviour.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u78a$vdm$1@news.eternal-september.org>
Nick Keighley wrote:
> On 10 June, 20:17, Seamus MacRae <··········@live.ca.invalid> wrote:
>> ····················@hotmail.com wrote:
>>> trouble with that is it reinforces his idea than he
>>> can get his own way by being badly behaved.
>> There are three problems with your insinuation above:
>>
>> 1. It is rude.
>
> not something I see as a problem.
http://www.gutenberg.org/ebooks/14314
> I operate iterated prisoner's
> dilemma. You behave reasonably and I behave reasonably.
> I was polite to you. You were rude to me.
I am never rude in response to politeness, so you are in error. No doubt
you were rude to me, but mistakenly thought you were being polite.
Helpful hint: Any personal criticisms, expressed or implied, would have
sufficed to make your post impolite.
>> 2. I have not been "badly behaved".
>
> foaming at the mouth
I have not done that.
> you were wrong
I was not.
>> 3. In this instance, "getting my way" means having my rights of privacy
>
> you are on public news group. Deal with it.
http://www.merriam-webster.com/dictionary/rights
>> and publicity respected,
>
> I'm not sure how you respect publicity. Send a letter
> to the newspapers?
My rights of privacy and publicity. My right to control how I am
portrayed in public. "The right of privacy (noun) has one meaning: a
legal right (not explicitly provided in the US Constitution) to be left
alone; the right to live life free from unwarranted publicity."
(http://ezinearticles.com/?Oprah-Right-To-Privacy-or-Secrecy?&id=425547)
You do seem to need a lot of help with commonplace concepts,
definitions, and turns. Perhaps you should bookmark google and
dictionary.com in your browser.
>> not to mention the charters of three newsgroups.
>
> which charters of which news groups? I'm on comp.programming
Those'd be comp.programming, comp.lang.lisp, and
comp.lang.java.programmer, all of which have topic bounds that exclude
posting for the purpose of personally attacking, harassing, or
discussing another person.
Insulting Lisp is on topic in two of them. Discussing/insulting Seamus
MacRae is on topic in zero of them.
ftp://ftp.isc.org/pub/usenet/news.announce.newgroups/comp/comp.programming
http://groups.google.com/group/comp.lang.java.misc/browse_thread/thread/e93c6d8a93f57090/923dbc0091af3f75
(the latter covers clj*)
http://groups.google.com/group/comp.lang.lisp/about?hl=en
(Curiously, the Google Groups about page for cll is the closest thing I
could find on the net to a charter for that group.)
>> Is that a threat?
>
> no, just an observation. In the real world people don't put
> up with this sort of bratty behaviour.
In other words, if you behaved in the real world the way you've behaved
towards me online, you'd get a punch in the nose? I'm glad you realize
that. Admitting your behavior is a problem is always the first step.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh35a8l.ejf.willem@snail.stack.nl>
Seamus MacRae wrote:
) I am never rude in response to politeness, so you are in error. No doubt
) you were rude to me, but mistakenly thought you were being polite.
)
) Helpful hint: Any personal criticisms, expressed or implied, would have
) sufficed to make your post impolite.
So, if I understand you correctly, if anybody disagrees
with you in any way, they are being impolite ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h10mti$jpm$3@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) I am never rude in response to politeness, so you are in error. No doubt
> ) you were rude to me, but mistakenly thought you were being polite.
> )
> ) Helpful hint: Any personal criticisms, expressed or implied, would have
> ) sufficed to make your post impolite.
>
> So, if I understand you correctly, if anybody disagrees
> with you in any way, they are being impolite ?
You do not understand me correctly.
I said personal criticisms, not disagreement. In particular,
disagreement is fine if phrased in such a way as to allow for the
possibility that I'm not wrong.
From: Lars Enderin
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4A33E144.4060800@telia.com>
Seamus MacRae wrote:
> Willem wrote:
>> Seamus MacRae wrote:
>> ) I am never rude in response to politeness, so you are in error. No
>> doubt ) you were rude to me, but mistakenly thought you were being
>> polite.
>> )
>> ) Helpful hint: Any personal criticisms, expressed or implied, would
>> have ) sufficed to make your post impolite.
>>
>> So, if I understand you correctly, if anybody disagrees
>> with you in any way, they are being impolite ?
>
> You do not understand me correctly.
>
> I said personal criticisms, not disagreement. In particular,
> disagreement is fine if phrased in such a way as to allow for the
> possibility that I'm not wrong.
That would be dishonest, since there is no such possibility.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h139v0$731$4@news.eternal-september.org>
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Willem wrote:
>>> Seamus MacRae wrote:
>>> ) I am never rude in response to politeness, so you are in error. No
>>> doubt ) you were rude to me, but mistakenly thought you were being
>>> polite.
>>> )
>>> ) Helpful hint: Any personal criticisms, expressed or implied, would
>>> have ) sufficed to make your post impolite.
>>>
>>> So, if I understand you correctly, if anybody disagrees
>>> with you in any way, they are being impolite ?
>>
>> You do not understand me correctly.
>>
>> I said personal criticisms, not disagreement. In particular,
>> disagreement is fine if phrased in such a way as to allow for the
>> possibility that I'm not wrong.
>
> That would be dishonest
No, it would not. Your namecalling and mudslinging is dishonest.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <UpGdnWoPmJWFfK7XnZ2dnUVZ8lBi4p2d@bt.com>
Seamus MacRae said:
> Willem wrote:
>> Seamus MacRae wrote:
>> ) I am never rude in response to politeness, so you are in error.
>> No doubt ) you were rude to me, but mistakenly thought you were
>> being polite. )
>> ) Helpful hint: Any personal criticisms, expressed or implied,
>> would have ) sufficed to make your post impolite.
>>
>> So, if I understand you correctly, if anybody disagrees
>> with you in any way, they are being impolite ?
>
> You do not understand me correctly.
>
> I said personal criticisms, not disagreement. In particular,
> disagreement is fine if phrased in such a way as to allow for the
> possibility that I'm not wrong.
That's fine unless the possibility that you are not wrong does not
exist. When you make claims such as these:
1) sizeof evaluates its operand;
2) sizeof takes an argument;
3) structures can take variable-length arrays as members;
there is no possibility of your being right. If you think that it is
impolite for me to point out that you are definitely wrong with no
possible exceptions on the above matters, that is your right - just
as it is my right to think that you're a bozo.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <k-OdnfM1vuhJca7XnZ2dnUVZ8jdi4p2d@bt.com>
Richard Heathfield said:
> Seamus MacRae said:
>
>> Willem wrote:
>>> Seamus MacRae wrote:
>>> ) I am never rude in response to politeness, so you are in
>>> error. No doubt ) you were rude to me, but mistakenly thought
>>> you were being polite. )
>>> ) Helpful hint: Any personal criticisms, expressed or implied,
>>> would have ) sufficed to make your post impolite.
>>>
>>> So, if I understand you correctly, if anybody disagrees
>>> with you in any way, they are being impolite ?
>>
>> You do not understand me correctly.
>>
>> I said personal criticisms, not disagreement. In particular,
>> disagreement is fine if phrased in such a way as to allow for the
>> possibility that I'm not wrong.
>
> That's fine unless the possibility that you are not wrong does not
> exist. When you make claims such as these:
>
> 1) sizeof evaluates its operand;
> 2) sizeof takes an argument;
> 3) structures can take variable-length arrays as members;
>
> there is no possibility of your being right. If you think that it
> is impolite for me to point out that you are definitely wrong with
> no possible exceptions on the above matters, that is your right -
> just as it is my right to think that you're a bozo.
I suppose I'd better say it before he does - there is ONE exception
to (1), the VLA thing, and of course that exception doesn't apply
to struct tm anyway so is of no consequence in this discussion.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h139u0$731$3@news.eternal-september.org>
Richard Heathfield wrote:
> Richard Heathfield said:
>> Seamus MacRae said:
>>> I said personal criticisms, not disagreement. In particular,
>>> disagreement is fine if phrased in such a way as to allow for the
>>> possibility that I'm not wrong.
>> That's fine unless the possibility that you are not wrong does not
>> exist.
It always exists.
>> it is my right to think that you're a bozo.
>
> I suppose I'd better say it before he does - there is ONE exception
> to (1), the VLA thing
And there you have it.
On Jun 13, 1:21 pm, Richard Heathfield <····@see.sig.invalid> wrote:
> Richard Heathfield said:
>
>
>
> > Seamus MacRae said:
>
> >> Willem wrote:
> >>> Seamus MacRae wrote:
> >>> ) I am never rude in response to politeness, so you are in
> >>> error. No doubt ) you were rude to me, but mistakenly thought
> >>> you were being polite. )
> >>> ) Helpful hint: Any personal criticisms, expressed or implied,
> >>> would have ) sufficed to make your post impolite.
>
> >>> So, if I understand you correctly, if anybody disagrees
> >>> with you in any way, they are being impolite ?
>
> >> You do not understand me correctly.
>
> >> I said personal criticisms, not disagreement. In particular,
> >> disagreement is fine if phrased in such a way as to allow for the
> >> possibility that I'm not wrong.
>
> > That's fine unless the possibility that you are not wrong does not
> > exist. When you make claims such as these:
>
> > 1) sizeof evaluates its operand;
> > 2) sizeof takes an argument;
> > 3) structures can take variable-length arrays as members;
>
> > there is no possibility of your being right. If you think that it
> > is impolite for me to point out that you are definitely wrong with
> > no possible exceptions on the above matters, that is your right -
> > just as it is my right to think that you're a bozo.
>
> I suppose I'd better say it before he does - there is ONE exception
> to (1), the VLA thing, and of course that exception doesn't apply
> to struct tm anyway so is of no consequence in this discussion.
Please correct any errors in the following coda.
Given the following C99 function,
int oogabooga (int n) {
int vla[n];
return sizeof *vla;
}
The length of the array (variable here, but the same otherwise)
has no bearing upon the value of the expression (sizeof *vla)
as only a single element is referenced. The return value of
this function is therefore a compile-time constant, requiring
0 run-time to compute. As it's such a small number, on all
but the strangest machines it could be an immediate operand
embedded into the machine instruction.
In this nasty
int booger (int n) {
int vla[n];
return sizeof vla;
}
The size of an individual element is known at compile time,
and the size of the whole array is therefore merely n * how-
big-an-int-may-be. Surely the compiler would use a multiplication
or shift instruction. Nothing to dereference. No "evaluation".
In lisp parlance, I believe one would say the operands of
sizeof are implicitly quoted.
With normal, compiled, C, sizeof doesn't actually *do* anything.
It's merely an arithmetic shorthand for a compile-time constant
or (in the one exception) a multiplication.
IMO FWIW HTH YMMV IIRC AMEN
--
laserChicken
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h16372$lco$1@news.eternal-september.org>
luserXtrog wrote:
[snip]
Something is wrong here. Yesterday there were 12 piece-of-shit posts by
you lot here to respond to. Today there are 20. Why have you increased
your posting-volume? You're supposed to be doing the opposite.
> On Jun 13, 1:21 pm, Richard Heathfield <····@see.sig.invalid> wrote:
>> Richard Heathfield said:
>>> Seamus MacRae said:
>>>> I said personal criticisms, not disagreement. In particular,
>>>> disagreement is fine if phrased in such a way as to allow for the
>>>> possibility that I'm not wrong.
>>> That's fine unless the possibility that you are not wrong does not
>>> exist.
It always exists.
>> I suppose I'd better say it before he does - there is ONE exception
>> to (1), the VLA thing
And there you have it.
> In lisp parlance
That nonsense again?
> IMO FWIW HTH YMMV IIRC AMEN
FOAD AMEN
luserXtrog <·······@yahoo.com> writes:
<snip>
> Please correct any errors in the following coda.
>
> Given the following C99 function,
>
> int oogabooga (int n) {
> int vla[n];
> return sizeof *vla;
> }
>
> The length of the array (variable here, but the same otherwise)
> has no bearing upon the value of the expression (sizeof *vla)
> as only a single element is referenced. The return value of
> this function is therefore a compile-time constant, requiring
> 0 run-time to compute. As it's such a small number, on all
> but the strangest machines it could be an immediate operand
> embedded into the machine instruction.
Yes, there is no evaluation and no dereference because the argument to
sizeof is not a VLA.
> In this nasty
>
> int booger (int n) {
> int vla[n];
> return sizeof vla;
> }
>
> The size of an individual element is known at compile time,
> and the size of the whole array is therefore merely n * how-
> big-an-int-may-be. Surely the compiler would use a multiplication
> or shift instruction. Nothing to dereference. No "evaluation".
There is evaluation but no dereference. There is no dereference
because there is no * operator, but there is evaluation. The
evaluation of the operand simply involves yielding the array as the
result. Any multiplication that might be needed is not part of the
evaluation of the operand -- it is part of what sizeof has to do.
Evaluating the operand is so simple that the compiler probably
generates no code for it at all. The evaluation is there because the
standard says it is there. It's effect can be optimised away.
A more subtle case:
void f(int n, bool null)
{
int vla[n];
int (*vlap)[n] = null ? NULL : &vla;
printf("%zu\n", sizeof *vlap);
}
f(10, false) prints 10 * sizeof(int) and is well-defined. What about
f(10, true)? The type of the operand of sizeof is a VLA type so the
operand is evaluated and I think that second call is UB. I am not
sure why things are defined this way; I can't think of a case where
the evaluation is needed for sizeof to do its job, but that does not
mean there is not such case or no such implementation.
> In lisp parlance, I believe one would say the operands of
> sizeof are implicitly quoted.
Except when the type is a VLA type.
> With normal, compiled, C, sizeof doesn't actually *do* anything.
> It's merely an arithmetic shorthand for a compile-time constant
> or (in the one exception) a multiplication.
I am not sure why you want to say this. It reads to me as "sizeof
does not need to do anything except when it has to so something" :-)
--
Ben.
On Jun 15, 8:52 am, Ben Bacarisse <··········@bsb.me.uk> wrote:
> luserXtrog <·······@yahoo.com> writes:
>
<snipped very good stuff for size>
> > With normal, compiled, C, sizeof doesn't actually *do* anything.
> > It's merely an arithmetic shorthand for a compile-time constant
> > or (in the one exception) a multiplication.
>
> I am not sure why you want to say this. It reads to me as "sizeof
> does not need to do anything except when it has to so something" :-)
It was an attempt to reiterate the compile-time/run-time distinction.
I was trying to be more insistent that sizeof has access to all its
information at compile-time (with the exception that variable sizes
have to be scaled at run-time) such that sizeof need not have any
real *presense* in the executable image. Its behavior is to yield
a value, but that value can be obtained by the running program
without "performing its 'sizeof' operation and propagating that
value down to a parent frame". [This is not a quotation: imagine
I'm waving two fingers on each hand up and down in the air to
simulate these quotation marks.]
I feel like I'm trying to convey something significant and important
but I fear i am failing and that I may not be up to the challenge.
I may even be wrong.
--
lexit
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h163bi$lco$2@news.eternal-september.org>
luserXtrog wrote:
> On Jun 15, 8:52 am, Ben Bacarisse <··········@bsb.me.uk> wrote:
>> luserXtrog <·······@yahoo.com> writes:
>>
>
> <snipped very good stuff for size>
>
>>> With normal, compiled, C, sizeof doesn't actually *do* anything.
>>> It's merely an arithmetic shorthand for a compile-time constant
>>> or (in the one exception) a multiplication.
>> I am not sure why you want to say this. It reads to me as "sizeof
>> does not need to do anything except when it has to so something" :-)
>
> It was an attempt to reiterate the compile-time/run-time distinction.
It doesn't need reiterating. This debate should be dead and buried already.
> I feel like I'm trying to convey something significant and important
> but I fear i am failing and that I may not be up to the challenge.
>
> I may even be wrong.
About me, you most certainly are.
luserXtrog <·······@yahoo.com> writes:
> On Jun 15, 8:52 am, Ben Bacarisse <··········@bsb.me.uk> wrote:
>> luserXtrog <·······@yahoo.com> writes:
>>
>
> <snipped very good stuff for size>
>
>> > With normal, compiled, C, sizeof doesn't actually *do* anything.
>> > It's merely an arithmetic shorthand for a compile-time constant
>> > or (in the one exception) a multiplication.
>>
>> I am not sure why you want to say this. It reads to me as "sizeof
>> does not need to do anything except when it has to so something" :-)
>
> It was an attempt to reiterate the compile-time/run-time distinction.
> I was trying to be more insistent that sizeof has access to all its
> information at compile-time (with the exception that variable sizes
> have to be scaled at run-time) such that sizeof need not have any
> real *presense* in the executable image. Its behavior is to yield
> a value, but that value can be obtained by the running program
> without "performing its 'sizeof' operation and propagating that
> value down to a parent frame". [This is not a quotation: imagine
> I'm waving two fingers on each hand up and down in the air to
> simulate these quotation marks.]
>
> I feel like I'm trying to convey something significant and important
> but I fear i am failing and that I may not be up to the challenge.
>
> I may even be wrong.
Do you think there is a substantive difference between:
size_t f(int n) { int tmp[n]; return sizeof tmp; }
and
size_t g(int n) { return n * sizeof(int); }
? Both need to access n and do a multiplication at run-time. I am
not sure the distinction you are making is a good one.
[It may soon be time to trim the groups to comp.programming. There
have been no complaints for the good folk in the two language specific
groups but they can't be that interested. I am never sure when the
best time to trim groups or set followup-to is.]
--
Ben.
On Jun 15, 12:46 pm, Ben Bacarisse <··········@bsb.me.uk> wrote:
<snippity>
> Do you think there is a substantive difference between:
>
> size_t f(int n) { int tmp[n]; return sizeof tmp; }
>
> and
>
> size_t g(int n) { return n * sizeof(int); }
>
> ?
Not at all (with obvious optimization performed).
> Both need to access n and do a multiplication at run-time. I am
> not sure the distinction you are making is a good one.
The distinction I was trying to make was more like that between these:
size_t h (int n) { return n * 4; }
size_t i (int n) { int tmp[n];
return n * sizeof(typeof(_identifier("tmp"))); }
I was trying to imagine what erroneous assumptions one would
have to have made in order to expect that something like this
would be unsafe:
size_t j (int *foo) { return sizeof *foo; }
--
chicken chicken chicken
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18ihn$5lo$2@news.eternal-september.org>
luserXtrog wrote:
> I was trying to imagine what erroneous assumptions
The only erroneous assumption made here was your assumption that you
could sneak an insult past me undetected.
On Jun 16, 11:51 am, Seamus MacRae <··········@live.ca.invalid> wrote:
> luserXtrog wrote:
> > I was trying to imagine what erroneous assumptions
>
> The only erroneous assumption made here was your assumption that you
> could sneak an insult past me undetected.
Heh.
From: Raymond Wiker
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <m2vdmuwv14.fsf@RAWMBP-2.local>
Seamus MacRae <··········@live.ca.invalid> writes:
> luserXtrog wrote:
>> I was trying to imagine what erroneous assumptions
>
> The only erroneous assumption made here was your assumption that you
> could sneak an insult past me undetected.
It seems to me that you are the sort of person that Dr
Spooner would describe as a "shining wit".
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h139sn$731$2@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Willem wrote:
>>> Seamus MacRae wrote:
>>> ) I am never rude in response to politeness, so you are in error.
>>> No doubt ) you were rude to me, but mistakenly thought you were
>>> being polite. )
>>> ) Helpful hint: Any personal criticisms, expressed or implied,
>>> would have ) sufficed to make your post impolite.
>>>
>>> So, if I understand you correctly, if anybody disagrees
>>> with you in any way, they are being impolite ?
>> You do not understand me correctly.
>>
>> I said personal criticisms, not disagreement. In particular,
>> disagreement is fine if phrased in such a way as to allow for the
>> possibility that I'm not wrong.
>
> That's fine unless the possibility that you are not wrong does not
> exist.
It always exists.
> it is my right to think that you're a bozo.
Unfortunately, you seem to feel you have the right to actually SAY so,
loudly, in public, repeatedly. You might want to read up on defamation law.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <LfCdnVubGfMd06jXnZ2dnUVZ8kFi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>> Willem wrote:
>>>> Seamus MacRae wrote:
>>>> ) I am never rude in response to politeness, so you are in
>>>> error. No doubt ) you were rude to me, but mistakenly thought
>>>> you were being polite. )
>>>> ) Helpful hint: Any personal criticisms, expressed or implied,
>>>> would have ) sufficed to make your post impolite.
>>>>
>>>> So, if I understand you correctly, if anybody disagrees
>>>> with you in any way, they are being impolite ?
>>> You do not understand me correctly.
>>>
>>> I said personal criticisms, not disagreement. In particular,
>>> disagreement is fine if phrased in such a way as to allow for
>>> the possibility that I'm not wrong.
>>
>> That's fine unless the possibility that you are not wrong does
>> not exist.
>
> It always exists.
Well, who'd have thunk it? You're wrong AGAIN. In each of the three
cases I itemised, you were *provably* wrong, according to ISO/IEC
9899, which is the International Standard governing the language
under discussion. The only way you could be right is for the
Standard to be wrong. Since the Standard is right /by definition/,
you cannot be right on any of those three points.
>> it is my right to think that you're a bozo.
>
> Unfortunately, you seem to feel you have the right to actually SAY
> so, loudly, in public, repeatedly.
Yes, I do have that right, although I haven't actually availed
myself of it /repeatedly/ as you seem to think.
> You might want to read up on defamation law.
You lied, and I can prove it. How will that look to a jury?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h163fj$lco$3@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> I said personal criticisms, not disagreement. In particular,
>>>> disagreement is fine if phrased in such a way as to allow for
>>>> the possibility that I'm not wrong.
>>> That's fine unless the possibility that you are not wrong does
>>> not exist.
>> It always exists.
>
> Well, who'd have thunk it?
Apparently you didn't.
> [calls me an idiot]
No, you're the idiot, remember?
>>> it is my right to think that you're a bozo.
>> Unfortunately, you seem to feel you have the right to actually SAY
>> so, loudly, in public, repeatedly.
>
> Yes, I do have that right
No, you don't. It's called defamation. Google it.
>> You might want to read up on defamation law.
>
> [calls me a liar]
No, really. Google it if you don't believe me.
P.S. No, you're the liar, remember?
From: Bruce C. Baker
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <RIwZl.27267$y42.19605@newsfe21.iad>
"Seamus MacRae" <··········@live.ca.invalid> wrote in message
·················@news.eternal-september.org...
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>> Richard Heathfield wrote:
>>>> Seamus MacRae said:
>>>>> I said personal criticisms, not disagreement. In particular,
>>>>> disagreement is fine if phrased in such a way as to allow for
>>>>> the possibility that I'm not wrong.
>>>> That's fine unless the possibility that you are not wrong does
>>>> not exist.
>>> It always exists.
>>
>> Well, who'd have thunk it?
>
> Apparently you didn't.
>
>> [calls me an idiot]
>
> No, you're the idiot, remember?
>
>>>> it is my right to think that you're a bozo.
>>> Unfortunately, you seem to feel you have the right to actually SAY
>>> so, loudly, in public, repeatedly.
>>
>> Yes, I do have that right
>
> No, you don't. It's called defamation. Google it.
>
>>> You might want to read up on defamation law.
>>
>> [calls me a liar]
>
> No, really. Google it if you don't believe me.
>
> P.S. No, you're the liar, remember?
Seamus, if you had half a brain, you'd declare victory and move on. Ditto
for the rest of you.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <LYSdndTKI_rSAavXnZ2dnUVZ8i9i4p2d@bt.com>
Bruce C. Baker said:
<snip>
> Seamus, if you had half a brain, you'd declare victory and move
> on. Ditto for the rest of you.
But those with a *complete* brain realise that it isn't about
winning or losing. It's about correctness. Seamus MacRae has made
the following claims:
1) sizeof evaluates a (non-VLA) operand - a claim he made in article
<············@news.eternal-september.org>
2) sizeof takes an argument - a claim he made in article
<············@news.eternal-september.org>, although you'll have to
wade through a lot of extraneous junk if you want to track that
claim down - to make it easier, here's an exact quote:
++++++++++++++ quote from <············@news.eternal-september.org>
> Sure - but this isn't *foo; it's sizeof *foo
Which contains *foo as an argument, for heaven's sake.
++++++++++++++ end quote
3) VLAs can be members of structures, a claim he made in a number of
articles, including <············@news.eternal-september.org>
If he is prepared to put forward technical arguments to support
these claims, then the possibility remains that a constructive
dialogue could take place. There are, however, few signs that he is
prepared to put forward technical arguments. (This is hardly
surprising, since the C Standard flatly contradicts him on all
three counts.) For as long as he maintains the position "I'm right,
and anyone who says otherwise is libelling me", I don't see how
anyone can take him seriously, and therefore it is apparent that
there is little or no value in replying to him except perhaps to
correct any further technical errors.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Paul Donnelly
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87iqixgmao.fsf@plap.localdomain>
Richard Heathfield <···@see.sig.invalid> writes:
> Bruce C. Baker said:
>
> <snip>
>
>> Seamus, if you had half a brain, you'd declare victory and move
>> on. Ditto for the rest of you.
>
> But those with a *complete* brain realise that it isn't about
> winning or losing. It's about correctness.
Those *using* it realize that you can't stop people from being wrong on
the Internet, you've made your point, and you're wasting your time.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gdednXkQFvqsTavXnZ2dnUVZ8tZi4p2d@bt.com>
Paul Donnelly said:
> Richard Heathfield <···@see.sig.invalid> writes:
>
>> Bruce C. Baker said:
>>
>> <snip>
>>
>>> Seamus, if you had half a brain, you'd declare victory and move
>>> on. Ditto for the rest of you.
>>
>> But those with a *complete* brain realise that it isn't about
>> winning or losing. It's about correctness.
>
> Those *using* it realize that you can't stop people from being
> wrong on the Internet, you've made your point, and you're wasting
> your time.
Quick! The tide's coming in! Fetch my throne!
(i.e. yes, I do realise this. But it's still about correctness, or
at least it should be.)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18jcm$g1d$3@news.eternal-september.org>
Richard Heathfield wrote:
> Paul Donnelly said:
>> Richard Heathfield <···@see.sig.invalid> writes:
>>> Bruce C. Baker said:
>>>> Seamus, if you had half a brain[deleted]
I have a full and normal brain, thanks.
>>> [insult deleted]
>> Those *using* it realize that you can't stop people from being
>> wrong on the Internet, you've made your point, and you're wasting
>> your time.
You certainly can't stop people from being wrong on the Internet by
viciously attacking someone who *wasn't even wrong*.
> Quick! The tide's coming in! Fetch my throne!
And Richard unravels completely. Stark, raving, someone get a
straitjacket stat!
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18j9h$g1d$2@news.eternal-september.org>
Paul Donnelly wrote:
> Richard Heathfield <···@see.sig.invalid> writes:
>> Bruce C. Baker said:
>>> Seamus, if you had half a brain[deleted]
I have a full and normal brain, thanks.
>> [insult deleted]
>
> Those *using* it realize that you can't stop people from being wrong on
> the Internet, you've made your point, and you're wasting your time.
You especially can't stop people from being wrong on the Internet by
rudely berating a person that *wasn't even wrong*.
From: Kaz Kylheku
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <20090615124427.-553@gmail.com>
["Followup-To:" header set to comp.lang.lisp.]
On 2009-06-15, Richard Heathfield <···@see.sig.invalid> wrote:
> Bruce C. Baker said:
>
><snip>
>
>> Seamus, if you had half a brain, you'd declare victory and move
>> on. Ditto for the rest of you.
>
> But those with a *complete* brain realise that it isn't about
> winning or losing. It's about correctness. Seamus MacRae has made
> the following claims:
>
> 1) sizeof evaluates a (non-VLA) operand - a claim he made in article
><············@news.eternal-september.org>
Once the subject has been beat to death and substantially documented with all
the relevant references, there is really nothing more to say. Anyone following
the thread can sort out the right from the wrong. The subsequent shouting is no
longer about correctness; correctness is only a thin pretext for browbeating
some lunatic into admitting that he's wrong, which will likely never happen.
It's okay to let it be.
I recommend that if you can't refrain from following up to MacRae, then at
least refrain from following up to a MacRae when he's already ``defending''
himself against some prior correction.
Only if he posts a new piece of misinformation, then correct it.
Of course he will have some inane retort for it, but that retort isn't
a new piece of technical misinformation, just crap like ``stop attacking me''
or ``[vicious personal attack snipped] I am not wrong''.
This non-content is not worth responding to. By now, you know exactly what the
result is of responding to it. There will never be any other result.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18j6m$g1d$1@news.eternal-september.org>
Kaz Kylheku wrote:
> On 2009-06-15, Richard Heathfield <···@see.sig.invalid> wrote:
>> Bruce C. Baker said:
>>
>> <snip>
>>
>>> Seamus, if you had half a brain[deleted]
I have a full and normal brain, thanks.
>> Seamus MacRae has made the following claims
I don't need Richard to put words in my mouth. I can speak for myself,
thanks.
> Once the subject has been beat to death and substantially documented with all
> the relevant references, there is really nothing more to say. Anyone following
> the thread can sort out the right from the wrong.
And the assholes from the guy that's just trying to defend himself
against unwarranted and increasingly strident criticism.
> The subsequent shouting is no longer about correctness; correctness is only a
> thin pretext for browbeating
That much is apparent. Browbeating is an excellent way to describe all
of your reprehensible behavior.
> some lunatic
No. I am not a lunatic.
> into [crying "uncle"], which will likely never happen.
Likely? Definitely. Crying "uncle" is like rolling out a red carpet for
bullies. They'll have you marked down as "easy pickings" once you do.
> I recommend that if you can't refrain from following up to MacRae, then at
> least refrain from following up to a MacRae when he's already defending
> himself against some prior [insult].
Better yet, never insult me in the first place.
> Only if he posts a new piece of misinformation, then correct it.
I never post misinformation, so that last is superfluous, unless its
real purpose was to seed the notion in people's minds that I do post
misinformation, in which case you are guilty of insidiously insulting me
some more.
> Of course he will have some retort for it
I certainly shall, jerkwad.
> but that retort isn't a new piece of technical misinformation
It can't be, since *nothing* I write is misinformation.
> just crap like ``stop attacking me''
That is not "crap"; it is an insistence upon my rights being respected.
> This non-content is not worth responding to.
It is not "non-content", but you are right, it is not worth replying to.
The only response should be for my attacker to sit back and contemplate
the error of his ways, perhaps one day to be more enlightened in how he
treats people in the future and how polite he is to strangers in public.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18iqg$cma$1@news.eternal-september.org>
Richard Heathfield wrote:
> Bruce C. Baker said:
>> Seamus, if you had half a brain[deleted]
I have a full and normal brain, thank you very much.
> Seamus MacRae has made the following claims
I can speak for myself. I don't need you to put words in my mouth for
me, thank you very much.
> [calls me an idiot repeatedly]
No, you're the idiot, remember?
> the possibility remains that a constructive dialogue could take
> place.
Not given the way you're acting. You apparently will only allow a
"constructive dialog" to take place on your terms, and your terms
apparently require my unconditional surrender and public acceptance of
your insulting judgments of me.
I refuse.
> I don't see how anyone can take him seriously
I manage to do so.
> it is apparent that there is little or no value in replying to him
The problem is that you keep replying to OTHER people to badmouth me as
well, as you have done here, replying to Bruce to badmouth me. If you
would just shut up about me COMPLETELY, we'd have peace here again.
> except perhaps to correct
No. Nothing about me needs "correcting", particularly not by a prick
like you.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18ijv$5lo$3@news.eternal-september.org>
Bruce C. Baker wrote:
> "Seamus MacRae" <··········@live.ca.invalid> wrote in message
> ·················@news.eternal-september.org...
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> You might want to read up on defamation law.
>>> [calls me a liar]
>> No, really. Google it if you don't believe me.
>>
>> P.S. No, you're the liar, remember?
>
> Seamus, if you had half a brain, [rest of post deleted unread]
I don't respond well to being addressed in so rude a manner.
I have a full and normal brain, thank you very much.
From: Thomas A. Russ
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <ymi3aa14g4y.fsf@blackcat.isi.edu>
[Post targets trimmed, replies trimmed even more]
Seamus MacRae <··········@live.ca.invalid> writes:
> I said personal criticisms, not disagreement. In particular,
> disagreement is fine if phrased in such a way as to allow for the
> possibility that I'm not wrong.
But you ARE often wrong. And I find it quite refreshing when posts
specifically and directly say that. Certainly in the co-called "lisp
vs. Java" thread you often posted objectively false information based on
a fundamental technical ignorance of what you were describing. So those
were cases where you were flat-out wrong. So why should we suppress the
facts?
--
Thomas A. Russ, USC/Information Sciences Institute
I wasn't going to enter this thread, but since this seems to be sort of
like the "Nixon enemies" list, it would be a dishonor not to be on it.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h163io$lco$4@news.eternal-september.org>
Thomas A. Russ wrote:
> [Post targets trimmed, replies trimmed even more]
[comp.lang.java.programmer restored, so people there are less likely to
read your insult and not see my rebuttal; followups set appropriately]
> Seamus MacRae <··········@live.ca.invalid> writes:
>> I said personal criticisms, not disagreement. In particular,
>> disagreement is fine if phrased in such a way as to allow for the
>> possibility that I'm not wrong.
>
> But you ARE [an idiot]
No, I am not. I begin to strongly suspect that you are, though.
> [calls me an idiot and a liar, repeatedly]
No, you're the idiot and the liar.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p0oh$402$4@news.eternal-september.org>
Richard Heathfield wrote:
> Paul Donnelly said:
>> I think everybody should stop to consider that rather than a
>> garden-variety troll, this person you're arguing with may actually
>> be mentally ill.
>
> I'm beginning to think you might be right.
He is not. I am neither of the vile, vindictive, vicious vituperations
virulently proposed by Paul Donnelly.
From: Lars Enderin
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4A300701.1010705@telia.com>
Seamus MacRae wrote:
> Richard Heathfield wrote:
>> Paul Donnelly said:
>>> I think everybody should stop to consider that rather than a
>>> garden-variety troll, this person you're arguing with may actually
>>> be mentally ill.
>>
>> I'm beginning to think you might be right.
>
> He is not. I am neither of the vile, vindictive, vicious vituperations
> virulently proposed by Paul Donnelly.
You are, obviously, seriously disturbed. Anyone except you can see that.
Seek help.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u794$vdm$2@news.eternal-september.org>
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Richard Heathfield wrote:
>>> Paul Donnelly said:
>>>> I think everybody should stop to consider that rather than a
>>>> garden-variety troll, this person you're arguing with may actually
>>>> be mentally ill.
>>>
>>> I'm beginning to think you might be right.
>>
>> He is not. I am neither of the vile, vindictive, vicious vituperations
>> virulently proposed by Paul Donnelly.
>
> You are, obviously, seriously disturbed.
I am not.
On Jun 12, 1:37 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
> Lars Enderin wrote:
> > Seamus MacRae wrote:
> >> Richard Heathfield wrote:
> >>> Paul Donnelly said:
> >>>> I think everybody should stop to consider that rather than a
> >>>> garden-variety troll, this person you're arguing with may actually
> >>>> be mentally ill.
>
> >>> I'm beginning to think you might be right.
>
> >> He is not. I am neither of the vile, vindictive, vicious vituperations
> >> virulently proposed by Paul Donnelly.
>
> > You are, obviously, seriously disturbed.
>
> I am not.
Anybody seen 12 Monkeys?
Brad Pitt in the van with a ski mask.
$0.02
--
laserChicken
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h163ki$lco$5@news.eternal-september.org>
luserXtrog wrote:
> On Jun 12, 1:37 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
>> Lars Enderin wrote:
>>> Seamus MacRae wrote:
>>>> Richard Heathfield wrote:
>>>>> Paul Donnelly said:
>>>>>> I think everybody should stop to consider that rather than a
>>>>>> garden-variety troll, this person you're arguing with may actually
>>>>>> be mentally ill.
>>>>> I'm beginning to think you might be right.
>>>> He is not. I am neither of the vile, vindictive, vicious vituperations
>>>> virulently proposed by Paul Donnelly.
>>> You are, obviously, seriously disturbed.
>> I am not.
> [suspected insult]
Whatever negative thing you were intending to convey about me, I hereby
state for the record that it is factually incorrect.
Paul Donnelly wrote:
> I think everybody should stop to consider that rather than a
> garden-variety troll, this person you're arguing with may actually be
> mentally ill. It might be better to hedge on the side of caution and
> quit disturbing the disturbed.
D00dz, have you really not ever come across Seamus MacRae / Neo /
Twisted / etc / etc / etc before? He's pretty famous on the
rec.games.roguelike.* hierarchy - insisting that when he lost a game of
Angband, it was a deliberate attempt by all and sundry to subvert his
life by *not* telling him that it was possible to lose...
I'm not sure that he's trolled rec.games.frp.* yet - Terry Austin would
tear him a new one.
Seriously, the only way to win is not to play at all. I think that's a
quote from somewhere.
Adam
From: Thomas A. Russ
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <ymizlco3qfc.fsf@blackcat.isi.edu>
Adam White <·······@iinet.net.au> writes:
> Seriously, the only way to win is not to play at all. I think that's a
> quote from somewhere.
"WarGames" (1983)
[after playing out all possible outcomes for Global Thermonuclear War]
Joshua: Greetings, Professor Falken.
Stephen Falken: Hello, Joshua.
Joshua: A strange game. The only winning move is not to play. How
about a nice game of chess?
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Adam White <·······@iinet.net.au> writes:
>
>> Seriously, the only way to win is not to play at all. I think that's a
>> quote from somewhere.
>
> "WarGames" (1983)
>
>
> [after playing out all possible outcomes for Global Thermonuclear War]
>
> Joshua: Greetings, Professor Falken.
> Stephen Falken: Hello, Joshua.
> Joshua: A strange game. The only winning move is not to play. How
> about a nice game of chess?
>
Swish! Thanks, I thought that that might be the movie!
[cue troll-boy claiming that Joshua and Stephen Falken were telling lies
about him and must now stop].
Adam "now waiting for troll-boy to claim that Joshua and Stephen
Falken are telling lies about him and must stop" White
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h3c34u$18c$6@news.eternal-september.org>
Adam White wrote:
> Thomas A. Russ wrote:
>> Adam White <·······@iinet.net.au> writes:
>>
>>> Seriously, the only way to win is not to play at all. I think that's a
>>> quote from somewhere.
>>
>> "WarGames" (1983)
>
> Swish! Thanks, I thought that that might be the movie!
Yes, whenever someone like you starts playing the ad hominem game, he
immediately and automatically loses whatever argument he was involved in.
> [cue troll-boy
I am a grown man of 55 and a normal human being.
On Jun 5, 7:48 am, Adam White <·······@iinet.net.au> wrote:
> Thomas A. Russ wrote:
> > Adam White <·······@iinet.net.au> writes:
>
> >> [implied insult deleted]
None of the nasty things that you have said or implied about me are at
all true.
> [cue [insult deleted] claiming that Joshua and Stephen Falken were telling lies
None of the nasty things that you have said or implied about me are at
all true.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h3c33v$18c$5@news.eternal-september.org>
Thomas A. Russ wrote:
> Adam White <·······@iinet.net.au> writes:
>
>> Seriously, the only way to win is not to play at all. I think that's a
>> quote from somewhere.
>
> "WarGames" (1983)
Yes, whenever someone like you starts playing the ad hominem game, he
immediately and automatically loses whatever argument he was involved in.
On Jun 4, 12:38 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Adam White <·······@iinet.net.au> writes:
> > [implied insult deleted]
None of the nasty things that Adam has said or implied about me are at
all true.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h3c33d$18c$4@news.eternal-september.org>
Adam White wrote:
> Paul Donnelly wrote:
>
>> I think everybody should stop to consider that rather than a
>> garden-variety troll, this person you're arguing with may actually be
>> mentally ill. It might be better to hedge on the side of caution and
>> quit disturbing the disturbed.
>
> D00dz, have you really not ever come across Seamus MacRae / Neo /
> Twisted / etc / etc / etc before?
My name is simply Seamus MacRae.
> He's pretty famous on the rec.games.roguelike.* hierarchy
That's news to me. I've never even heard of that hierarchy before today.
> I'm not sure that he's trolled rec.games.frp.* yet - Terry Austin would
> tear him a new one.
I don't respond well to threats.
> Seriously, the only way to win is not to play at all.
Yes, whenever someone like you starts playing the ad hominem game, he
immediately and automatically loses whatever argument he was involved in.
On Jun 4, 8:23 am, Adam White <·······@iinet.net.au> wrote:
> Paul Donnelly wrote:
> > [insults someone, probably either Seamus MacRae or Series Expansion,
> > severely]
>
> D00dz, have you really not ever come across Seamus MacRae / Neo /
> Twisted / etc / etc / etc before?
You are conflating at least two people: Seamus MacRae and myself.
Depending on who you mean by the name "Neo", which of course became
very popular to use online right after the Matrix movies came out, and
on whether Seamus has ever used that name, perhaps three.
> He's pretty famous on the rec.games.roguelike.* hierarchy - [lies
> deleted]
At least, they are lies if you were referring to myself. And I don't
recall ever seeing the name Seamus in rgr*.
Regardless, none of the nasty things that you have said or implied
about me are at all true.
> I'm not sure that he's [insult deleted] yet
Of course not. None of the nasty things that you have said or implied
about me are at all true.
> Terry Austin would tear him a new one.
I don't respond well to threats.
> [implied insult deleted]
None of the nasty things that you have said or implied about me are at
all true.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p0k9$402$3@news.eternal-september.org>
Paul Donnelly wrote:
> ·····@franz.com writes:
>> [accuses me of being crazy]
>
> I think everybody should stop to consider that rather than a
> garden-variety troll, this person you're arguing with may actually be
> mentally ill.
I am neither.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p0jd$402$2@news.eternal-september.org>
·····@franz.com wrote:
> On Jun 3, 10:15 am, Richard Heathfield <····@see.sig.invalid> wrote:
>> Seamus MacRae said:
>>
>>> Richard Heathfield forgot to stop attacking me:
>> No, Richard Heathfield doesn't attack you. If you think he's
>> attacking you, you're mistaken. He has consistently tried to bring
>> this discussion back to the semantics of sizeof, and you have
>> consistently tried to focus on personalities instead.
>
> Richard,
>
> Seamus MacRae is clearly demonstrating insanity.
A vicious lie.
Seamus, we in the community have been subjugated to your eternal
crimes against humanity.
Will you forgvie, and repent, and say that CL is a superior language?
On Jun 5, 7:39 am, ChrisF <·········@gmail.com> wrote:
> Seamus, we in the community have been subjugated to your eternal
> crimes against humanity.
>
> Will you forgvie, and repent, and say that CL is a superior language?
Bring in the comfy chair!
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p16d$96d$2@news.eternal-september.org>
ChrisF wrote:
> Seamus, we in the community have been subjugated to your eternal
> crimes against humanity.
I have committed no crimes against humanity. So far as I am aware,
nobody posting here has.
> Will you forgvie, and repent, and say that CL is a superior language?
I will not.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p0hm$402$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield forgot to stop attacking me:
>
> No, Richard Heathfield doesn't attack you.
Yes, you do. Frequently.
> If you think he's attacking you, you're [insult deleted]
And there you go, doing it again!
> you have consistently tried to focus on personalities instead.
You mean, you have.
>>>> Don't forget C99 added variable-length arrays.
>>> Right
>> Well, there you go then.
>
> [calls me a liar]
No, you're the liar, remember?
Heck, I was only agreeing with a statement you made, agreeing with a
statement I made, so how the hell can I possibly be the liar here?
You are past strange.
>>>>> Since you have rejected
>>>> I reject any claim that implies that I'm some sort of doofus,
>>>> especially if that claim was made publicly.
>>> The C Standard doesn't even mention you, let alone call you a
>>> doofus.
>> No, you do. It is you that I am objecting to.
>
> But why focus on personalities when there's a technical discussion
> to be had?
I don't know. You tell me!
>>>>> I'd like to know what sources of information you _would_
>>>>> believe.
>>>> When the discussion has become a platform for launching personal
>>>> attacks, I *won't* believe any information whatsoever that says
>>>> something hostile about me.
>>> As far as I'm aware, the C Standard says nothing whatsoever about
>>> you in any way, shape or form, let alone anything hostile.
>> No, you do. It is you that I am objecting to.
>
> But why focus on personalities when there's a technical discussion
> to be had?
I don't know. You tell me!
>> Stop trying to change the subject to the C standard, which, as you
>> say, is irrelevant to the matter of your insulting me repeatedly.
>
> I'm not trying to change the subject. I'm trying to revert it back
> to what it was
Yeah, right. Every time you "try to revert it back" you insult me again.
Must not be trying *too* hard, then.
>>>> and then I will defend myself to the maximum extent possible,
>>>> without any negotiation or compromise. Whether I am, or am not,
>>>> whatever nasty thing you may be thinking is not up for debate: I
>>>> am not, and that is final, and I will not budge on that score.
>>> I am delighted to hear it, and would not contradict you for the
>>> world.
>> Fine. Then you'll go away now and leave me in peace?
>
> Nobody is forcing you to read my articles.
The problem is that if you post an article badmouthing me, you're
failing to "leave me in peace" even if I don't read it, because I may
still be subject to subsequent negative consequences from your posting
it. For instance, someone else may read the vicious lies you posted
about me, and, seeing that nobody challenged those lies, believe them,
then subsequently encounter me and mistreat me because of their
erroneous beliefs about me, erroneous beliefs that would not have been
inculcated in them had you not written the attack post. (Or had I
rebutted it instead of, hypothetically, ignoring it.)
To actually leave me in peace, you must not state, or insinuate,
anything negative about me whatsoever.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <Rfednb84hfv1Vb_XnZ2dnUVZ8qdi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
> [snip]
>
> Stop attacking me.
I invite you to review the discussion once more, to find out who
attacked whom. I am less concerned with attacking you than with
debunking the incorrect claim you made.
>>>> Firstly, the preferred idiom is:
>>>>
>>>> struct tm *foo = calloc(sizeof *foo);
>>> Surely not? That dereferences an uninitialized pointer, thereby
>>> invoking undefined behavior.
>>
>> Surely not! The sizeof operator does not evaluate its operand
>
> It must at least partly do so, in order to know what size of thing
> *foo is referring to.
It is *forbidden* to do so, by the language definition. An
implementation that evaluates the operand of a sizeof operator is
not a conforming C implementation.
>>>> Secondly, although all-bits-zero does indeed represent 0.0 or
>>>> NULL on many platforms, it is not guaranteed by the C Standard
>>>> so to do.
>>> Have you ever seen a reasonably modern system where it wasn't?
>>
>> Have you ever seen a reasonably modern system that had precisely
>> the same architecture in all respects as the most common
>> architecture of the previous generation? There are real systems
>> where NULL is not all-bits-zero
>
> Yes, but are any of them in widespread use?
You missed my point. See below.
>
>> and real systems where 0.0 is not all-bits-zero.
>
> Not IEEE754-compatible ones.
You missed my point. See below.
>> In the absence of a guarantee from Silicon Valley that this will
>> never, ever, ever happen again, I will continue to assume the
>> worst when writing code that I need to be maximally portable.
>
> And I will continue to use Java when writing code that I need to
> be maximally portable. C is for systems-level stuff now. :-)
Fine, you're entitled to think that, and to avoid C entirely if you
choose - but there are still people who need to write portable C
code, and it is well for them to write C properly and with an eye
to portability.
>
>>> Then again, dereferencing a bad pointer without actually reading
>>> or writing through it doesn't tend to cause h/w exceptions on
>>> modern machines either.
>>
>> Strawman argument.
>
> Do not personally attack me or accuse me of intellectually
> dishonest behavior again. You have been warned.
It wasn't a personal attack, and I don't give a stuff about your
warning. You are taking this far too personally. This is a
discussion, not a lawsuit.
I described your argument as a strawman argument because your flawed
understanding of sizeof led you to believe, mistakenly, that I had
written code dereferencing a bad pointer. I have already given you
chapter and verse that explains exactly why I wasn't dereferencing
a bad pointer.
<snip>
>>>> I've worked in environments like that, and found it quite
>>>> workable.
>>> Now I know why so much C software is crash-prone and generally
>>> buggy.
Spot the (groundless) personal attack, to which I reacted...
>> Yes, it's at least partly because there are people who don't know
>> [rest of personal attacks deleted]
...and you didn't like it.
> Stop attacking me.
For someone who doesn't like personal attacks, you sure like making
them. There's no point giving me orders, by the way. You're not my
boss.
> You've said your piece and I've said mine. Move on.
I'm already in the right place. If you seek the truth, it is you who
need to move. And the truth is that, despite your incredulity,
sizeof does not evaluate its operand. I have already provided the
relevant evidence to back me up. You have provided none to back you
up. That is not a personal attack, you buffoon (that one was,
though) - it's just a statement of the facts.
Okay, so I'll retract "buffoon" - but for heaven's sake, lighten up
a little - and before "correcting" people, take the trouble to find
out whether your "correction" is correct.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
On 31 Mai, 20:17, Richard Heathfield <····@see.sig.invalid> wrote:
> ... there are still people who need to write portable C
> code, and it is well for them to write C properly and with an eye
> to portability.
Portability is exactly the reason I decided to use C to implement
Seed7. When I began to implement the predecessor of Seed7 I used
Pascal but I had much more portability problems with it.
When C compilers use high warning levels it is almost impossible to
write code that never (with no C compiler) gets a warning:
- On some compilers you get warnings complaining about things in
standard include files. How do you get rid of such warnings?
- Historically C had the philosophy that actual float parameters
are automatically converted to double when a function is called.
On some compilers you get warnings when your prototyp requests
a formal float parameter and the actual parameter is a float
also. So you get a warning for something that is 100% OK and
I don't want to cast every float argument to float just to
avoid this warning.
- On some compilers you get warnings when 'unsigned char *' strings
are used for functions like 'strlen' or 'strcpy' (which request
a signed 'char *' pointer). Naturally you can assume that
'strlen' works independent of the sign of the character, but the
compiler warnings do not care about that.
- C has rules how to deal with operations when integers of
different sizes or signedness are involved. One operator argument
is implicitly casted to the type of the other. Naturally such
casts can involve loss of data or loss of the sign. This warnings
are helpful to find possible sources of errors. But to silence
such warnings it is necessary to use explicit casts. The problem
is that with and without explicit casts the same things are done.
The cast just tells the compiler: I know what I mean, just do it.
This way you will not get warnings when new typedefs or other
declarations cause the expression to become dangerous.
- Warnings about 'variablename' may be used uninitialized:
This can be false complaints. Interestingly gcc is not able to
recognize when the states of two variables are connected.
Such as a global fail_flag variable and a local condition
variable (cond). The connection is: As long as fail_flag is
FALSE the cond variable is initialised. When the fail_flag
is TRUE the cond variable is not used and therefore it could
be in an uninitialized state. At several places I use such
connected variable states which are not recognized by the
gcc optimizer and are therefore flagged with a warning. I
accept such warnings in performance critical paths. I am not
willing to do "unnecessary" initialisations in performance
critical paths of the program. At places that are not
performance critical I do some of this "unnecessary"
initialisations just to avoid such warnings.
I appreciate every help to reduce the number of warnings when
compiling Seed7. It would be nice to recive the warnings generated
by various C compilers.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h00bdf$su9$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>
>> Richard Heathfield wrote:
>> [snip]
>>
>> Stop attacking me.
>
> I invite you to review the discussion once more, to find out who
> attacked whom.
It's quite fresh in my memory. I was ambling along, minding my own
business and then making a perfectly innocuous suggestion in a perfectly
civil post when you viciously assaulted me without provocation.
> I am less concerned with attacking you than with debunking
I do not need "debunking", thank you very much. Next time, do not
"debunk" unsolicited.
>>>>> Firstly, the preferred idiom is:
>>>>>
>>>>> struct tm *foo = calloc(sizeof *foo);
>>>> Surely not? That dereferences an uninitialized pointer, thereby
>>>> invoking undefined behavior.
>>> Surely not! The sizeof operator does not evaluate its operand
>> It must at least partly do so, in order to know what size of thing
>> *foo is referring to.
>
> It is *forbidden* to do so
Then how the heck is it supposed to know what size the thing is it's
pointing to?
Regardless, it's been drilled in repeatedly: if "*foo" is encountered
when foo is uninitialized, Bad Things may happen.
>>>>> Secondly, although all-bits-zero does indeed represent 0.0 or
>>>>> NULL on many platforms, it is not guaranteed by the C Standard
>>>>> so to do.
>>>> Have you ever seen a reasonably modern system where it wasn't?
>>> Have you ever seen a reasonably modern system that had precisely
>>> the same architecture in all respects as the most common
>>> architecture of the previous generation? There are real systems
>>> where NULL is not all-bits-zero
>> Yes, but are any of them in widespread use?
>
> You missed my point.
No, I did not. I repeat again: are any of them in widespread use?
>>> and real systems where 0.0 is not all-bits-zero.
>> Not IEEE754-compatible ones.
>
> You missed my point.
No, I did not. I repeat again: not IEEE754-compatible ones.
>>> In the absence of a guarantee from Silicon Valley that this will
>>> never, ever, ever happen again, I will continue to assume the
>>> worst when writing code that I need to be maximally portable.
>> And I will continue to use Java when writing code that I need to
>> be maximally portable. C is for systems-level stuff now. :-)
>
> Fine, you're entitled to think that
Don't patronize me. You appear to be somewhat of a jerk. Please go look
in a mirror and adjust that attitude you're wearing.
>>>> Then again, dereferencing a bad pointer without actually reading
>>>> or writing through it doesn't tend to cause h/w exceptions on
>>>> modern machines either.
>>> Strawman argument.
>> Do not personally attack me or accuse me of intellectually
>> dishonest behavior again. You have been warned.
>
> It wasn't a personal attack
Like hell it wasn't. You publicly berated me and implied in front of a
large audience that I was stupid and/or incompetent. What the hell is
the MATTER with you? And with several other people in these newsgroups?
> You are taking this far too personally.
That isn't for you to decide.
> This is a discussion, not a lawsuit.
It's not a polite discussion, and it hasn't been since you started
making things personal.
You made several nasty errors:
1. You nitpicked a post of mine. Bad move.
2. Then when I responded to smooth things over, you replied with
a more direct and serious attack instead of letting sleeping
dogs lie. Big mistake.
3. You continued to not back down when I continued to try to
reset things to the appropriate state so that the
discussion could move on in other directions.
Don't do that! If you nitpick at something someone said and they respond
in their own defense, leave it at that. You'll have said your opinion,
they'll have said theirs, and everyone can move on. If, instead, you
respond by restating your opinion more forcefully, it starts a fight
instead, and nobody benefits from that.
> I described your argument as a strawman argument because
you're an asshole. Yes, yes, I know.
> your flawed understanding
> led you to believe, mistakenly
Stop personally-attacking me at once. You will not again use the words
"flawed" or "mistaken" to describe me in public. Do I make myself clear?
Leave. Me. Alone.
These newsgroups are for discussing programming, not people. I am
off-topic here.
>>>>> I've worked in environments like that, and found it quite
>>>>> workable.
>>>> Now I know why so much C software is crash-prone and generally
>>>> buggy.
>
> Spot the (groundless) personal attack, to which I reacted.
There was no personal attack in my post. Saying that environments that
ignore a lot of compiler warnings generate buggy code is not an attack
on any particular person.
>>> Yes, it's at least partly because there are people who don't know
>>> [rest of personal attacks deleted]
>> Stop attacking me.
>
> For someone who doesn't like personal attacks, you sure like making
> them.
No, I do not. Stop publicly lying about me.
>> You've said your piece and I've said mine. Move on.
>
> I'm already in the right place.
NO. YOU ARE NOT.
You've said your piece. It does not bear repeating.
MOVE ON.
> If you seek the truth, it is you who need to move.
Calling me a liar will not make me friendlier.
> That is not a personal attack, you buffoon
Fuck you.
> Okay, so I'll retract "buffoon" - but for heaven's sake, lighten up
> a little
After you.
> and before "correcting" people, take the trouble
to send it as private email rather than a public news post? After you.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gKWdnfKdPPwCnLnXnZ2dnUVZ8gidnZ2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>
>>> Richard Heathfield wrote:
>>> [snip]
>>>
>>> Stop attacking me.
>>
>> I invite you to review the discussion once more, to find out who
>> attacked whom.
>
> It's quite fresh in my memory. I was ambling along, minding my own
> business and then making a perfectly innocuous suggestion in a
> perfectly civil post when you viciously assaulted me without
> provocation.
>
>> I am less concerned with attacking you than with debunking
>
> I do not need "debunking", thank you very much.
Right, but the claim you made was incorrect, and *did* need
debunking.
> Next time, do not "debunk" unsolicited.
If you don't wish for mistakes in your articles to be corrected, you
have two choices - (a) don't make mistakes, or (b) don't post them.
I make mistakes in my articles too - and they /do/ get corrected,
and I'm pleased by that, because it means I get to learn stuff,
which is good, right?
>
>>>>>> Firstly, the preferred idiom is:
>>>>>>
>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>> thereby invoking undefined behavior.
>>>> Surely not! The sizeof operator does not evaluate its operand
>>> It must at least partly do so, in order to know what size of
>>> thing *foo is referring to.
>>
>> It is *forbidden* to do so
>
> Then how the heck is it supposed to know what size the thing is
> it's pointing to?
I think you're confusing runtime with compile time. Pointer
dereferencing occurs at runtime. With one C99 exception that
doesn't apply here, all the information needed to calculate the
result of sizeof is available at compilation time. Thus, no matter
what object type p points to, the compiler is able to calculate
sizeof *p. Note: the *compiler*. So, by the time your executable
image is built, that size information is hard-coded into your
binary. It's as if the compiler replaced "sizeof *p" with "28" (or
whatever the exactly correct size is for the type) - so at runtime
it is (as if) a constant is passed to calloc. I say "as if" because
the Standard doesn't constrain implementations very much - it would
be quite legal, for example, for the compiler to insert an
inefficient call to a dopey size database thing. Daft, but legal.
But it is *not* legal for the *p of sizeof *p to be evaluated (i.e.
for its value to be calculated by the program). The dereference
*never happens*, because it's not allowed to happen.
> Regardless, it's been drilled in repeatedly: if "*foo" is
> encountered when foo is uninitialized, Bad Things may happen.
Sure - but this isn't *foo; it's sizeof *foo, which is a totally
different ball-game.
>
>>>>>> Secondly, although all-bits-zero does indeed represent 0.0 or
>>>>>> NULL on many platforms, it is not guaranteed by the C
>>>>>> Standard so to do.
>>>>> Have you ever seen a reasonably modern system where it wasn't?
>>>> Have you ever seen a reasonably modern system that had
>>>> precisely the same architecture in all respects as the most
>>>> common architecture of the previous generation? There are real
>>>> systems where NULL is not all-bits-zero
>>> Yes, but are any of them in widespread use?
>>
>> You missed my point.
>
> No, I did not. I repeat again: are any of them in widespread use?
Yes, you did. I repeat again - in the past, things often worked a
bit differently to the way they normally work now. Things changed,
so that they now work in what you probably think of as the only way
they're ever going to work. A more cautious attitude would be "if
they've changed before, they can change *again* - and if I program
according to the rules, I can to some extent protect my code
against such changes."
>
>>>> and real systems where 0.0 is not all-bits-zero.
>>> Not IEEE754-compatible ones.
>>
>> You missed my point.
>
> No, I did not. I repeat again: not IEEE754-compatible ones.
If you are prepared to limit yourself to systems that use
IEEE754-compatible floating point systems, that's your decision to
make.
>
>>>> In the absence of a guarantee from Silicon Valley that this
>>>> will never, ever, ever happen again, I will continue to assume
>>>> the worst when writing code that I need to be maximally
>>>> portable.
>>> And I will continue to use Java when writing code that I need to
>>> be maximally portable. C is for systems-level stuff now. :-)
>>
>> Fine, you're entitled to think that
>
> Don't patronize me.
Firstly, I told you before that giving me orders is a waste of time.
Secondly, I wasn't patronising you. You can try for patronising if
you like, but right now I'm still treating you like an intelligent
man who has simply got the wrong end of the stick, as we all do
from time to time. That opinion, however, is beginning to change.
> You appear to be somewhat of a jerk.
It's changing faster now.
> Please go
> look in a mirror and adjust that attitude you're wearing.
"Please" is a good start, but you have dug yourself a big hole, and
"please" is quite a short ladder.
>>>>> Then again, dereferencing a bad pointer without actually
>>>>> reading or writing through it doesn't tend to cause h/w
>>>>> exceptions on modern machines either.
>>>> Strawman argument.
>>> Do not personally attack me or accuse me of intellectually
>>> dishonest behavior again. You have been warned.
>>
>> It wasn't a personal attack
>
> Like hell it wasn't. You publicly berated me
Actually, I pointed out that you didn't understand sizeof. This
appears still to be the case, even though the nature of your
misunderstanding has been made crystal clear.
> and implied in front
> of a large audience that I was stupid and/or incompetent.
No, I think you're doing that yourself.
> What the hell is the MATTER with you?
Nothing, really. What is the matter with your ability to grasp the
semantics of sizeof?
> And with several other people in these newsgroups?
"It was a terrible parade. *Everybody* was out of step - except for
our Freddie, of course."
>> You are taking this far too personally.
>
> That isn't for you to decide.
True enough. I will rephrase. I *believe* you are taking this far
too personally. It appears I am not the only one to believe that.
>> This is a discussion, not a lawsuit.
>
> It's not a polite discussion, and it hasn't been since you started
> making things personal.
It could be polite. I am doing my best to remain polite, and I think
that mostly I'm succeeding.
> You made several nasty errors:
> 1. You nitpicked a post of mine. Bad move.
I corrected a mistake in your article. Good move, actually.
> 2. Then when I responded to smooth things over,
I don't recall your trying to smooth things over. Got a message ID
to support your claim?
> you replied with
> a more direct and serious attack instead of letting sleeping
> dogs lie. Big mistake.
Again, got a msg-ID? My own recollection is that you appeared to
continue to misunderstand sizeof.
> 3. You continued to not back down when I continued to try to
> reset things to the appropriate state so that the
> discussion could move on in other directions.
Why would I back down from a correct position?
> Don't do that!
You don't get to control my actions.
> If you nitpick at something someone said and they
> respond in their own defense, leave it at that.
You don't get to control my actions. If you screw up and I point it
out and you still deny it, it's my call whether I decide to point
out that you're still wrong.
> You'll have said
> your opinion, they'll have said theirs, and everyone can move on.
You can move on any time you like. Nobody forces you to respond.
> If, instead, you respond by restating your opinion more
> forcefully, it starts a fight instead, and nobody benefits from
> that.
If someone (anyone, not just you) disagrees with a point I've made
in an article, either they are right (in which case I'm wrong and
I'd like to know about it), or they are not right (in which case it
may be worth trying to put things in a way that is easier to
grasp), or perhaps we are both right ("violently agreeing with each
other") in which case it will usually come out in the wash, or
we're both wrong, in which case someone will probably point out why
in compelling terms. In this case, you were wrong, and I knew it
and could prove it (and *did* prove it), but you didn't seem to see
why you were wrong, so I tried to make the point clearer. It seems
I have even now not made it clear enough (although the middle part
of this reply is another attempt).
>> I described your argument as a strawman argument because
>
> you're an asshole. Yes, yes, I know.
Selective quotation is a poor debating trick, and loses all force
when pointed out.
>> your flawed understanding
>> led you to believe, mistakenly
>
> Stop personally-attacking me at once.
Firstly, I'm not personally attacking you. I am having a discussion
on Usenet. Secondly, I am sure you would agree that you are wholly
entitled to make your own choice about whether to take part in, or
to withdraw from, this discussion. That is *your* choice. I, too,
am entitled to take part, or to withdraw, and that is *my* choice,
not yours.
> You will not again use the
> words "flawed" or "mistaken" to describe me in public. Do I make
> myself clear?
You make yourself perfectly clear, but your understanding of sizeof
*is* flawed, and you *are* mistaken, whether or not you realise it,
and attempting to censor the discussion will not change that. Nor
will such an attempt succeed. You don't get to decide what I write.
> Leave. Me. Alone.
If you don't wish to communicate with me, you can stop doing so at
any time.
> These newsgroups are for discussing programming, not people. I am
> off-topic here.
I agree (and I have made the same point myself in the past, on this
group [comp.programming]) - but a correct understanding of sizeof
*is* topical, and that's what I'm discussing. All this extraneous
guff is just a side issue.
>
>>>>>> I've worked in environments like that, and found it quite
>>>>>> workable.
>>>>> Now I know why so much C software is crash-prone and generally
>>>>> buggy.
>>
>> Spot the (groundless) personal attack, to which I reacted.
>
> There was no personal attack in my post.
That's called "special pleading". You are claiming that your
personal attacks are merely technical observations, whereas my
merely technical observations are personal attacks. It won't wash.
> Saying that environments
> that ignore a lot of compiler warnings generate buggy code is not
> an attack on any particular person.
Who said anything about ignoring compiler warnings? That is a
complete misunderstanding of the environment in question. The
system works like this:
(a) it's impossible to satisfy every compiler, and code that is
required for eliminating a warning on one compiler may itself cause
a warning on another; therefore, a clean build is not actually
possible in the general case for non-trivial code that must build
on multiple compilers;
(b) rather than strive for the impossible, build the code and look
at the first lot of warnings; resolve the ones that need resolving,
which leaves you with the warnings about code that you know is
correct because you have NOT ignored the warning but used it to
check the code and satisfied yourself that the code is correct;
(c) add the warning to a database of such warnings;
(d) use the database to filter out such warnings on subsequent
compilations.
It's a perfectly reasonable system. It's open to abuse, of course,
by people who add new warnings to the database when what they
should be doing is fixing the code, so the database needs to be
version-controlled and all changes should be peer-reviewed.
>>>> Yes, it's at least partly because there are people who don't
>>>> know
>>>> [rest of personal attacks deleted]
>>> Stop attacking me.
>>
>> For someone who doesn't like personal attacks, you sure like
>> making them.
>
> No, I do not. Stop publicly lying about me.
Well, it wasn't a lie, but it's possible that I was mistaken to
claim that you enjoyed making personal attacks. Nevertheless, you
have clearly made them.
>>> You've said your piece and I've said mine. Move on.
>>
>> I'm already in the right place.
>
> NO. YOU ARE NOT.
I respectfully disagree.
> You've said your piece. It does not bear repeating.
Am I right to interpret this as "Seamus is not interested in
learning the proper semantics of sizeof"?
> MOVE ON.
I'm already in the right place. I /do/ understand the semantics of
sizeof.
>> If you seek the truth, it is you who need to move.
>
> Calling me a liar will not make me friendlier.
I don't believe I've called you a liar. I do believe you do not
understand the truth about sizeof, and this belief is based on what
you have written about it in this thread.
>> That is not a personal attack, you buffoon
>
> Fuck you.
Irony is always dangerous.
>> Okay, so I'll retract "buffoon" - but for heaven's sake, lighten
>> up a little
>
> After you.
I'm not the one who introduced expletives into the discussion. Nor
will I sink to your level by using them myself.
>
>> and before "correcting" people, take the trouble
>
> to send it as private email rather than a public news post? After
> you.
It's more cost-effective to explain the semantics of sizeof in a
public article than to send emails to every single subscriber.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h044f6$p58$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> I am less concerned with attacking you than with debunking
>> I do not need "debunking", thank you very much.
>
> Right
Then please drop this.
NOW!!!
>> Next time, do not "debunk" unsolicited.
>
> If you don't wish for mistakes in your articles to be corrected, you
> have two choices - (a) don't make mistakes, or (b) don't post them.
I go for option (a), always.
> I make mistakes in my articles - and they /do/ get corrected,
> and I'm pleased by that, because it means I get to learn stuff,
> which is good, right?
Are you unconcerned with how you are perceived? I'd think you'd rather
not be publicly humiliated and made to look like an idiot. If that's not
the case, though, it might explain your boorish behavior here, where you
seem unconcerned for the risk that your actions will have that sort of
effect on someone else. If, for some strange reason, you wouldn't mind
it yourself, then perhaps it just didn't occur to you that someone else
*would* mind.
Well, now that you're aware of the possibility, you should know to just
quietly move on now.
>>>>>>> Firstly, the preferred idiom is:
>>>>>>>
>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>> thereby invoking undefined behavior.
>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>> It must at least partly do so, in order to know what size of
>>>> thing *foo is referring to.
>>> It is *forbidden* to do so
>> Then how the heck is it supposed to know what size the thing is
>> it's pointing to?
>
> I think you're confusing
I am not.
I am also not interested in entertaining any more public speculation
about my mental functioning.
Drop it.
Now.
>> Regardless, it's been drilled in repeatedly: if "*foo" is
>> encountered when foo is uninitialized, Bad Things may happen.
>
> Sure - but this isn't *foo; it's sizeof *foo
Which contains *foo as an argument, for heaven's sake.
>>>>>>> Secondly, although all-bits-zero does indeed represent 0.0 or
>>>>>>> NULL on many platforms, it is not guaranteed by the C
>>>>>>> Standard so to do.
>>>>>> Have you ever seen a reasonably modern system where it wasn't?
>>>>> Have you ever seen a reasonably modern system that had
>>>>> precisely the same architecture in all respects as the most
>>>>> common architecture of the previous generation? There are real
>>>>> systems where NULL is not all-bits-zero
>>>> Yes, but are any of them in widespread use?
>>> You missed my point.
>> No, I did not.
>
> Yes
No, and this is not negotiable. I do not miss points. Now move along.
>>>>> and real systems where 0.0 is not all-bits-zero.
>>>> Not IEEE754-compatible ones.
>>> You missed my point.
>> No, I did not. I repeat again: not IEEE754-compatible ones.
>
> If you are prepared to limit yourself to systems that use
> IEEE754-compatible floating point systems, that's your decision to
> make.
Since that's the vast majority of systems in present-day use, it doesn't
seem to be a biggie.
>>>>> In the absence of a guarantee from Silicon Valley that this
>>>>> will never, ever, ever happen again, I will continue to assume
>>>>> the worst when writing code that I need to be maximally
>>>>> portable.
>>>> And I will continue to use Java when writing code that I need to
>>>> be maximally portable. C is for systems-level stuff now. :-)
>>> Fine, you're entitled to think that
>> Don't patronize me.
>
> Firstly, I told you before
I said, don't patronize me. And what's the next thing you do? Patronize me!
Fuck off. You are clearly a complete waste of bandwidth and congenitally
incapable of remaining polite or civil.
> I'm still treating you like an intelligent man
Ordinarily, one does not treat intelligent men as shoddily as you've
treated me. In particular, when an intelligent man requests that you
drop a condescending tone, or drop an entire line of questioning, then
unless you are a police interrogator and he is a murder suspect, you do
so! Any other behavior is extremely impolite.
> That opinion, however, is beginning to change.
Is that a threat?
Actually, I frankly don't care about your opinion of me, just so long as
you don't broadcast it loudly but keep it to yourself as a polite person
would.
If you have a negative opinion of me, please keep it to yourself and
ignore me. If you have a positive opinion of me, then feel free to not
insult me in public.
>> Please go look in a mirror and adjust that attitude you're wearing.
>
> "Please" is a good start [rest of patronizing crap deleted]
Either discuss the original subject matter or remain silent please.
>>>> Do not personally attack me or accuse me of intellectually
>>>> dishonest behavior again. You have been warned.
>>> It wasn't a personal attack
>> Like hell it wasn't. You publicly berated me
>
> Actually, I
Actually, I'm not interested in your explanations or excuses. I'm
interested in two things:
1. Shutting down this unwelcome and off-topic inquiry into the status
of my mental functioning, and
2. Getting an apology, if one might be forthcoming, though I will
settle for complete silence instead.
> the nature of your misunderstanding has been made crystal clear.
Shall I repeat what I just said? About the unwelcome nature of any
further public inquiry into my mental functioning?
I understand perfectly. I do not, however, agree with your stated
opinions of me, and I will not ever agree with them.
You cannot gain anything by continuing this. If you drop the subject
now, we both walk away and get on with our lives. If you continue to
publicly insinuate various unpleasant things about my mental
functioning, you will be in for a world of shit. You'll get at least as
good as you give and will likely lose your usenet access in the bargain.
It's your choice.
>> and implied in front of a large audience that I was stupid and/or
>> incompetent.
>
> No
Yes. Publicly insulting me was bad enough. Now you have the gall to lie
about it?
>> What the hell is the MATTER with you?
>
> Nothing, really. What is the matter with you
Nothing. And that is final.
I am not interested in discussing or negotiating or anything like that.
My stance regarding my own mental functioning is firm, and you will not
budge it. You will only let yourself in for a nasty and pointless
flamewar if you insist on continuing to poke into a subject matter where
you have been warned repeatedly now that you're not welcome.
>> And with several other people in these newsgroups?
>
> "It was a terrible parade. [rest deleted]
Parades are not on topic here.
>>> You are taking this far too personally.
>> That isn't for you to decide.
>
> True enough. I will rephrase. I *believe* you are taking this far
> too personally.
Irrelevant. If I say I don't welcome a continued discussion of me in
public, then the subject is closed, whether or not you would mind if our
positions were reversed.
When it's your mental competence that's being discussed in public, then
it's your turn to decide the same things.
Fair's fair.
>>> This is a discussion, not a lawsuit.
>> It's not a polite discussion, and it hasn't been since you started
>> making things personal.
>
> It could be polite. I am doing my best to remain polite, and I think
> that mostly I'm succeeding.
You're not succeeding.
To remain fully polite, you will need to avoid mentioning or implying
anything at all negative about me. This could be accomplished by
remaining silent, by being full of praise for me, or by discussing
something other than me and avoiding saying or implying anything about
me while doing so.
>> You made several nasty errors:
>> 1. You nitpicked a post of mine. Bad move.
>
> I corrected
You nitpicked where no nitpicking was welcome. Don't do it again.
>> 2. Then when I responded to smooth things over,
>
> I don't recall your trying to smooth things over.
Yes. In <································@bt.com> you nitpicked me,
apparently unaware that the correct response to my post was to either
leave it alone or agree.
In <············@news.eternal-september.org> I responded in such a way
that you could have just left that post to stand unmolested and
everything would have been fine. Instead, you attacked and here we are now.
Given that you had several opportunities to leave me alone and chose
instead to blast me with increasingly-stronger shots each time, I have
to conclude that you want a fight.
Now I am warning you that a fight with me will end very badly for you.
>> you replied with
>> a more direct and serious attack instead of letting sleeping
>> dogs lie. Big mistake.
>
> Again, got a msg-ID?
Yes: <································@bt.com>
This you should definitely never have posted.
> My own recollection is that you appeared to continue to
> misunderstand
I HAVE NO INTEREST IN CONTINUING TO DISCUSS YOUR OPINION OF MY MENTAL
FUNCTIONING. HAVE I MADE MYSELF CLEAR?
Why are you so unwilling to respect multiple boundaries?
1. The topic bounds. These newsgroups are for discussing programming,
not people.
2. The personal boundaries around one another. You do not publicly
speculate about another person's mental functioning without
permission! Jeezus.
3. The relevance bounds. The arguments about Lisp vs. Java,
emacs vs. Eclipse, and Seed7 warnings, and the original
job-search topics, all have relevance bounds. My mental
functioning is irrelevant to all of those topics. The only
person whose mental functioning might be relevant to any of them
is Robert Maas, the original job-seeker.
>> 3. You continued to not back down when I continued to try to
>> reset things to the appropriate state so that the
>> discussion could move on in other directions.
>
> Why would I back down from a correct position?
I refer to your arguments about my mental functioning. You hold certain
*opinions* there. They are not "correct" in my opinion, and they are not
matters of fact regardless. Those opinions are what you should back down
from. Instead you seem determined both to air them far and wide and to
defend them aggressively.
This might be okay if those opinions were on a neutral subject matter,
say, abortion or gun control. But those opinions are about a particular
other person, which means that he ought to have at least some say in
whether and how you blather about him in public.
And I say you are to stop discussing me in public altogether. Killfile
me if you must, but henceforth, please pretend that I do not exist. That
means if you see a post by me, it does not exist so you will not post a
followup. If you hold an opinion about me, it does not exist so you will
not post mentioning it or implying it.
I hope I've made myself clear enough this time.
>> Don't do that!
>
> You don't get to control my actions.
Ordinarily, no, but when your actions include making public statements
about me, my rights of privacy and publicity enter into it, and I say I
don't want you discussing me in public.
Really, I am none of your business anyway so you have no good reason to
be doing so; and I am off-topic in all three of these newsgroups so you
certainly have some very good reasons not to be doing so in this thread,
regardless.
>> If you nitpick at something someone said and they
>> respond in their own defense, leave it at that.
>
> You don't get to control my actions.
You're missing the point. I am attempting to explain rules of polite
society to you that apparently you don't get. You don't keep pressing
someone that clearly doesn't want a fight. You leave them alone.
> If you screw up
That never happens.
If it ever did, then you should certainly not keep aggressively poking
at someone who is trying to save face. That's how big, nasty fights
start, when someone disrespects someone else's right to be left alone.
>> You'll have said
>> your opinion, they'll have said theirs, and everyone can move on.
>
> You can move on any time you like. Nobody forces you to respond.
Oh, is that what this is about? You keep posting because you have a
childish insistence on having the last word? How disappointing.
>> If, instead, you respond by restating your opinion more
>> forcefully, it starts a fight instead, and nobody benefits from
>> that.
>
> If someone (anyone, not just you) disagrees with a point I've made
> in an article, either they are right (in which case I'm wrong and
> I'd like to know about it), or they are not right (in which case it
> may be worth trying to put things in a way that is easier to
> grasp)
Insulting. I think you should be thinking "worth trying to put things in
a way that preserves both sides' dignity", don't you? Or does the
dignity of other people not concern you?
I'm getting a very disturbing picture here: that you are not willing to
agree to disagree on any subject, nor do you care about preserving the
dignity of others.
> In this case, you [insult deleted]
I repeat: I am not interested in your opinion of me. Neither is anyone
else. Don't. Post it. Again.
> you didn't seem to see why
I see exactly why you hold your opinion of me. I also don't give a shit.
My concern is with your *posting that opinion in public*, and posting
things apparently designed to induce *other people to develop the same,
negative opinion*. You can surely understand why I don't want that
happening, particularly the latter part.
What I don't understand is why you seem to be insistent that that
happen, and that I not be permitted to speak up in my own defense?
Really, I just want to be left alone.
If, after this post, you continue to harass me, I will have to conclude
that your purpose is in fact to start a fight. There is no other
explanation for someone posting an attack post in response to "I just
want to be left alone", after all.
> I have even now not made it clear enough (although the middle part
> of this reply is another attempt).
Your opinion is crystal clear. I hope by now so is mine: I do not want
you to make yours even clearer. I want you to drop the subject and leave
me in peace.
>>> I described your argument as a strawman argument because
>> you're an asshole. Yes, yes, I know.
>
> Selective quotation
Please do not change the subject.
>>> your flawed understanding
>>> led you to believe, mistakenly
>> Stop personally-attacking me at once.
>
> Firstly, I'm not personally attacking you.
Yes, you are. You are publicly calling my intelligence into question.
That is an insult. It's the same as if you posted "Seamus MacRae is an
idiot" on the billboard at Times Square.
How would you like it if someone put "Richard Heathfield is an idiot" on
there?
I'm guessing you wouldn't.
Please let this entire matter just drop, for both of our sakes.
> I am having a discussion on Usenet.
You are discussing a person in public without that person's consent.
That is a no-no.
> Secondly, I am sure you would agree that you are wholly
> entitled to make your own choice about whether to take part in, or
> to withdraw from, this discussion.
Then I choose to withdraw from it, by which is meant my name will not
appear any further in it, which in turn means you do not talk about me
and you do not follow up to one of my posts.
Is that clear?
Otherwise, I am "taking part" by being mentioned or quoted in it,
against my will and in violation of that very entitlement that you just
admitted I possess.
>> You will not again use the
>> words "flawed" or "mistaken" to describe me in public. Do I make
>> myself clear?
>
> You make yourself perfectly clear, but [insults deleted]
> You don't get to decide what I write.
Fuck you.
Obviously, you understand me perfectly and are explicitly refusing to
leave me alone.
Fine. If you want a fight, let's fight.
Your mother is so fat, she is required by law to wear a "wide load" sign
and beep when she backs up.
Your turn.
>> Leave. Me. Alone.
>
> If you don't wish to communicate with me, you can stop doing so at
> any time.
I don't wish to be communicated ABOUT in public by you.
>> These newsgroups are for discussing programming, not people. I am
>> off-topic here.
>
> I agree
Then stop talking about me!
> sizeof *is* topical, and that's what I'm discussing.
Get real. This stopped being about "sizeof" several posts ago when you
decided to make things personal.
> All this extraneous guff is just a side issue.
All this "extraneous guff" is what actually matters to me. If you
consider it a mere "side issue" then that's another reason for you to
drop this thread and move on -- topic drift has taken it outside of your
area of interest.
>>>>>>> I've worked in environments like that, and found it quite
>>>>>>> workable.
>>>>>> Now I know why so much C software is crash-prone and generally
>>>>>> buggy.
>>> Spot the (groundless) personal attack, to which I reacted.
>> There was no personal attack in my post.
>
> That's called "special pleading".
No, it's called pointing out that insulting software is not insulting a
human being, and therefore is not a personal attack. For it to have been
a *personal* attack it would have had to imply something negative about
some specific *person*.
>> Saying that environments
>> that ignore a lot of compiler warnings generate buggy code is not
>> an attack on any particular person.
>
> Who said anything about ignoring compiler warnings?
You did. That's what "environments like that" was in reference to,
remember? Workplaces that actually do diffs on the compiler warnings and
only pay attention to new ones, thus ignoring lots of other warnings,
rather than attempting to get a clean build.
> That is a complete misunderstanding
And there you go again, making things personal and publicly accusing me
of idiocy!
Fuck you.
I've had it with you. You pretend to some kind of civilized character
but your real objective is simply to go around badmouthing anyone you
disagree with, have the last word in any discussion, and generally shove
your weight around. How old are you, about three?
> (a) it's impossible to satisfy every compiler, and code that is
> required for eliminating a warning on one compiler may itself cause
> a warning on another; therefore, a clean build is not actually
> possible in the general case for non-trivial code that must build
> on multiple compilers;
Doesn't follow. Ever heard of #ifdef and its friends? Conditional
compilation means being able to satisfy multiple compilers, and produce
more portable code.
>>>>> Yes, it's at least partly because there are people who don't
>>>>> know
>>>>> [rest of personal attacks deleted]
>>>> Stop attacking me.
>>> For someone who doesn't like personal attacks, you sure like
>>> making them.
>> No, I do not. Stop publicly lying about me.
>
> Well, it wasn't a lie, but it's possible that I was mistaken to
> claim that you enjoyed making personal attacks.
That you were.
> Nevertheless, you have clearly made them.
I have *now*, when you continued to publicly badmouth me. You asked for
it, you got it. Now, are you ready to quit, or are you thirsty for more?
>>>> You've said your piece and I've said mine. Move on.
>>> I'm already in the right place.
>> NO. YOU ARE NOT.
>
> I respectfully disagree.
Respect? That's a joke. You've shown no respect for my wishes, for my
boundaries, or for any of the three newsgroups' topic boundaries, at
least thus far.
>> You've said your piece. It does not bear repeating.
>
> Am I right to interpret this as "Seamus is not interested in
You are right to interpret this as "Seamus is not interested in
continuing this discussion, or in being the subject of any discussion in
which you participate".
>> MOVE ON.
>
> I'm already in the right place.
No. See above.
>> Calling me a liar will not make me friendlier.
>
> I don't believe I've called you a liar.
Implied it, at any rate.
> I do believe you do not understand the truth [snip]
Your opinion has been noted and logged. Now here's a quarter. (%)
Go call someone who gives a damn.
> this belief is based on what you have written
I don't care what your beliefs are based on, because I don't care about
your beliefs, except insofar as your publicly broadcasting them might
help or harm me.
>>> That is not a personal attack, you buffoon
>> Fuck you.
>
> Irony is always dangerous.
So is a complaint to your internet provider for flooding three
newsgroups with offtopic drivel.
>>> Okay, so I'll retract "buffoon" - but for heaven's sake, lighten
>>> up a little
>> After you.
>
> I'm not the one who introduced expletives into the discussion.
You are, however, the one who introduced rudeness, personal innuendos,
and an unwillingness to leave things alone.
> Nor will I sink to your level
My God, are you really trying to claim the moral high ground now? How
utterly ridiculous. It's never available at any price to the guy that
shot first, so you can give up on that idea right quick.
>>> and before "correcting" people, take the trouble
>> to send it as private email rather than a public news post? After
>> you.
>
> It's more cost-effective to xxx in a public article than to send
> emails to every single subscriber.
I was, of course, suggesting that you send your insults *privately*, to
me only, instead of airing them in public *at all*, but apparently you
have once again missed the point. Probably, this time, deliberately.
Your implied threat of emailing a large number of random people with
letters badmouthing me by name is, of course, a very bad idea. If you
actually do that you will lose your internet account so fast your head
will spin. Unsolicited bulk mail is frowned upon by most service
providers nowadays, and at the first sign that you did anything like
that I'd report you as a spammer.
Anyway, I guess it's now your move. Will you decide to leave things be,
and consider this match a draw, or are you determined to win (or maybe
just to get the last word) even though you risk losing by pressing
things? We shall see.
Your ISP has been notified of your mental disturbance. Now stop the
personal attacks Seamus!, and admit that Common Lisp is better than
Java. You've been warned! Don't allow your mental malfunctions to
further hurt you.
On Jun 2, 4:09 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
> Richard Heathfield wrote:
> > Seamus MacRae said:
> >> Richard Heathfield wrote:
> >>> I am less concerned with attacking you than with debunking
> >> I do not need "debunking", thank you very much.
>
> > Right
>
> Then please drop this.
>
> NOW!!!
>
> >> Next time, do not "debunk" unsolicited.
>
> > If you don't wish for mistakes in your articles to be corrected, you
> > have two choices - (a) don't make mistakes, or (b) don't post them.
>
> I go for option (a), always.
>
> > I make mistakes in my articles - and they /do/ get corrected,
> > and I'm pleased by that, because it means I get to learn stuff,
> > which is good, right?
>
> Are you unconcerned with how you are perceived? I'd think you'd rather
> not be publicly humiliated and made to look like an idiot. If that's not
> the case, though, it might explain your boorish behavior here, where you
> seem unconcerned for the risk that your actions will have that sort of
> effect on someone else. If, for some strange reason, you wouldn't mind
> it yourself, then perhaps it just didn't occur to you that someone else
> *would* mind.
>
> Well, now that you're aware of the possibility, you should know to just
> quietly move on now.
>
> >>>>>>> Firstly, the preferred idiom is:
>
> >>>>>>> struct tm *foo = calloc(sizeof *foo);
> >>>>>> Surely not? That dereferences an uninitialized pointer,
> >>>>>> thereby invoking undefined behavior.
> >>>>> Surely not! The sizeof operator does not evaluate its operand
> >>>> It must at least partly do so, in order to know what size of
> >>>> thing *foo is referring to.
> >>> It is *forbidden* to do so
> >> Then how the heck is it supposed to know what size the thing is
> >> it's pointing to?
>
> > I think you're confusing
>
> I am not.
>
> I am also not interested in entertaining any more public speculation
> about my mental functioning.
>
> Drop it.
>
> Now.
>
> >> Regardless, it's been drilled in repeatedly: if "*foo" is
> >> encountered when foo is uninitialized, Bad Things may happen.
>
> > Sure - but this isn't *foo; it's sizeof *foo
>
> Which contains *foo as an argument, for heaven's sake.
>
> >>>>>>> Secondly, although all-bits-zero does indeed represent 0.0 or
> >>>>>>> NULL on many platforms, it is not guaranteed by the C
> >>>>>>> Standard so to do.
> >>>>>> Have you ever seen a reasonably modern system where it wasn't?
> >>>>> Have you ever seen a reasonably modern system that had
> >>>>> precisely the same architecture in all respects as the most
> >>>>> common architecture of the previous generation? There are real
> >>>>> systems where NULL is not all-bits-zero
> >>>> Yes, but are any of them in widespread use?
> >>> You missed my point.
> >> No, I did not.
>
> > Yes
>
> No, and this is not negotiable. I do not miss points. Now move along.
>
> >>>>> and real systems where 0.0 is not all-bits-zero.
> >>>> Not IEEE754-compatible ones.
> >>> You missed my point.
> >> No, I did not. I repeat again: not IEEE754-compatible ones.
>
> > If you are prepared to limit yourself to systems that use
> > IEEE754-compatible floating point systems, that's your decision to
> > make.
>
> Since that's the vast majority of systems in present-day use, it doesn't
> seem to be a biggie.
>
> >>>>> In the absence of a guarantee from Silicon Valley that this
> >>>>> will never, ever, ever happen again, I will continue to assume
> >>>>> the worst when writing code that I need to be maximally
> >>>>> portable.
> >>>> And I will continue to use Java when writing code that I need to
> >>>> be maximally portable. C is for systems-level stuff now. :-)
> >>> Fine, you're entitled to think that
> >> Don't patronize me.
>
> > Firstly, I told you before
>
> I said, don't patronize me. And what's the next thing you do? Patronize me!
>
> Fuck off. You are clearly a complete waste of bandwidth and congenitally
> incapable of remaining polite or civil.
>
> > I'm still treating you like an intelligent man
>
> Ordinarily, one does not treat intelligent men as shoddily as you've
> treated me. In particular, when an intelligent man requests that you
> drop a condescending tone, or drop an entire line of questioning, then
> unless you are a police interrogator and he is a murder suspect, you do
> so! Any other behavior is extremely impolite.
>
> > That opinion, however, is beginning to change.
>
> Is that a threat?
>
> Actually, I frankly don't care about your opinion of me, just so long as
> you don't broadcast it loudly but keep it to yourself as a polite person
> would.
>
> If you have a negative opinion of me, please keep it to yourself and
> ignore me. If you have a positive opinion of me, then feel free to not
> insult me in public.
>
> >> Please go look in a mirror and adjust that attitude you're wearing.
>
> > "Please" is a good start [rest of patronizing crap deleted]
>
> Either discuss the original subject matter or remain silent please.
>
> >>>> Do not personally attack me or accuse me of intellectually
> >>>> dishonest behavior again. You have been warned.
> >>> It wasn't a personal attack
> >> Like hell it wasn't. You publicly berated me
>
> > Actually, I
>
> Actually, I'm not interested in your explanations or excuses. I'm
> interested in two things:
>
> 1. Shutting down this unwelcome and off-topic inquiry into the status
> of my mental functioning, and
> 2. Getting an apology, if one might be forthcoming, though I will
> settle for complete silence instead.
>
> > the nature of your misunderstanding has been made crystal clear.
>
> Shall I repeat what I just said? About the unwelcome nature of any
> further public inquiry into my mental functioning?
>
> I understand perfectly. I do not, however, agree with your stated
> opinions of me, and I will not ever agree with them.
>
> You cannot gain anything by continuing this. If you drop the subject
> now, we both walk away and get on with our lives. If you continue to
> publicly insinuate various unpleasant things about my mental
> functioning, you will be in for a world of shit. You'll get at least as
> good as you give and will likely lose your usenet access in the bargain.
>
> It's your choice.
>
> >> and implied in front of a large audience that I was stupid and/or
> >> incompetent.
>
> > No
>
> Yes. Publicly insulting me was bad enough. Now you have the gall to lie
> about it?
>
> >> What the hell is the MATTER with you?
>
> > Nothing, really. What is the matter with you
>
> Nothing. And that is final.
>
> I am not interested in discussing or negotiating or anything like that.
> My stance regarding my own mental functioning is firm, and you will not
> budge it. You will only let yourself in for a nasty and pointless
> flamewar if you insist on continuing to poke into a subject matter where
> you have been warned repeatedly now that you're not welcome.
>
> >> And with several other people in these newsgroups?
>
> > "It was a terrible parade. [rest deleted]
>
> Parades are not on topic here.
>
> >>> You are taking this far too personally.
> >> That isn't for you to decide.
>
> > True enough. I will rephrase. I *believe* you are taking this far
> > too personally.
>
> Irrelevant. If I say I don't welcome a continued discussion of me in
> public, then the subject is closed, whether or not you would mind if our
> positions were reversed.
>
> When it's your mental competence that's being discussed in public, then
> it's your turn to decide the same things.
>
> Fair's fair.
>
> >>> This is a discussion, not a lawsuit.
> >> It's not a polite discussion, and it hasn't been since you started
> >> making things personal.
>
> > It could be polite. I am doing my best to remain polite, and I think
> > that mostly I'm succeeding.
>
> You're not succeeding.
>
> To remain fully polite, you will need to avoid mentioning or implying
> anything at all negative about me. This could be accomplished by
> remaining silent, by being full of praise for me, or by discussing
> something other than me and avoiding saying or implying anything about
> me while doing so.
>
> >> You made several nasty errors:
> >> 1. You nitpicked a post of mine. Bad move.
>
> > I corrected
>
> You nitpicked where no nitpicking was welcome. Don't do it again.
>
> >> 2. Then when I responded to smooth things over,
>
> > I don't recall your trying to smooth things over.
>
> Yes. In <································@bt.com> you nitpicked me,
> apparently unaware that the correct response to my post was to either
> leave it alone or agree.
>
> In <············@news.eternal-september.org> I responded in such a way
> that you could have just left that post to stand unmolested and
> everything would have been fine. Instead, you attacked and here we are now.
>
> Given that you had several opportunities to leave me alone and chose
> instead to blast me with increasingly-stronger shots each time, I have
> to conclude that you want a fight.
>
> Now I am warning you that a fight with me will end very badly for you.
>
> >> you replied with
> >> a more direct and serious attack instead of letting sleeping
> >> dogs lie. Big mistake.
>
> > Again, got a msg-ID?
>
> Yes: <································@bt.com>
>
> This you should definitely never have posted.
>
> > My own recollection is that you appeared to continue to
> > misunderstand
>
> I HAVE NO INTEREST IN CONTINUING TO DISCUSS YOUR OPINION OF MY MENTAL
> FUNCTIONING. HAVE I MADE MYSELF CLEAR?
>
> Why are you so unwilling to respect multiple boundaries?
>
> 1. The topic bounds. These newsgroups are for discussing programming,
> not people.
> 2. The personal boundaries around one another. You do not publicly
> speculate about another person's mental functioning without
> permission! Jeezus.
> 3. The relevance bounds. The arguments about Lisp vs. Java,
> emacs vs. Eclipse, and Seed7 warnings, and the original
> job-search topics, all have relevance bounds. My mental
> functioning is irrelevant to all of those topics. The only
> person whose mental functioning might be relevant to any of them
> is Robert Maas, the original job-seeker.
>
> >> 3. You continued to not back down when I continued to try to
> >> reset things to the appropriate state so that the
> >> discussion could move on in other directions.
>
> > Why would I back down from a correct position?
>
> I refer to your arguments about my mental functioning. You hold certain
> *opinions* there. They are not "correct" in my opinion, and they are not
> matters of fact regardless. Those opinions are what you should back down
> from. Instead you seem determined both to air them far and wide and to
> defend them aggressively.
>
> This might be okay if those opinions were on a neutral subject matter,
> say, abortion or gun control. But those opinions are about a particular
> other person, which means that he ought to have at least some say in
> whether and how you blather about him in public.
>
> And I say you are to stop discussing me in public altogether. Killfile
> me if you must, but henceforth, please pretend that I do not exist. That
> means if you see a post by me, it does not exist so you will not post a
> followup. If you hold an opinion about me, it does not exist so you will
> not post mentioning it or implying it.
>
> I hope I've made myself clear enough this time.
>
> >> Don't do that!
>
> > You don't get to control my actions.
>
> Ordinarily, no, but when your actions include making public statements
> about me, my rights of privacy and publicity enter into it, and I say I
> don't want you discussing me in public.
>
> Really, I am none of your business anyway so you have no good reason to
> be doing so; and I am off-topic in all three of these newsgroups so you
> certainly have some very good reasons not to be doing so in this thread,
> regardless.
>
> >> If you nitpick at something someone said and they
> >> respond in their own defense, leave it at that.
>
> > You don't get to control my actions.
>
> You're missing the point. I am attempting to explain rules of polite
> society to you that apparently you don't get. You don't keep pressing
> someone that clearly doesn't want a fight. You leave them alone.
>
> > If you screw up
>
> That never happens.
>
> If it ever did, then you should certainly not keep aggressively poking
> at someone who is trying to save face. That's how big, nasty fights
> start, when someone disrespects someone else's right to be left alone.
>
> >> You'll have said
> >> your opinion, they'll have said theirs, and everyone can move on.
>
> > You can move on any time you like. Nobody forces you to respond.
>
> Oh, is that what this is about? You keep posting because you have a
> childish insistence on having the last word? How disappointing.
>
> >> If, instead, you respond by restating your opinion more
> >> forcefully, it starts a fight instead, and nobody benefits from
> >> that.
>
> > If someone (anyone, not just you) disagrees with a point I've made
> > in an article, either they are right (in which case I'm wrong and
> > I'd like to know about it), or they are not right (in which case it
> > may be worth trying to put things in a way that is easier to
> > grasp)
>
> Insulting. I think you should be thinking "worth trying to put things in
> a way that preserves both sides' dignity", don't you? Or does the
> dignity of other people not concern you?
>
> I'm getting a very disturbing picture here: that you are not willing to
> agree to disagree on any subject, nor do you care about preserving the
> dignity of others.
>
> > In this case, you [insult deleted]
>
> I repeat: I am not interested in your opinion of me. Neither is anyone
> else. Don't. Post it. Again.
>
> > you didn't seem to see why
>
> I see exactly why you hold your opinion of me. I also don't give a shit.
> My concern is with your *posting that opinion in public*, and posting
> things apparently designed to induce *other people to develop the same,
> negative opinion*. You can surely understand why I don't want that
> happening, particularly the latter part.
>
> What I don't understand is why you seem to be insistent that that
> happen, and that I not be permitted to speak up in my own defense?
>
> Really, I just want to be left alone.
>
> If, after this post, you continue to harass me, I will have to conclude
> that your purpose is in fact to start a fight. There is no other
> explanation for someone posting an attack post in response to "I just
> want to be left alone", after all.
>
> > I have even now not made it clear enough (although the middle part
> > of this reply is another attempt).
>
> Your opinion is crystal clear. I hope by now so is mine: I do not want
> you to make yours even clearer. I want you to drop the subject and leave
> me in peace.
>
> >>> I described your argument as a strawman argument because
> >> you're an asshole. Yes, yes, I know.
>
> > Selective quotation
>
> Please do not change the subject.
>
> >>> your flawed understanding
> >>> led you to believe, mistakenly
> >> Stop personally-attacking me at once.
>
> > Firstly, I'm not personally attacking you.
>
> Yes, you are. You are publicly calling my intelligence into question.
> That is an insult. It's the same as if you posted "Seamus MacRae is an
> idiot" on the billboard at Times Square.
>
> How would you like it if someone put "Richard Heathfield is an idiot" on
> there?
>
> I'm guessing you wouldn't.
>
> Please let this entire matter just drop, for both of our sakes.
>
> > I am having a discussion on Usenet.
>
> You are discussing a person in public without that person's consent.
> That is a no-no.
>
> > Secondly, I am sure you would agree that you are wholly
> > entitled to make your own choice about whether to take part in, or
> > to withdraw from, this discussion.
>
> Then I choose to withdraw from it, by which is meant my name will not
> appear any further in it, which in turn means you do not talk about me
> and you do not follow up to one of my posts.
>
> Is that clear?
>
> Otherwise, I am "taking part" by being mentioned or quoted in it,
> against my will and in violation of that very entitlement that you just
> admitted I possess.
>
> >> You will not again use the
> >> words "flawed" or "mistaken" to describe me in public. Do I make
> >> myself clear?
>
> > You make yourself perfectly clear, but [insults deleted]
> > You don't get to decide what I write.
>
> Fuck you.
>
> Obviously, you understand me perfectly and are explicitly refusing to
> leave me alone.
>
> Fine. If you want a fight, let's fight.
>
> Your mother is so fat, she is required by law to wear a "wide load" sign
> and beep when she backs up.
>
> Your turn.
>
> >> Leave. Me. Alone.
>
> > If you don't wish to communicate with me, you can stop doing so at
> > any time.
>
> I don't wish to be communicated ABOUT in public by you.
>
> >> These newsgroups are for discussing programming, not people. I am
> >> off-topic here.
>
> > I agree
>
> Then stop talking about me!
>
> > sizeof *is* topical, and that's what I'm discussing.
>
> Get real. This stopped being about "sizeof" several posts ago when you
> decided to make things personal.
>
> > All this extraneous guff is just a side issue.
>
> All this "extraneous guff" is what actually matters to me. If you
> consider it a mere "side issue" then that's another reason for you to
> drop this thread and move on -- topic drift has taken it outside of your
> area of interest.
>
> >>>>>>> I've worked in environments like that, and found it quite
> >>>>>>> workable.
> >>>>>> Now I know why so much C software is crash-prone and generally
> >>>>>> buggy.
> >>> Spot the (groundless) personal attack, to which I reacted.
> >> There was no personal attack in my post.
>
> > That's called "special pleading".
>
> No, it's called pointing out that insulting software is not insulting a
> human being, and therefore is not a personal attack. For it to have been
> a *personal* attack it would have had to imply something negative about
> some specific *person*.
>
> >> Saying that environments
> >> that ignore a lot of compiler warnings generate buggy code is not
> >> an attack on any particular person.
>
> > Who said anything about ignoring compiler warnings?
>
> You did. That's what "environments like that" was in reference to,
> remember? Workplaces that actually do diffs on the compiler warnings and
> only pay attention to new ones, thus ignoring lots of other warnings,
> rather than attempting to get a clean build.
>
> > That is a complete misunderstanding
>
> And there you go again, making things personal and publicly accusing me
> of idiocy!
>
> Fuck you.
>
> I've had it with you. You pretend to some kind of civilized character
> but your real objective is simply to go around badmouthing anyone you
> disagree with, have the last word in any discussion, and generally shove
> your weight around. How old are you, about three?
>
> > (a) it's impossible to satisfy every compiler, and code that is
> > required for eliminating a warning on one compiler may itself cause
> > a warning on another; therefore, a clean build is not actually
> > possible in the general case for non-trivial code that must build
> > on multiple compilers;
>
> Doesn't follow. Ever heard of #ifdef and its friends? Conditional
> compilation means being able to satisfy multiple compilers, and produce
> more portable code.
>
> >>>>> Yes, it's at least partly because there are people who don't
> >>>>> know
> >>>>> [rest of personal attacks deleted]
> >>>> Stop attacking me.
> >>> For someone who doesn't like personal attacks, you sure like
> >>> making them.
> >> No, I do not. Stop publicly lying about me.
>
> > Well, it wasn't a lie, but it's possible that I was mistaken to
> > claim that you enjoyed making personal attacks.
>
> That you were.
>
> > Nevertheless, you have clearly made them.
>
> I have *now*, when you continued to publicly badmouth me. You asked for
> it, you got it. Now, are you ready to quit, or are you thirsty for more?
>
> >>>> You've said your piece and I've said mine. Move on.
> >>> I'm already in the right place.
> >> NO. YOU ARE NOT.
>
> > I respectfully disagree.
>
> Respect? That's a joke. You've shown no respect for my wishes, for my
> boundaries, or for any of the three newsgroups' topic boundaries, at
> least thus far.
>
> >> You've said your piece. It does not bear repeating.
>
> > Am I right to interpret this as "Seamus is not interested in
>
> You are right to interpret this as "Seamus is not interested in
> continuing this discussion, or in being the subject of any discussion in
> which you participate".
>
> >> MOVE ON.
>
> > I'm already in the right place.
>
> No. See above.
>
> >> Calling me a liar will not make me friendlier.
>
> > I don't believe I've called you a liar.
>
> Implied it, at any rate.
>
> > I do believe you do not understand the truth [snip]
>
> Your opinion has been noted and logged. Now here's a quarter. (%)
>
> Go call someone who gives a damn.
>
> > this belief is based on what you have written
>
> I don't care what your beliefs are based on, because I don't care about
> your beliefs, except insofar as your publicly broadcasting them might
> help or harm me.
>
> >>> That is not a personal attack, you buffoon
> >> Fuck you.
>
> > Irony is always dangerous.
>
> So is a complaint to your internet provider for flooding three
> newsgroups with offtopic drivel.
>
> >>> Okay, so I'll retract "buffoon" - but for heaven's sake, lighten
> >>> up a little
> >> After you.
>
> > I'm not the one who introduced expletives into the discussion.
>
> You are, however, the one who introduced rudeness, personal innuendos,
> and an unwillingness to leave things alone.
>
> > Nor will I sink to your level
>
> My God, are you really trying to claim the moral high ground now? How
> utterly ridiculous. It's never available at any price to the guy that
> shot first, so you can give up on that idea right quick.
>
> >>> and before "correcting" people, take the trouble
> >> to send it as private email rather than a public news post? After
> >> you.
>
> > It's more cost-effective to xxx in a public article than to send
> > emails to every single subscriber.
>
> I was, of course, suggesting that you send your insults *privately*, to
> me only, instead of airing them in public *at all*, but apparently you
> have once again missed the point. Probably, this time, deliberately.
>
> Your implied threat of emailing a large number of random people with
> letters badmouthing me by name is, of course, a very bad idea. If you
> actually do that you will lose your internet account so fast your head
> will spin. Unsolicited bulk mail is frowned upon by most service
> providers nowadays, and at the first sign that you did anything like
> that I'd report you as a spammer.
>
> Anyway, I guess it's now your move. Will you decide to leave things be,
> and consider this match a draw, or are you determined to win (or maybe
> just to get the last word) even though you risk losing by pressing
> things? We shall see.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h066u8$sd2$1@news.eternal-september.org>
MarkH wrote:
> Your ISP has been notified of your mental disturbance.
Who the hell are you, and what is your problem? Why pop up at random and
flame someone?
I have no "mental disturbance". Do not lie about me in public again.
> Now stop the personal attacks Seamus!
I would if I could, by pulling Richard's plug.
> and admit that Common Lisp is better than Java.
It is not.
> You've been warned! Don't allow your mental malfunctions to
> further hurt you.
I have no mental malfunctions. I suspect that you do, since you:
a) butted into an OT discussion to flame someone essentially at random;
b) top-posted;
c) via Google Groups;
d) without trimming the quoted material -- all fifteen KB of it; and
e) told a whole bunch of easily-detected lies.
On 2 Jun., 23:09, Seamus MacRae <··········@live.ca.invalid> wrote:
> Richard Heathfield wrote:
> > Seamus MacRae said:
> >> Richard Heathfield wrote:
> >>>>>>> Firstly, the preferred idiom is:
>
> >>>>>>> struct tm *foo = calloc(sizeof *foo);
> >>>>>> Surely not? That dereferences an uninitialized pointer,
> >>>>>> thereby invoking undefined behavior.
> >>>>> Surely not! The sizeof operator does not evaluate its operand
> >>>> It must at least partly do so, in order to know what size of
> >>>> thing *foo is referring to.
> >>> It is *forbidden* to do so
> >> Then how the heck is it supposed to know what size the thing is
> >> it's pointing to?
> > I think you're confusing
> I am not.
The compile time operator 'sizeof' determines the size of a
given variable, constant or type at compile time. This is done
by using the type of the variable or constant or by using the
given type. The compiler knows the sizes of most data
structures. When the size cannot be determined at compile
time the sizeof operator cannot do something reasonable.
E.g.: When using void * pointers the size of the destination
of a void pointer cannot be reasonable determined at compile
time since the compiler cannot know where the void pointer
points to. I am not sure what you get for 'sizeof(void)' but
this will probably not be something you want to use. Since
'sizeof' is executed at compile time there is nothing that can
be executed at runtime. The compiler replaces the sizeof
expression by an unsigned integer of type size_t.
E.g.: When the structure ' tm' is defined as:
struct tm {
char ch[8];
};
The expression
struct tm *foo = malloc(sizeof *foo);
is probably equivalent to something like
struct tm *foo = malloc(8);
Note that I used 'malloc' instead of 'calloc', since 'calloc'
usually has two parameters.
The explanation above refers to K&R C and to C89.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <RaOdned0PPtw17vXnZ2dnUVZ8hVi4p2d@bt.com>
·············@gmx.at said:
<good explanation snipped>
> I am not sure what you get for 'sizeof(void)' but
> this will probably not be something you want to use.
You get a constraint violation, because void is an incomplete type:
The sizeof operator
Constraints
1 The sizeof operator shall not be applied to an expression that has
function type or an incomplete type, to the parenthesized name of
such a type, or to an expression that designates a bit-field
member."
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0673j$sd2$3@news.eternal-september.org>
Richard Heathfield wrote:
> ·············@gmx.at said:
>
> <good explanation snipped>
What "good explanation"? There was a basic error in the first line of
his attempt to "explain", indirectly, why he thinks I'm an idiot.
Of course, there had to be; since I am not an idiot, any purported proof
otherwise necessarily contains some flaw, and in this instance it did
not take me very long to find it.
On 3 Jun., 18:07, Seamus MacRae <··········@live.ca.invalid> wrote:
> Richard Heathfield wrote:
> > ·············@gmx.at said:
>
> > <good explanation snipped>
>
> What "good explanation"?
Sorry that I tried to explain how the 'sizeof' operator works in
K&R C and C89. Since you obviously already know everything
it is pointless to explain something to you. I apologize that I did
not recognize your genius. Everybody should start to praise your
wisdom and your infallibility. Reality will change such that you
are always right.
Message for everybody else:
Draw you own conclusions how the C89 'sizeof' operator and
reality works.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p17p$96d$3@news.eternal-september.org>
·············@gmx.at wrote:
> On 3 Jun., 18:07, Seamus MacRae <··········@live.ca.invalid> wrote:
>> Richard Heathfield wrote:
>>> ·············@gmx.at said:
>>> <good explanation snipped>
>> What "good explanation"?
>
> Sorry that I tried to explain how [insults deleted]
Insincere apologies will get you nowhere.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <1bednZMOQ448ebvXnZ2dnUVZ8hCdnZ2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> ·············@gmx.at said:
>>
>> <good explanation snipped>
>
> What "good explanation"?
"The compile time operator 'sizeof' determines the size of a
given variable, constant or type at compile time. This is done
by using the type of the variable or constant or by using the
given type. The compiler knows the sizes of most data
structures. When the size cannot be determined at compile
time the sizeof operator cannot do something reasonable.
E.g.: When using void * pointers the size of the destination
of a void pointer cannot be reasonable determined at compile
time since the compiler cannot know where the void pointer
points to. I am not sure what you get for 'sizeof(void)' but
this will probably not be something you want to use. Since
'sizeof' is executed at compile time there is nothing that can
be executed at runtime. The compiler replaces the sizeof
expression by an unsigned integer of type size_t."
See
<····································@21g2000vbk.googlegroups.com>
for the full article.
His explanation doesn't take VLAs into account, but that's not a
huge deal since VLAs are a C99 feature, and the number of
conforming C99 installations (expressed as a percentage of the
total number of C installations) is vanishingly small - and in any
case the point under discussion is not to do with VLAs, as has
already been pointed out on a number of occasions.
> There was a basic error in the first line
> of his attempt to "explain", indirectly, why he thinks I'm an
> idiot.
I don't see any basic error in his explanation (unless you mean
omitting the special case of VLAs, which is no big deal), and it
was an explanation of sizeof, not an explanation of why he thinks
you're an idiot. Whether he does think you are an idiot is not
clear, because he hasn't expressed an opinion on the matter. What
he expressed was a technical view of sizeof, and a reasonably good
one at that.
> Of course, there had to be; since I am not an idiot, any purported
> proof otherwise necessarily contains some flaw, and in this
> instance it did not take me very long to find it.
I don't think anyone is trying to prove you an idiot. It is entirely
possible that people may be coming to that conclusion anyway,
however, but this is based on your own statements, not those of
others.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p1eu$bhb$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>
>> Richard Heathfield wrote:
>>> ·············@gmx.at said:
>>>
>>> <good explanation snipped>
>> What "good explanation"?
>
> [calls me a liar]
That's an insult, not a good explanation of anything.
> His explanation doesn't take VLAs into account, but that's not a
> huge deal since VLAs are a C99 feature, and the number of
> conforming C99 installations (expressed as a percentage of the
> total number of C installations) is vanishingly small etc etc
Excuses, excuses.
>> There was a basic error in the first line
>> of his attempt to "explain", indirectly, why he thinks I'm an
>> idiot.
>
> I don't see any basic error in his explanation
Well, one basic error was the very fact of his trying to "explain", in
public, why he thinks I'm an idiot.
Another was, of course, ignoring VLAs.
>> Of course, there had to be; since I am not an idiot, any purported
>> proof otherwise necessarily contains some flaw, and in this
>> instance it did not take me very long to find it.
>
> I don't think anyone is trying to prove you an idiot.
So you say, but your very own actions demonstrate otherwise.
> It is entirely possible that people may be coming to that conclusion
> anyway, however, but this is based on your own statements, not those
> of others.
And there you go again. A rather verbose and indirect way of publicly
calling me an idiot. I suppose you think wording it in such a convoluted
manner is somehow "clever" and will make people more likely to believe
you than if you just said, directly, "Seamus MacRae is an idiot". Not
that it matters: it's just as big a lie however you word it. And it also
puts the lie to what you said just beforehand. You clearly are, as
demonstrated by your actions, trying (and failing) to prove me an idiot,
despite your assertions to the contrary.
And, of course, that is highly illegitimate behavior on your part. Shame
on you!
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0670j$sd2$2@news.eternal-september.org>
·············@gmx.at wrote:
> On 2 Jun., 23:09, Seamus MacRae <··········@live.ca.invalid> wrote:
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> Richard Heathfield wrote:
>>>>>>>>> Firstly, the preferred idiom is:
>>>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>>>> thereby invoking undefined behavior.
>>>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>>>> It must at least partly do so, in order to know what size of
>>>>>> thing *foo is referring to.
>>>>> It is *forbidden* to do so
>>>> Then how the heck is it supposed to know what size the thing is
>>>> it's pointing to?
>>> I think you're confusing
>> I am not.
>
> The compile time operator 'sizeof' determines the size of a
> given variable, constant or type at compile time.
Impossible, since variable-length arrays were added.
[rest of post deleted unread since it clearly depended upon the above
false premise]
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <871vq1qo4n.fsf@blp.benpfaff.org>
Seamus MacRae <··········@live.ca.invalid> writes:
> ·············@gmx.at wrote:
>> The compile time operator 'sizeof' determines the size of a
>> given variable, constant or type at compile time.
>
> Impossible, since variable-length arrays were added.
The addition of variable-length arrays in C99 only affects the
case where the operand of sizeof is in fact a variable-length
array. It has no effect on other cases.
Here is what the text in C99 says. Please note the final
sentence in particular:
The sizeof operator yields the size (in bytes) of its
operand, which may be an expression or the parenthesized
name of a type. The size is determined from the type of the
operand. The result is an integer. If the type of the
operand is a variable length array type, the operand is
evaluated; otherwise, the operand is not evaluated and the
result is an integer constant.
--
RMS on DRM: "This ought to be a crime. And, if we had governments of the
people, by the people, for the people, then the executives of those companies
would be in prison. But they're not in prison, and the reason is that we have
government of the people, by the sell-outs, for the corporations."
From: Lars Enderin
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4A26A643.4030508@telia.com>
Ben Pfaff wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>
>> ·············@gmx.at wrote:
>>> The compile time operator 'sizeof' determines the size of a
>>> given variable, constant or type at compile time.
>> Impossible, since variable-length arrays were added.
>
> The addition of variable-length arrays in C99 only affects the
> case where the operand of sizeof is in fact a variable-length
> array. It has no effect on other cases.
>
> Here is what the text in C99 says. Please note the final
> sentence in particular:
>
> The sizeof operator yields the size (in bytes) of its
> operand, which may be an expression or the parenthesized
> name of a type. The size is determined from the type of the
> operand. The result is an integer. If the type of the
> operand is a variable length array type, the operand is
> evaluated; otherwise, the operand is not evaluated and the
> result is an integer constant.
Seamus has been told the facts about this repeatedly, but you must
realize that when facts disagree with Seamus, the facts must be wrong,
since Seamus is *never* wrong. At least that is what he claims. He has
serious problems with reality.
From: Kaz Kylheku
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <20090615110625.786@gmail.com>
On 2009-06-03, Lars Enderin <············@telia.com> wrote:
> Seamus has been told the facts about this repeatedly, but you must
> realize that when facts disagree with Seamus, the facts must be wrong,
> since Seamus is *never* wrong. At least that is what he claims. He has
> serious problems with reality.
There is copious evidence that Shameful Macro /knows/ that he is wrong.
Yes, he is desperately trying to uphold a self-image of competence and
infallible correctness. But that self-image is fragile, because it is the
result of an imperfect self-deception. (Self-deceptions rarely are perfect,
but even imperfect ones are insane).
If his self-image wasn't fragile, he wouldn't fly off the handle any
time he is confronted with evidence which contradicts the self-deception.
He knows that he looks like an idiot, but he wants to project that problem onto
whoever is calling him an idiot at the moment. Hence, ``Stop attacking me and
making me look like an idiot!''.
Not only does he believe that he is infallibly right, he believes that people
somehow have the magic power to make others look like idiots. I.e. the
manifestation of idiocy does not stem from the words and actions of the idiot,
but rather it is an image impressed onto him by words uttered by others! If
those others simply refrain from those words, then he won't look like an idiot.
In-freaking-sane. And stupid. What a combo.
Insane and smart, I can't work with either, but can at least respect.
:)
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p1q6$ecg$1@news.eternal-september.org>
Kaz Kylheku wrote:
> On 2009-06-03, Lars Enderin <············@telia.com> wrote:
>> Seamus ... has serious problems with reality.
I do not. Lars is lying.
> There is copious evidence that Shameful Macro /knows/ that he is wrong.
This is another lie. My name is Seamus MacRae and I am not wrong.
> Yes, he is desperately trying to uphold a self-image of competence
This implication that I am incompetent is yet another lie.
> But that self-image is fragile, because it is the result of an imperfect
> self-deception.
This implication that I am insane is yet another lie.
> He knows that he looks like an idiot
This implication that I am an idiot is yet another lie.
Stop lying about me, and stop trying to suppress the truth by trying to
misdirect replies away from two of the groups you're spreading lies in.
> Not only does he believe that he is infallibly
Strawman. I never made any such claims.
> [more childish namecalling]
That is not a rational argument in favor of any point being contended here.
> In-freaking-sane. And stupid. What a combo.
Neither is that. The ad hominem form of argument is a logical fallacy.
It will convince no-one.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p1iq$bhb$3@news.eternal-september.org>
Lars Enderin wrote:
> Ben Pfaff wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>
>>> ·············@gmx.at wrote:
>>>> The compile time operator 'sizeof' determines the size of a
>>>> given variable, constant or type at compile time.
>>> Impossible, since variable-length arrays were added.
>>
>> The addition of variable-length arrays in C99 only affects the
>> case where the operand of sizeof is in fact a variable-length
>> array. It has no effect on other cases.
Nonsense. What about a struct that contains a variable length array as a
field?
> Seamus has been told the facts about this repeatedly
I have been told a mixture of facts, out-of-date claims, outright
errors, and outright intentional vicious lies, a lot of the latter by you.
> He has serious problems with reality.
See? Here is another one.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <7e6dnRG_XM4jgq3XnZ2dnUVZ8n6dnZ2d@bt.com>
[I have refrained from replying to most of the recent spate of
nonsensical SMR replies, no doubt to everyone's relief - but
there's a technical issue involved in this one, hence this reply.]
Seamus MacRae said:
> Lars Enderin wrote:
>> Ben Pfaff wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>
>>>> ·············@gmx.at wrote:
>>>>> The compile time operator 'sizeof' determines the size of a
>>>>> given variable, constant or type at compile time.
>>>> Impossible, since variable-length arrays were added.
>>>
>>> The addition of variable-length arrays in C99 only affects the
>>> case where the operand of sizeof is in fact a variable-length
>>> array. It has no effect on other cases.
>
> Nonsense. What about a struct that contains a variable length
> array as a field?
That would be a constraint violation requiring a diagnostic message
(see 6.7.5.2(2)).
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u7bq$vdm$3@news.eternal-september.org>
Richard Heathfield wrote:
> [I have refrained from replying to most of the recent spate of
> nonsensical SMR replies
I don't know anything about "nonsensical SMR replies", but I guess the R
maybe stands for Richard, since you are the most voluminous current
source of nonsensical post-content in this thread.
> Seamus MacRae said:
>> Lars Enderin wrote:
>>> Ben Pfaff wrote:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>
>>>>> ·············@gmx.at wrote:
>>>>>> The compile time operator 'sizeof' determines the size of a
>>>>>> given variable, constant or type at compile time.
>>>>> Impossible, since variable-length arrays were added.
>>>> The addition of variable-length arrays in C99 only affects the
>>>> case where the operand of sizeof is in fact a variable-length
>>>> array. It has no effect on other cases.
>> Nonsense. What about a struct that contains a variable length
>> array as a field?
> That would be a constraint violation
Excuses, excuses.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p1gj$bhb$2@news.eternal-september.org>
Ben Pfaff wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>
>> ·············@gmx.at wrote:
>>> The compile time operator 'sizeof' determines the size of a
>>> given variable, constant or type at compile time.
>> Impossible, since variable-length arrays were added.
>
> The addition of variable-length arrays in C99 only affects the
> case where the operand of sizeof is in fact a variable-length
> array. It has no effect on other cases.
Nonsense. What about a struct that contains a variable-length array as a
field?
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87ws7jrfxt.fsf@blp.benpfaff.org>
Seamus MacRae <··········@live.ca.invalid> writes:
> Ben Pfaff wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>
>>> ·············@gmx.at wrote:
>>>> The compile time operator 'sizeof' determines the size of a
>>>> given variable, constant or type at compile time.
>>> Impossible, since variable-length arrays were added.
>>
>> The addition of variable-length arrays in C99 only affects the
>> case where the operand of sizeof is in fact a variable-length
>> array. It has no effect on other cases.
>
> Nonsense. What about a struct that contains a variable-length array as
> a field?
A struct cannot contain a variable-length array.
--
Ben Pfaff
http://benpfaff.org
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u7cc$vdm$4@news.eternal-september.org>
Ben Pfaff wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>
>> Ben Pfaff wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>
>>>> ·············@gmx.at wrote:
>>>>> The compile time operator 'sizeof' determines the size of a
>>>>> given variable, constant or type at compile time.
>>>> Impossible, since variable-length arrays were added.
>>> The addition of variable-length arrays in C99 only affects the
>>> case where the operand of sizeof is in fact a variable-length
>>> array. It has no effect on other cases.
>> Nonsense. What about a struct that contains a variable-length array as
>> a field?
>
> A struct cannot contain a variable-length array.
I don't see why not. It can contain any other data type.
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <878wjxfe7w.fsf@blp.benpfaff.org>
Seamus MacRae <··········@live.ca.invalid> writes:
> Ben Pfaff wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>
>>> Ben Pfaff wrote:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>
>>>>> ·············@gmx.at wrote:
>>>>>> The compile time operator 'sizeof' determines the size of a
>>>>>> given variable, constant or type at compile time.
>>>>> Impossible, since variable-length arrays were added.
>>>> The addition of variable-length arrays in C99 only affects the
>>>> case where the operand of sizeof is in fact a variable-length
>>>> array. It has no effect on other cases.
>>> Nonsense. What about a struct that contains a variable-length array as
>>> a field?
>>
>> A struct cannot contain a variable-length array.
>
> I don't see why not. It can contain any other data type.
Because the C standard says so:
Only an ordinary identifier (as defined in 6.2.3) with both
block scope or function prototype scope and no linkage shall
have a variably modified type.
There's also a footnote that makes it more explicit:
102) A structure or union can not contain a member with a
variably modified type because member names are not
ordinary identifiers as defined in 6.2.3.
where "variably modified" is defined as:
If the nested sequence of declarators in a full declarator
contains a variable length array type, the type specified by
the full declarator is said to be variably modified.
--
"I consider that the golden rule requires that if I like a program
I must share it with other people who like it."
--Richard Stallman
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h10muj$jpm$4@news.eternal-september.org>
Ben Pfaff wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>> Ben Pfaff wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>> Ben Pfaff wrote:
>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>> ·············@gmx.at wrote:
>>>>>>> The compile time operator 'sizeof' determines the size of a
>>>>>>> given variable, constant or type at compile time.
>>>>>> Impossible, since variable-length arrays were added.
>>>>> The addition of variable-length arrays in C99 only affects the
>>>>> case where the operand of sizeof is in fact a variable-length
>>>>> array. It has no effect on other cases.
>>>> Nonsense. What about a struct that contains a variable-length array as
>>>> a field?
>>> A struct cannot contain a variable-length array.
>> I don't see why not. It can contain any other data type.
>
> [babble deleted]
A repeated assertion is not the same thing as a rationale.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <UpGdnWUPmJX4fK7XnZ2dnUVZ8lBi4p2d@bt.com>
Seamus MacRae said:
> Ben Pfaff wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>> Ben Pfaff wrote:
<snip>
>>>> A struct cannot contain a variable-length array.
>>> I don't see why not. It can contain any other data type.
>>
>> [babble deleted]
This "babble" was a relevant quote from ISO/IEC 9899.
>
> A repeated assertion is not the same thing as a rationale.
He didn't give you an assertion. He didn't give you a rationale. He
gave you chapter and verse from the relevant International
Standard. Duh.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h13a0a$731$5@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Ben Pfaff wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>> Ben Pfaff wrote:
>>>>> A struct cannot contain a variable-length array.
>>>> I don't see why not. It can contain any other data type.
>>> [babble deleted]
>> A repeated assertion is not the same thing as a rationale.
>
> He didn't give you a rationale.
Exactly my point.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <LfCdnVWbGfOt0qjXnZ2dnUVZ8kFi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>> Ben Pfaff wrote:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>> Ben Pfaff wrote:
>>>>>> A struct cannot contain a variable-length array.
>>>>> I don't see why not. It can contain any other data type.
>>>> [babble deleted]
>>> A repeated assertion is not the same thing as a rationale.
>>
>> He didn't give you a rationale.
>
> Exactly my point.
He gave you BETTER than a rationale. He gave you a relevant citation
from the Standard.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h163ov$lco$7@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> A repeated assertion is not the same thing as a rationale.
>>> He didn't give you a rationale.
>> Exactly my point.
>
> He gave you BETTER than a rationale.
No, he did not. "Because I said so" is not an acceptable answer for me.
Nor is "because so-and-so said so". Not even if "so-and-so" is the
President.
Where do you live, where such a thing is considered a satisfactory
answer? North Korea?
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <9J6dnRpFT6FSVq_XnZ2dnUVZ8vKdnZ2d@bt.com>
Seamus MacRae said:
> Ben Pfaff wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>
>>> Ben Pfaff wrote:
<snip>
>>>> The addition of variable-length arrays in C99 only affects the
>>>> case where the operand of sizeof is in fact a variable-length
>>>> array. It has no effect on other cases.
>>> Nonsense. What about a struct that contains a variable-length
>>> array as a field?
>>
>> A struct cannot contain a variable-length array.
>
> I don't see why not.
Because it's a constraint violation, as has already been pointed
out.
> It can contain any other data type.
But not a variable-length array.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h10mvd$jpm$5@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Ben Pfaff wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>
>>>> Ben Pfaff wrote:
>>>>> The addition of variable-length arrays in C99 only affects the
>>>>> case where the operand of sizeof is in fact a variable-length
>>>>> array. It has no effect on other cases.
>>>> Nonsense. What about a struct that contains a variable-length
>>>> array as a field?
>>> A struct cannot contain a variable-length array.
>> I don't see why not.
>
> Because it's a constraint violation, as has already been pointed
> out.
That's not an explanation; that's some kind of word games.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <UpGdnWQPmJUDfK7XnZ2dnUVZ8lBi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>> Ben Pfaff wrote:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>
>>>>> Ben Pfaff wrote:
>>>>>> The addition of variable-length arrays in C99 only affects
>>>>>> the case where the operand of sizeof is in fact a
>>>>>> variable-length
>>>>>> array. It has no effect on other cases.
>>>>> Nonsense. What about a struct that contains a variable-length
>>>>> array as a field?
>>>> A struct cannot contain a variable-length array.
>>> I don't see why not.
>>
>> Because it's a constraint violation, as has already been pointed
>> out.
>
> That's not an explanation; that's some kind of word games.
If you mean you don't know what a constraint violation is, the news
does not surprise me.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h13a1q$731$6@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> Ben Pfaff wrote:
>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>> Ben Pfaff wrote:
>>>>>>> The addition of variable-length arrays in C99 only affects
>>>>>>> the case where the operand of sizeof is in fact a
>>>>>>> variable-length
>>>>>>> array. It has no effect on other cases.
>>>>>> Nonsense. What about a struct that contains a variable-length
>>>>>> array as a field?
>>>>> A struct cannot contain a variable-length array.
>>>> I don't see why not.
>>> Because it's a constraint violation, as has already been pointed
>>> out.
>> That's not an explanation; that's some kind of word games.
> [calls me an idiot]
That your sole response is more namecalling rather than any sort of
attempt at reason does not surprise me.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <LfCdnVSbGfM20qjXnZ2dnUVZ8kFi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>> Richard Heathfield wrote:
>>>> Seamus MacRae said:
>>>>> Ben Pfaff wrote:
>>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>>> Ben Pfaff wrote:
>>>>>>>> The addition of variable-length arrays in C99 only affects
>>>>>>>> the case where the operand of sizeof is in fact a
>>>>>>>> variable-length
>>>>>>>> array. It has no effect on other cases.
>>>>>>> Nonsense. What about a struct that contains a
>>>>>>> variable-length array as a field?
>>>>>> A struct cannot contain a variable-length array.
>>>>> I don't see why not.
>>>> Because it's a constraint violation, as has already been
>>>> pointed out.
>>> That's not an explanation; that's some kind of word games.
>> [calls me an idiot]
>
> That your sole response is more namecalling rather than any sort
> of attempt at reason does not surprise me.
I tried reason. You don't seem to understand the concept. If you
did, you'd look up the relevant information in the Standard and
then you'd actually learn something. You seem determined to avoid
this course.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h163sg$lco$8@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> That's not an explanation; that's some kind of word games.
>>> [calls me an idiot]
>> That your sole response is more namecalling rather than any sort
>> of attempt at reason does not surprise me.
>
> I tried reason.
You failed. Perhaps if you tried to be more *reasonable*, you'd have
more success in that area, but no, you insist that you cannot be wrong
and anyone who disagrees with you not only cannot be right, but must be
an idiot. Since you're completely incapable of compromise, negotiation,
or civilly agreeing to disagree, you always fail when you try reason.
On 3 Jun., 18:05, Seamus MacRae <··········@live.ca.invalid> wrote:
> ·············@gmx.at wrote:
> > On 2 Jun., 23:09, Seamus MacRae <··········@live.ca.invalid> wrote:
> >> Richard Heathfield wrote:
> >>> Seamus MacRae said:
> >>>> Richard Heathfield wrote:
> >>>>>>>>> Firstly, the preferred idiom is:
> >>>>>>>>> struct tm *foo = calloc(sizeof *foo);
> >>>>>>>> Surely not? That dereferences an uninitialized pointer,
> >>>>>>>> thereby invoking undefined behavior.
> >>>>>>> Surely not! The sizeof operator does not evaluate its operand
> >>>>>> It must at least partly do so, in order to know what size of
> >>>>>> thing *foo is referring to.
> >>>>> It is *forbidden* to do so
> >>>> Then how the heck is it supposed to know what size the thing is
> >>>> it's pointing to?
> >>> I think you're confusing
> >> I am not.
> > The compile time operator 'sizeof' determines the size of a
> > given variable, constant or type at compile time.
> Impossible, since variable-length arrays were added.
struct tm * is NOT a variable-length array. Additionally I said:
"The explanation above refers to K&R C and to C89."
AFAIK C99 is used by a minority while C89 is still the
standard used by most C compilers and programmers.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p1r7$ecg$2@news.eternal-september.org>
·············@gmx.at wrote:
> On 3 Jun., 18:05, Seamus MacRae <··········@live.ca.invalid> wrote:
>> ·············@gmx.at wrote:
>>> On 2 Jun., 23:09, Seamus MacRae <··········@live.ca.invalid> wrote:
>>>> Richard Heathfield wrote:
>>>>> Seamus MacRae said:
>>>>>> Richard Heathfield wrote:
>>>>>>>>>>> Firstly, the preferred idiom is:
>>>>>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>>>>>> thereby invoking undefined behavior.
>>>>>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>>>>>> It must at least partly do so, in order to know what size of
>>>>>>>> thing *foo is referring to.
>>>>>>> It is *forbidden* to do so
>>>>>> Then how the heck is it supposed to know what size the thing is
>>>>>> it's pointing to?
>>>>> I think you're confusing
>>>> I am not.
>>> The compile time operator 'sizeof' determines the size of a
>>> given variable, constant or type at compile time.
>> Impossible, since variable-length arrays were added.
>
> struct tm
Irrelevant, and it might contain a variable-length array as a field
regardless.
From: Ben Pfaff
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87ski7rfwj.fsf@blp.benpfaff.org>
Seamus MacRae <··········@live.ca.invalid> writes:
> ·············@gmx.at wrote:
>> struct tm
>
> Irrelevant, and it might contain a variable-length array as a field
> regardless.
A struct cannot contain a variable-length array.
--
Ben Pfaff
http://benpfaff.org
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u7cq$vdm$5@news.eternal-september.org>
Ben Pfaff wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>
>> ·············@gmx.at wrote:
>>> struct tm
>> Irrelevant, and it might contain a variable-length array as a field
>> regardless.
>
> A struct cannot contain a variable-length array.
I don't see why not. It can contain any other data type.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <RaOdneR0PPuM17vXnZ2dnUVZ8hWdnZ2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>> Richard Heathfield wrote:
>>>> I am less concerned with attacking you than with debunking
>>> I do not need "debunking", thank you very much.
>>
>> Right
>
> Then please drop this.
>
> NOW!!!
You are good at removing context. Note that what I actually said
was: "Right, but the claim you made was incorrect, and *did* need
debunking."
>>> Next time, do not "debunk" unsolicited.
>>
>> If you don't wish for mistakes in your articles to be corrected,
>> you have two choices - (a) don't make mistakes, or (b) don't post
>> them.
>
> I go for option (a), always.
This sub-thread contains a counter-example, in which you made a
mistake with regard to sizeof.
>> I make mistakes in my articles - and they /do/ get corrected,
>> and I'm pleased by that, because it means I get to learn stuff,
>> which is good, right?
>
> Are you unconcerned with how you are perceived? I'd think you'd
> rather not be publicly humiliated and made to look like an idiot.
You think getting sizeof right makes me look like an idiot? Well,
okay, but in that case what does getting it wrong make you look
like?
> If that's not the case, though, it might explain your boorish
> behavior here, where you seem unconcerned for the risk that your
> actions will have that sort of effect on someone else. If, for
> some strange reason, you wouldn't mind it yourself, then perhaps
> it just didn't occur to you that someone else *would* mind.
It didn't occur to me that anyone would object to learning something
relevant to their profession that they didn't know before. And yet
here you are.
> Well, now that you're aware of the possibility, you should know to
> just quietly move on now.
This is Usenet. I don't have to move anywhere. I can just sit right
here. What do /you/ mean by the metaphor "move on"? Do you mean
"quietly forget that Seamus MacRae doesn't understand sizeof and
has his fingers in his ears on the subject"? If so, well, I'm
prepared to do that. What I'm not prepared to do is accede to what
I consider (rightly or wrongly) to be attempts at threatening
language (do this, do that, don't do this, don't do that, capital
letters, "you have been warned", etc). I don't respond well to
threats, so if you write in a way that I perceive to be threatening
it is very unlikely to have the desired effect.
>>>>>>>> Firstly, the preferred idiom is:
>>>>>>>>
>>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>>> Surely not? That dereferences an uninitialized pointer,
>>>>>>> thereby invoking undefined behavior.
>>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>>> It must at least partly do so, in order to know what size of
>>>>> thing *foo is referring to.
>>>> It is *forbidden* to do so
>>> Then how the heck is it supposed to know what size the thing is
>>> it's pointing to?
>>
>> I think you're confusing
>
> I am not.
Then you must be confused.
>
> I am also not interested in entertaining any more public
> speculation about my mental functioning.
Fine, but I used the word in passing (in what I consider to be a
legitimate way); it was you who pointed it out for special mention.
So it seems to me that you are interested in precisely that
subject. I'm not. I'm interested in sizeof.
> Drop it.
You don't get to control my actions, remember?
> Now.
I get to decide what I do and when I do it, remember?
>
>>> Regardless, it's been drilled in repeatedly: if "*foo" is
>>> encountered when foo is uninitialized, Bad Things may happen.
>>
>> Sure - but this isn't *foo; it's sizeof *foo
>
> Which contains *foo as an argument, for heaven's sake.
No, it doesn't. In sizeof *foo, *foo is the /operand/ of sizeof, not
its argument. Arguments are, by definition, evaluated. Operands
need not be.
I know from experience that you don't take a lot of notice of proof,
but here it is anyway. It proves you wrong by definition, so even
if it doesn't convince you it may convince other readers of this
subthread:
Firstly, we have the C Standard's definition of operators (C89
numbering, but I can easily find all this in C99 if required):
3.1.5 Operators
Syntax
operator: one of
[ ] ( ) . ->
++ -- & * + - ~ ! sizeof
/ % << >> < > <= >= == != ^ | && ||
? :
= *= /= %= += -= <<= >>= &= ^= |=
, # ##
Note the presence of sizeof in the list. So sizeof is an operator.
(Then there are some constraints which needn't concern us because
they're about paired operators and macro directives, so I've left
them out.) Next we have:
Semantics
An operator specifies an operation to be performed (an evaluation )
that yields a value, or yields a designator, or produces a side
effect, or a combination thereof. An operand is an entity on which
an operator acts.
Since sizeof operates on *foo, *foo is the operand of sizeof.
The word "argument" is defined by the Standard separately. It means:
"an expression in the comma-separated list bounded by the
parentheses in a function call expression, or a sequence of
preprocessing tokens in the comma-separated list bounded by the
parentheses in a function-like macro invocation. Also known as
``actual argument'' or ``actual parameter.''
Since sizeof *foo isn't a macro invocation or a function call
expression, *foo can't be an argument to sizeof. QED.
>>>>>>>> Secondly, although all-bits-zero does indeed represent 0.0
>>>>>>>> or NULL on many platforms, it is not guaranteed by the C
>>>>>>>> Standard so to do.
>>>>>>> Have you ever seen a reasonably modern system where it
>>>>>>> wasn't?
>>>>>> Have you ever seen a reasonably modern system that had
>>>>>> precisely the same architecture in all respects as the most
>>>>>> common architecture of the previous generation? There are
>>>>>> real systems where NULL is not all-bits-zero
>>>>> Yes, but are any of them in widespread use?
>>>> You missed my point.
>>> No, I did not.
>>
>> Yes
>
> No, and this is not negotiable. I do not miss points. Now move
> along.
You don't get to control my actions. You have snipped the
explanation I gave of why I considered you to have missed my point.
>>>>>> and real systems where 0.0 is not all-bits-zero.
>>>>> Not IEEE754-compatible ones.
>>>> You missed my point.
>>> No, I did not. I repeat again: not IEEE754-compatible ones.
>>
>> If you are prepared to limit yourself to systems that use
>> IEEE754-compatible floating point systems, that's your decision
>> to make.
>
> Since that's the vast majority of systems in present-day use, it
> doesn't seem to be a biggie.
Things change. What seems ubiquitous today can become niche market
tomorrow. Anyone remember DEC VAX?
>
>>>>>> In the absence of a guarantee from Silicon Valley that this
>>>>>> will never, ever, ever happen again, I will continue to
>>>>>> assume the worst when writing code that I need to be
>>>>>> maximally portable.
>>>>> And I will continue to use Java when writing code that I need
>>>>> to be maximally portable. C is for systems-level stuff now.
>>>>> :-)
>>>> Fine, you're entitled to think that
>>> Don't patronize me.
>>
>> Firstly, I told you before
>
> I said, don't patronize me. And what's the next thing you do?
> Patronize me!
Firstly, no, I wasn't patronising you; I was explaining to you. It's
not immediately clear what I was explaining to you because you
snipped it and I can't be bothered to check back. Secondly, just
because you tell me to do something (or refrain from doing
something), that doesn't put me under any obligation to obey you.
> Fuck off. You are clearly a complete waste of bandwidth and
> congenitally incapable of remaining polite or civil.
You are the one who's swearing, not me.
>
>> I'm still treating you like an intelligent man
>
> Ordinarily, one does not treat intelligent men as shoddily as
> you've treated me.
Intelligent men do not react in the way you react. I have therefore
changed my opinion of you.
> In particular, when an intelligent man requests
> that you drop a condescending tone,
I haven't even reached for my condescending tone during this whole
conversation so far. Nevertheless, you tempt me to reach for it.
> or drop an entire line of questioning,
I haven't /had/ a line of questioning. I've pointed out a mistake in
your understanding of sizeof. You are the one who is prolonging
this discussion by continuing to insist that you were not mistaken.
Each time you post anything that amounts to such a claim, it's a
mistake, and mistakes that are posted to Usenet do tend to get
corrected. If you don't want me to correct your mistakes, the best
way to achieve that would be either to stop making them or at least
stop posting them. Your call, however - you do what you like. And
so do I.
> then unless you are a police interrogator and he is a
> murder suspect, you do so! Any other behavior is extremely
> impolite.
Do you consider swearing to be extremely impolite? I do. And you are
losing 2-0 on expletives, let alone on strident demands (I've lost
count of the number of those you've made in this subthread).
>
>> That opinion, however, is beginning to change.
>
> Is that a threat?
It doesn't look like one to me. It just says that I was revising my
opinion of your intelligence (downwards). Intelligent people are
capable of learning, but you have shown little sign of this with
regard to the subject of this discussion, i.e. sizeof, so it's not
unnatural for me to reconsider, say, my use of polysyllables.
Having said that, it's hard to say "operator" in one syllable,
isn't it? So I'm kinda stuck as to how to explain sizeof in a way
you have a reasonable chance of understanding.
> Actually, I frankly don't care about your opinion of me,
Neither do I. But I /do/ care about the public understanding of
sizeof, which is what I'm trying to discuss in this thread and
which you appear to me to be making every effort to avoid
discussing. You are devoting far more typing to your reaction to
what you perceive to be my opinion of you than you are to the
actual subject at hand.
> just so
> long as you don't broadcast it loudly but keep it to yourself as a
> polite person would.
By prolonging the discussion of your behaviour, you are making its
continuation more likely. If that's what you want (despite what you
say), fine. If it's not what you want, you might want to consider
what effective action /you/ can take to stop it.
> If you have a negative opinion of me, please keep it to yourself
> and ignore me. If you have a positive opinion of me, then feel
> free to not insult me in public.
>
>>> Please go look in a mirror and adjust that attitude you're
>>> wearing.
>>
>> "Please" is a good start [rest of patronizing crap deleted]
3-0, if that's considered an expletive (as it is by many). But what
I said was not patronising. It was a carefully measured point -
that you've dug a big hole and "please" is a short ladder. If you
want a civil discussion, you are going to have to work at it by
being civil. Unmarked snippage and selective quotation are not
civil behaviour. Nor is the use of expletive.
> Either discuss the original subject matter or remain silent
> please.
I'm trying to discuss the original subject matter that spawned this
subthread - sizeof - but you seem remarkably reluctant to
contribute, which is why that part of the conversation is all but
dead, despite my attempts to keep it going. You seem determined to
prolong all this extraneous discussion about *you*, which I find
terribly tedious and which I'd be as happy to drop if only you
would stop making all these ridiculous claims.
>
>>>>> Do not personally attack me or accuse me of intellectually
>>>>> dishonest behavior again. You have been warned.
>>>> It wasn't a personal attack
>>> Like hell it wasn't. You publicly berated me
>>
>> Actually, I
>
> Actually, I'm not interested in your explanations or excuses.
That reaction leads me to suspect that you're not interested in
truth or reasoning. Am I wrong? If so, it's easy to prove it, but
you haven't yet done so.
> I'm interested in two things:
>
> 1. Shutting down this unwelcome and off-topic inquiry into the
> status of my mental functioning, and
But I have made no such enquiry. It is not I who turned this
discussion of sizeof into a slanging match.
> 2. Getting an apology, if one might be forthcoming, though I will
> settle for complete silence instead.
You certainly won't get an apology, because I don't make a habit of
apologising for being right about sizeof. As for complete silence,
continuing to make a noise is not the right way to achieve complete
silence, so why do you continue to post?
>
>> the nature of your misunderstanding has been made crystal clear.
>
> Shall I repeat what I just said? About the unwelcome nature of any
> further public inquiry into my mental functioning?
You can if you like, but it won't make any difference to your
misunderstanding of sizeof. Duh.
> I understand perfectly.
And yet you think that, in sizeof *foo, *foo is an argument of
sizeof, and which is evaluated. That is badly wrong in two major
respects, both of which have been pointed out to you with reference
to the International Standard that defines the language.
> I do not, however, agree with your stated
> opinions of me, and I will not ever agree with them.
I can live with that. I'm not asking you to agree with what you
consider to be my stated opinions of you. Nor am I even asking you
to agree with my actual opinions of you.
> You cannot gain anything by continuing this.
All I am continuing is a discussion of sizeof in a programming
forum. If you wish to partake in that discussion, you are free to
do so. If you don't, why do you still post? Again, that's your
decision, but it does seem to be rather an odd decision.
> If you drop the subject now, we both walk away and get on with our
> lives.
The subject is sizeof. I don't know why you continue to introduce
extraneous material, but I would prefer it if you didn't do that.
And I have no intention of dropping the sizeof subject at this time
(although of course I will drop it eventually - all Usenet threads
die eventually).
> If you
> continue to publicly insinuate various unpleasant things about my
> mental functioning, you will be in for a world of shit.
Firstly, what you infer is your responsibility, not mine. I have
actually said very little about you in this thread, and I'd far
rather talk about sizeof. Secondly, as I believe I told you before,
I don't respond well to threats.
> You'll get
> at least as good as you give
When, for pity's sake? So far, I've been giving great stuff on
sizeof and all I've had back is this personal stuff, which I don't
want and don't care about. What I'd like is to find out your
technical justification for believing what you do believe about
sizeof - that is, I'd like to discuss the actual issue please. If
you can confine your discussion to that, I'll be getting as good as
I give. Up to now, however, I have been sorely disappointed on that
score.
> and will likely lose your usenet access in the bargain.
That isn't going to happen, for at least two reasons:
1) I haven't done anything wrong, as the record will show;
2) Nowadays, ISPs mostly don't care anyway, not even about spam -
they should, but they don't.
> It's your choice.
I choose to discuss sizeof, which does not evaluate its operand.
>>> and implied in front of a large audience that I was stupid
>>> and/or incompetent.
>>
>> No
>
> Yes. Publicly insulting me was bad enough. Now you have the gall
> to lie about it?
Pointing out that you are mistaken is not the same as saying you are
stupid or incompetent. Nor do you get to decide what I imply. You
have control only over what you infer. If you wish to infer in
front of a large audience that you are stupid and/or incompetent,
that is properly your decision to make.
>
>>> What the hell is the MATTER with you?
>>
>> Nothing, really. What is the matter with you
>
> Nothing. And that is final.
Except that you still don't understand sizeof.
> I am not interested in discussing or negotiating or anything like
> that. My stance regarding my own mental functioning is firm, and
> you will not budge it. You will only let yourself in for a nasty
> and pointless flamewar if you insist on continuing to poke into a
> subject matter where you have been warned repeatedly now that
> you're not welcome.
I'm not *interested*. I don't know why you think I am. It seems you
are far more interested than I am. Why don't we just get back to
sizeof?
>
>>> And with several other people in these newsgroups?
>>
>> "It was a terrible parade. [rest deleted]
>
> Parades are not on topic here.
The comment was relevant to the discussion. Either you realise this
or you don't. If you realise it and snipped it because you saw the
implication and didn't like it, you are being disingenuous. If you
didn't realise it and snipped it because you thought it irrelevant,
that says something different about you. Which of those it is, of
course I don't know and I don't care.
>
>>>> You are taking this far too personally.
>>> That isn't for you to decide.
>>
>> True enough. I will rephrase. I *believe* you are taking this far
>> too personally.
>
> Irrelevant. If I say I don't welcome a continued discussion of me
> in public, then the subject is closed, whether or not you would
> mind if our positions were reversed.
If you think the discussion is closed, why are you still
contributing to it?
> When it's your mental competence that's being discussed in public,
> then it's your turn to decide the same things.
I'm not interested in your mental competence. I am fully prepared to
believe that you have some, and I can leave it at that if you will.
I'm interested in sizeof. Shall we get back to sizeof?
> Fair's fair.
It doesn't say fair on the box. You get to decide what you post. I
get to decide what I post. That's the closest Usenet gets to fair.
If you're looking for some kind of resolution, there probably won't
be one, except perhaps in the minds of your readership.
>
>>>> This is a discussion, not a lawsuit.
>>> It's not a polite discussion, and it hasn't been since you
>>> started making things personal.
>>
>> It could be polite. I am doing my best to remain polite, and I
>> think that mostly I'm succeeding.
>
> You're not succeeding.
You are the one who has been making demands, not me, and depending
on how you define "expletive", you're losing either 2-0 or 3-0. So
I'm not overly concerned about your definition of "polite".
<snip>
>>> You made several nasty errors:
>>> 1. You nitpicked a post of mine. Bad move.
>>
>> I corrected
>
> You nitpicked where no nitpicking was welcome. Don't do it again.
>
>>> 2. Then when I responded to smooth things over,
>>
>> I don't recall your trying to smooth things over.
>
> Yes. In <································@bt.com> you nitpicked
> me,
Wrong. In that article, I did not nitpick you. I *thanked* Ben
Bacarisse for nitpicking me.
> apparently unaware that the correct response to my post was to
> either leave it alone or agree.
Wrong, partly because that article was not a response to your post
but a response to Ben's post, and partly because I don't give a
stuff what you consider the correct response to be.
>
> In <············@news.eternal-september.org> I responded in such a
> way that you could have just left that post to stand unmolested
> and everything would have been fine. Instead, you attacked and
> here we are now.
In that article, you screwed up: "That dereferences an uninitialized
pointer, thereby invoking undefined behavior. Even though it
doesn't read or write through it." That was simply wrong.
I did not "molest" that post as you claim. I responded to it, in
message ID <································@bt.com>, which is a
separate article. Your original remains, utterly unmolested, on
servers around the world, up until they expire it.
My response pointed out why your claim about dereferencing was
wrong, and I cited the relevant part of the relevant technical
standard. You have still not provided any convincing technical
explanation of your issue with that response.
>
> Given that you had several opportunities to leave me alone and
> chose instead to blast me with increasingly-stronger shots each
> time, I have to conclude that you want a fight.
No, I want to talk about sizeof.
> Now I am warning you that a fight with me will end very badly for
> you.
>
>>> you replied with
>>> a more direct and serious attack instead of letting sleeping
>>> dogs lie. Big mistake.
>>
>> Again, got a msg-ID?
>
> Yes: <································@bt.com>
That's not a serious attack. That's not even a love-tap. That's just
a technical rebuttal of a technical point. If you think that's a
serious attack, you haven't been around Usenet very long.
> This you should definitely never have posted.
Why not? Are you trying to suppress the truth about sizeof?
>> My own recollection is that you appeared to continue to
>> misunderstand
>
> I HAVE NO INTEREST IN CONTINUING TO DISCUSS YOUR OPINION OF MY
> MENTAL FUNCTIONING. HAVE I MADE MYSELF CLEAR?
Yes, you have. I have no interest in it either. Have /I/ made
/my/self clear? I want to talk about sizeof.
> Why are you so unwilling to respect multiple boundaries?
>
> 1. The topic bounds. These newsgroups are for discussing
> programming,
> not people.
sizeof qualifies.
> 2. The personal boundaries around one another. You do not publicly
> speculate about another person's mental functioning without
> permission! Jeezus.
I am not interested in speculating about your mental functioning. I
am interested in discussing sizeof.
> 3. The relevance bounds. The arguments about Lisp vs. Java,
> emacs vs. Eclipse, and Seed7 warnings, and the original
> job-search topics, all have relevance bounds. My mental
> functioning is irrelevant to all of those topics. The only
> person whose mental functioning might be relevant to any of
> them is Robert Maas, the original job-seeker.
In this thread, I'm not interested in any of these things. I'm
interested in the technical details of sizeof, which arose in this
discussion due to topic drift, a natural process which happens all
over Usenet all the time.
>>> 3. You continued to not back down when I continued to try to
>>> reset things to the appropriate state so that the
>>> discussion could move on in other directions.
>>
>> Why would I back down from a correct position?
>
> I refer to your arguments about my mental functioning.
I'm not *interested* in your mental functioning. Please can we drop
the stupid discussion about your mental functioning? I'm interested
in sizeof. What is it with you and your mental functioning? Sheesh.
It's like you're proud to have some. Fine, but you don't have to
spread it all over the Net. Obviously you can if you like, but it
makes quite a mess.
> You hold
> certain *opinions* there. They are not "correct" in my opinion,
So what? Your understanding of sizeof is not correct *by
definition*. It isn't a matter of opinion.
<snip>
> And I say you are to stop discussing me in public altogether.
I'm not trying to discuss you. I'm trying to discuss sizeof. But let
me tell you something about *my* mental functioning for a change -
if there's one thing that's likely to make me want to continue to
discuss a subject, it's a demand for me to stop. Is that what you
are trying to achieve? I ask merely for information, and I'm not
overly fussed about the answer anyway, so don't feel obliged.
> Killfile me if you must, but henceforth, please pretend that I do
> not exist.
I'm okay with pretending you don't exist. So - we have this
invisible man who doesn't exist (if I shut my eyes), but this
invisible man who doesn't exist is posting disinformation about
sizeof. How can we solve this problem?
> That means if you see a post by me, it does not exist
> so you will not post a followup. If you hold an opinion about me,
> it does not exist so you will not post mentioning it or implying
> it.
You don't get to control my actions.
> I hope I've made myself clear enough this time.
You don't get to control my actions. I hope I've made myself clear
enough this time.
>>> Don't do that!
>>
>> You don't get to control my actions.
>
> Ordinarily, no, but when your actions include making public
> statements about me, my rights of privacy and publicity enter into
> it, and I say I don't want you discussing me in public.
I'm not interested in discussing you in public. I'm interested in
discussing sizeof. It is you who continually drag the discussion
back to you. I would prefer for you to return to the sizeof
discussion, but it's your call.
> Really, I am none of your business anyway so you have no good
> reason to be doing so;
It is you, not me, who prolong this discussion.
<snip>
>> You don't get to control my actions.
>
> You're missing the point. I am attempting to explain rules of
> polite society to you that apparently you don't get.
When you can learn to stop including expletives in Usenet articles,
I might be open to what you have to say about rules of polite
society. Until then, I don't consider you qualified to speak on the
subject.
> You don't
> keep pressing someone that clearly doesn't want a fight. You leave
> them alone.
I don't want a fight. I want to talk about sizeof.
>> If you screw up
>
> That never happens.
It happened. You got sizeof wrong. That's fine - lots of people do -
but then you screwed up some more by continuing to get it wrong in
the face of authoritative information (relevant quotes from the
relevant technical standard).
>
> If it ever did, then you should certainly not keep aggressively
> poking at someone who is trying to save face.
If you want to save face, contradicting ISO/IEC 9899 is not the way
to go about it.
> That's how big,
> nasty fights start, when someone disrespects someone else's right
> to be left alone.
If you don't want people to respond to your articles, in my
experience the best way to achieve that is not to post them.
Anything you do post is very likely to get discussed, even if the
thing you post is "please don't discuss this". That's human nature
for you.
>
>>> You'll have said
>>> your opinion, they'll have said theirs, and everyone can move
>>> on.
>>
>> You can move on any time you like. Nobody forces you to respond.
>
> Oh, is that what this is about? You keep posting because you have
> a childish insistence on having the last word? How disappointing.
I've already explained elsethread that you can have the last word.
It's "zymotic". I don't need it.
If you want to suppress discussion of a subject you find
uncomfortable, telling people not to discuss it is simply the wrong
strategy.
>
>>> If, instead, you respond by restating your opinion more
>>> forcefully, it starts a fight instead, and nobody benefits from
>>> that.
>>
>> If someone (anyone, not just you) disagrees with a point I've
>> made in an article, either they are right (in which case I'm
>> wrong and I'd like to know about it), or they are not right (in
>> which case it may be worth trying to put things in a way that is
>> easier to grasp)
>
> Insulting. I think you should be thinking "worth trying to put
> things in a way that preserves both sides' dignity", don't you? Or
> does the dignity of other people not concern you?
It was you, not me, who tossed away your dignity.
>
> I'm getting a very disturbing picture here: that you are not
> willing to agree to disagree on any subject, nor do you care about
> preserving the dignity of others.
I think your picture is not so much disturbing as distorted. I am
perfectly willing to agree to disagree on a great many subjects,
but the nature of sizeof is not one of those subjects.
>
>> In this case, you [insult deleted]
>
> I repeat: I am not interested in your opinion of me. Neither is
> anyone else. Don't. Post it. Again.
I repeat: you don't get to control my actions.
>> you didn't seem to see why
>
> I see exactly why you hold your opinion of me.
You don't know what my opinion of you is, because I haven't posted
it. All you are doing is guessing, and mostly you are guessing
wrongly. Rather like your guessing about how sizeof works, instead
of finding out.
> I also don't give a
> shit. My concern is with your *posting that opinion in public*,
> and posting things apparently designed to induce *other people to
> develop the same, negative opinion*. You can surely understand why
> I don't want that happening, particularly the latter part.
What I don't understand is why you get sizeof wrong. Could you
explain your justification for thinking sizeof evaluates its
operand (when the operand is not a VLA)? Note how I continually try
to turn the discussion back to sizeof. Note how you continually try
to turn it back to what it seems to please you to call your mental
functioning.
> What I don't understand is why you seem to be insistent that that
> happen, and that I not be permitted to speak up in my own defense?
Of course you are permitted to speak up in your own defence. That's
precisely what you're doing, and nobody is stopping you, are they?
But you are not being attacked. Your opinion of sizeof /is/ being
attacked. Would you care to defend it, on technical grounds? Note
how I try to steer the discussion back to technical matters. Please
help me out here.
> Really, I just want to be left alone.
Would you prefer it if nobody responded to your articles? Do you
think Usenet is your personal blog? Well, it isn't. If you post
stuff, people will very often respond, and you don't get to choose
the way in which they respond. Now can we get back to talking about
sizeof?
> If, after this post, you continue to harass me,
I'm not trying to harass you. I'm trying to discuss sizeof.
> I will have to
> conclude that your purpose is in fact to start a fight. There is
> no other explanation for someone posting an attack post in
> response to "I just want to be left alone", after all.
I am *not* attacking you. I am discussing sizeof. All this
discussion about *you* is a side issue that I would prefer to drop,
but not at the expense of giving in to what I perceive to be
attempts at coercion.
>
>> I have even now not made it clear enough (although the middle
>> part of this reply is another attempt).
>
> Your opinion is crystal clear. I hope by now so is mine: I do not
> want you to make yours even clearer. I want you to drop the
> subject and leave me in peace.
The subject is sizeof, and your misunderstanding of it. I can hardly
pursue the subject if you won't tell me your justification for your
interpretation of sizeof's behaviour.
>>>> I described your argument as a strawman argument because
>>> you're an asshole. Yes, yes, I know.
>>
>> Selective quotation
>
> Please do not change the subject.
Firstly, pointing out debating tricks is a valid part of debate.
Secondly, it was you who changed the subject. You changed it from
sizeof (which is topical) to you (who are not topical). Let's get
back to sizeof.
>
>>>> your flawed understanding
>>>> led you to believe, mistakenly
>>> Stop personally-attacking me at once.
>>
>> Firstly, I'm not personally attacking you.
>
> Yes, you are.
No, I'm not.
> You are publicly calling my intelligence into question. That is
> an insult.
No, it isn't. Intelligent is as intelligent does. You are not
behaving in a way that I associate with high intelligence, and that
is bound to colour the way I react to you. But if I say that I am
revising my opinion of your intelligence downwards, I am not
insulting you, merely describing my opinion of you. (And if I were
to say that I believed you to be highly intelligent, again that
would be merely a description of my opinion of you; it would not be
praise.)
> It's the same as if you posted
> "Seamus MacRae is an idiot" on the billboard at Times Square.
No, it isn't. Firstly, this is a forum in which it is easy to
respond. If I did as you described, it would be impractical and
possibly even counter-productive to put up another poster saying
"no he isn't". But on Usenet, it is quite common to see point and
counter-point being discussed. In any case, on balance I suspect
that you are probably not an idiot in the medical sense of the
word, so the analogy is wrong even in that respect.
> How would you like it if someone put "Richard Heathfield is an
> idiot" on there?
If you posted such a comment on Usenet, you would not be the first.
And I would not react by trying to stop you from posting. Instead,
I'd try to find out why you thought I was an idiot, and then I'd
explain why it wasn't the case. What I would not do is lose my
temper or get hysterical.
> I'm guessing you wouldn't.
I wouldn't particularly revel in it, no, but on the other hand I'm a
grown-up and able to take care of myself in a discussion without
having to resort to trying to shut the other guy up (which never,
ever works).
> Please let this entire matter just drop, for both of our sakes.
If you mean the matter of sizeof's operand, I would just like to
point out at this stage that (VLAs aside) it is not evaluated.
>> I am having a discussion on Usenet.
>
> You are discussing a person in public without that person's
> consent. That is a no-no.
Very little is a no-no on Usenet, but it is you who are discussing
you in public. I'd like to discuss sizeof, please.
>> Secondly, I am sure you would agree that you are wholly
>> entitled to make your own choice about whether to take part in,
>> or to withdraw from, this discussion.
>
> Then I choose to withdraw from it, by which is meant my name will
> not appear any further in it, which in turn means you do not talk
> about me and you do not follow up to one of my posts.
You don't get to control my actions. You get to control *your*
actions.
> Is that clear?
Your opinion is clear enough. What isn't clear is how this relates
to sizeof.
> Otherwise, I am "taking part" by being mentioned or quoted in it,
> against my will and in violation of that very entitlement that you
> just admitted I possess.
You get to choose what you do. Other people get to choose what they
do. That's how it works.
>>> You will not again use the
>>> words "flawed" or "mistaken" to describe me in public. Do I make
>>> myself clear?
>>
>> You make yourself perfectly clear, but [insults deleted]
>> You don't get to decide what I write.
>
> Fuck you.
Big talk, huh? That's either 3-0 or 4-0 now. Why not talk about
sizeof instead?
> Obviously, you understand me perfectly and are explicitly refusing
> to leave me alone.
No, I'm exercising my right to post to Usenet because I want to
discuss the semantics of sizeof.
> Fine. If you want a fight, let's fight.
>
> Your mother is so fat, she is required by law to wear a "wide
> load" sign and beep when she backs up.
Actually, my mother (who was, if anything, too thin rather than too
fat) died last year in a house fire.
Note that my response to your attempt at humour is to point out why
it's wrong. In theory I could prove the above statement (the
inquest was held last week - there is no point in asking me why it
took so long to come around, because I don't know the answer - and
I will shortly be getting a copy of the Coroner's report), but in
practice I would demur on the grounds of taste and just trust that
those of an independent mind are prepared to believe my statement
in the absence of a reason not to.
> Your turn.
Let's get back to sizeof, shall we?
>
>>> Leave. Me. Alone.
>>
>> If you don't wish to communicate with me, you can stop doing so
>> at any time.
>
> I don't wish to be communicated ABOUT in public by you.
Fine. I don't wish to pay tax. But we don't always get what we want.
As it happens, however, I'm not overly excited about the prospect
of communicating about you either. Let's get back to sizeof, shall
we?
>
>>> These newsgroups are for discussing programming, not people. I
>>> am off-topic here.
>>
>> I agree
>
> Then stop talking about me!
You don't get to control my actions.
>> sizeof *is* topical, and that's what I'm discussing.
>
> Get real. This stopped being about "sizeof" several posts ago when
> you decided to make things personal.
So you claim. But I disagree. I think it's about sizeof.
>> All this extraneous guff is just a side issue.
>
> All this "extraneous guff" is what actually matters to me. If you
> consider it a mere "side issue" then that's another reason for you
> to drop this thread and move on -- topic drift has taken it
> outside of your area of interest.
I'm very ready to drop all the personal stuff and get back to
sizeof. Are you?
>
>>>>>>>> I've worked in environments like that, and found it quite
>>>>>>>> workable.
>>>>>>> Now I know why so much C software is crash-prone and
>>>>>>> generally buggy.
>>>> Spot the (groundless) personal attack, to which I reacted.
>>> There was no personal attack in my post.
>>
>> That's called "special pleading".
>
> No, it's called pointing out that insulting software is not
> insulting a human being, and therefore is not a personal attack.
No, it's called "special pleading". Your claim is that your personal
attacks are technical arguments (or "insulting software" if you
prefer), but that my technical arguments are personal attacks. In
other words, you're being asked to be treated specially because
it's you. That's special pleading, and it's a shabby debating
trick.
> For it to have been a *personal* attack it would have had to imply
> something negative about some specific *person*.
Even granting for the sake of argument (and without prejudice to
future dispute) that this definition is correct, how is my
explanation of sizeof a "personal attack"?
>>> Saying that environments
>>> that ignore a lot of compiler warnings generate buggy code is
>>> not an attack on any particular person.
>>
>> Who said anything about ignoring compiler warnings?
>
> You did.
No, I didn't. Learn to read for comprehension.
<snip>
>
> Fuck you.
Is that five?
> I've had it with you. You pretend to some kind of civilized
> character but your real objective is simply to go around
> badmouthing anyone you disagree with,
No, my objective in this subthread is to discuss the semantics of
sizeof.
> have the last word in any
> discussion, and generally shove your weight around. How old are
> you, about three?
Even older than three. In fact, I'm all gwowed-up now, and I have
learned all about not swearing in public forums and stuff like
that. I didn't used to be able to spell "adult", and now I are one.
How about you?
>> (a) it's impossible to satisfy every compiler, and code that is
>> required for eliminating a warning on one compiler may itself
>> cause a warning on another; therefore, a clean build is not
>> actually possible in the general case for non-trivial code that
>> must build on multiple compilers;
>
> Doesn't follow. Ever heard of #ifdef and its friends? Conditional
> compilation means being able to satisfy multiple compilers, and
> produce more portable code.
The cure is worse than the disease, because you now have multiple
branches to maintain. Stupid stupid stupid. I cannot believe you
are seriously proposing that.
<snip>
>>>> For someone who doesn't like personal attacks, you sure like
>>>> making them.
>>> No, I do not. Stop publicly lying about me.
>>
>> Well, it wasn't a lie, but it's possible that I was mistaken to
>> claim that you enjoyed making personal attacks.
>
> That you were.
I am prepared to accept that.
>> Nevertheless, you have clearly made them.
>
> I have *now*,
You started way back.
> when you continued to publicly badmouth me. You
> asked for it, you got it. Now, are you ready to quit, or are you
> thirsty for more?
I'm ready, as ever, to discuss sizeof. Are you? Or are you
determined to follow your self-destructive path?
>>>>> You've said your piece and I've said mine. Move on.
>>>> I'm already in the right place.
>>> NO. YOU ARE NOT.
>>
>> I respectfully disagree.
>
> Respect? That's a joke. You've shown no respect for my wishes, for
> my boundaries, or for any of the three newsgroups' topic
> boundaries, at least thus far.
I have tried to show restraint and respect, and I think I have
succeeded far more than you. As for the topic, as far as I'm
concerned the subject of this discussion is sizeof, which you
continually try to avoid in favour of extraneous waffle about
personalities.
>>> You've said your piece. It does not bear repeating.
>>
>> Am I right to interpret this as "Seamus is not interested in
>
> You are right to interpret this as "Seamus is not interested in
> continuing this discussion, or in being the subject of any
> discussion in which you participate".
Then the solution is easy - you can simply killfile me, in which
case I suppose we'll never learn why you misunderstand sizeof.
>
>>> MOVE ON.
>>
>> I'm already in the right place.
>
> No. See above.
Your failure to understand my statement does not make my statement
incorrect.
>>> Calling me a liar will not make me friendlier.
>>
>> I don't believe I've called you a liar.
>
> Implied it, at any rate.
No. You may have inferred it, but I have not implied it. I am happy
to accept that like everyone else I am sometimes a little careless
with words, but I am *very* *very* *very* careful not to call
people liars unless I can prove it beyond a shadow of a doubt.
Therefore, I have not called you a liar, and will not call you a
liar unless I can prove it 100%, by which I mean that unless I can
demonstrate that you have given false information while *knowing*
it to be false I will not call you a liar.
The fact that you infer that I've called you a liar is mildly
interesting, but not interesting enough to talk much about. I'd
rather talk about sizeof.
<snip>
>> Irony is always dangerous.
>
> So is a complaint to your internet provider for flooding three
> newsgroups with offtopic drivel.
I am trying to discuss sizeof, not offtopic drivel. By your
reasoning, I should be complaining to /your/ Usenet provider. But I
won't. I reserve complaints for spammers and flooders (major
abuses, which ISPs normally ignore no matter how many complaints
they get).
>>>> Okay, so I'll retract "buffoon" - but for heaven's sake,
>>>> lighten up a little
>>> After you.
>>
>> I'm not the one who introduced expletives into the discussion.
>
> You are, however, the one who introduced rudeness, personal
> innuendos,
I don't think so.
> and an unwillingness to leave things alone.
Like sizeof, you mean?
>
>> Nor will I sink to your level
>
> My God, are you really trying to claim the moral high ground now?
Why would I need to do that? I'm already standing on it. And it's
called ISO/IEC 9899. And you haven't even begun to construct a
sound technical assault yet.
But I know what you mean. When you can learn to stop swearing in
public, then we'll talk about moral high ground if you like.
> How utterly ridiculous. It's never available at any price to the
> guy that shot first, so you can give up on that idea right quick.
My first "shot" as you call it was a technical correction to a
mistake you made about sizeof. So was my second. And my third. If
you think that people who correct mistakes always lose the moral
high ground by so doing, then your idea of "moral high ground" is
just bizarre.
>
>>>> and before "correcting" people, take the trouble
>>> to send it as private email rather than a public news post?
>>> After you.
(At this point, it is necessary to point out that, at the beginning
of his article to which this is a response, Seamus MacRae wrote (or
more likely his news software wrote, but he left it unaltered in
his reply) the words "Richard Heathfield wrote:". He (or, again,
more likely his newsreader) marked off all that quoted material
with a single chevron. In cases where he was quoting quoted
material, that material would appear with multiple chevrons, the
number of which indicate the depth of the quote. I have done the
same, so my material in this article appears either without
chevrons or set off by two chevrons, and Seamus MacRae's material
is set off by one chevron. So it is clear that, by writing or
allowing his software to write "Richard Heathfield wrote" and then
following it with this material (one extra chevron because I'm
quoting the quote, but in his original article it appeared with one
chevron), he is ascribing that material to me.
>>
>> It's more cost-effective to xxx in a public article than to send
>> emails to every single subscriber.
That is a lie. I wrote no such thing, and you know that I wrote no
such thing. What I wrote was "It's more cost-effective to explain
the semantics of sizeof in a public article than to send emails to
every single subscriber."
Remember I just said I would never call you a liar without being
able to prove it? Well, I just proved it. The original text is
available in <································@bt.com> but you have
edited "explain the semantics of sizeof" to "xxx". That's unmarked
editing, so that what you claim I said is not what I actually said,
and it's clearly not accidental, and therefore it's deliberate, and
that makes it a lie, and that makes you a liar. I will not initiate
legal action over this (because I'm not that sad), BUT if you sue
me for libel for calling you a liar, I am quite confident of
victory and I *will* counter-sue.
<snip>
> Anyway, I guess it's now your move. Will you decide to leave
> things be, and consider this match a draw,
It's not a match. It's about the reality of sizeof's semantics. This
isn't a competition. It's a flaw in your understanding of sizeof.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h06djv$nti$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> Richard Heathfield wrote:
>>>>> I am less concerned with attacking you than with debunking
>>>> I do not need "debunking", thank you very much.
>>> Right
>> Then please drop this.
>>
>> NOW!!!
You forgot to drop it. Sorry, please hang up and try again.
> [numerous insults deleted]
You are in error about me.
>>>> Next time, do not "debunk" unsolicited.
>>> If you don't wish for mistakes in your articles to be corrected,
>>> you have two choices - (a) don't make mistakes, or (b) don't post
>>> them.
>> I go for option (a), always.
>
> [calls me a liar]
You are in error about me.
>>> I make mistakes in my articles - and they /do/ get corrected,
>>> and I'm pleased by that, because it means I get to learn stuff,
>>> which is good, right?
>> Are you unconcerned with how you are perceived? I'd think you'd
>> rather not be publicly humiliated and made to look like an idiot.
>
> [insult deleted]
You are in error about me.
>> If that's not the case, though, it might explain your boorish
>> behavior here, where you seem unconcerned for the risk that your
>> actions will have that sort of effect on someone else. If, for
>> some strange reason, you wouldn't mind it yourself, then perhaps
>> it just didn't occur to you that someone else *would* mind.
>
> It didn't occur to me that anyone would object to learning something
The problem is the thing you apparently want to teach to the world:
"Seamus MacRae is an idiot". It is, of course, incorrect, and
furthermore I clearly have a vested interest in opposing your so-called
"education campaign".
>> Well, now that you're aware of the possibility, you should know to
>> just quietly move on now.
>
> This is Usenet. I don't have to move anywhere.
Yes, you do. Have you forgotten that whether or not Seamus MacRae is an
idiot is irrelevant to all three newsgroups you're spewing your crap
into? And your occasional asides about C are irrelevant to two of them.
> What do /you/ mean by the metaphor "move on"? Do you mean "quietly
> forget that Seamus MacRae [insults deleted]"
I mean stop posting about Seamus MacRae. Period. Do not mention me
again, in public, indirectly or directly, ever again. You have made your
opinion quite clear and stated it for the record. I have made mine clear
and stated it for the record. Clearly neither of us will budge from our
respective opinions. Therefore the only question left to decide is how
many times we'll each repeat ourselves before you eventually give up on
your ambition of having the last word. One more? Two more? A hundred more?
Come on. Give it up. It's not worth it.
> I'm prepared to do that.
Then by all means, do it already!
> I don't respond well to threats
I am only responding in kind after your own implied threats to continue
loudly broadcasting your unwelcome opinion of me in public.
>>> I think you're confusing
>> I am not.
> Then you must be confused.
I just told you: I am not.
>> I am also not interested in entertaining any more public
>> speculation about my mental functioning.
>
> Fine
Then by all means, please do shut up about me now.
> I used the word in passing (in what I consider to be a legitimate
> way
There is no "legitimate way" to call a stranger an idiot loudly in a
print medium.
> So it seems to me that you are interested in precisely that
> subject.
To the extent that I'm interested in publicly correcting the erroneous
and hostile statements that have been made about me, for the obvious
reasons, yes. I'd much rather not have to though.
> I'm not. I'm interested in sizeof.
I'm not.
>> Drop it.
>
> You don't get to control my actions, remember?
Are you threatening to publicly badmouth me some more? Do I need to get
a lawyer involved in this?
>> Now.
>
> I get to decide what I do and when I do it, remember?
Are you threatening to publicly badmouth me some more? Do I need to get
a lawyer involved in this?
>>>> Regardless, it's been drilled in repeatedly: if "*foo" is
>>>> encountered when foo is uninitialized, Bad Things may happen.
>>> Sure - but this isn't *foo; it's sizeof *foo
>> Which contains *foo as an argument, for heaven's sake.
>
> No, it doesn't.
Yes, it does. We have an occurrence of the structure "operator
argument". This is clear to anyone that isn't blind.
> I know from experience that you don't take a lot of notice of proof
I don't take a lot of notice of flawed arguments purporting to prove me
an idiot, you mean. Because I know for a fact that I am not an idiot.
> but here it is anyway. It proves you [insults deleted]
Fuck you, liar. I am not an idiot and no amount of "proof" otherwise
posted by you will change that fact. The only thing you're proving is
that you're an asshole.
>>>>> You missed my point.
>>>> No, I did not.
>>> Yes
>> No, and this is not negotiable. I do not miss points.
>
> You don't get to control my actions.
You are now arrogantly claiming to have the power to MAKE me have missed
a point by FIAT? How ridiculous.
> You have snipped the explanation I gave of why I considered you
> to have missed my point.
Because I was not interested in it. Your conclusion was a negative
statement about me and therefore could not possibly be correct. It
follows that the reasoning that led you to that conclusion was flawed. I
have little interest in the details of your flawed reasoning, because at
this point I doubt that analyzing it and pointing out the error would
lead you to reverse your opinion of me, or convince you to stop
broadcasting it. Only the danger of your own reputation being dragged
through the mud now seems likely to deter you from doing so.
>>> If you are prepared to limit yourself to systems that use
>>> IEEE754-compatible floating point systems, that's your decision
>>> to make.
>> Since that's the vast majority of systems in present-day use, it
>> doesn't seem to be a biggie.
>
> Things change.
The more things change, the more they stay the same.
>>>>> Fine, you're entitled to think that
>>>> Don't patronize me.
>>> Firstly, I told you before
>> I said, don't patronize me. And what's the next thing you do?
>> Patronize me!
>
> Firstly, no, I wasn't patronising you
Yes you were. Twice. "Fine, you're entitled to think that" is
patronizing, holier-than-thou, know-it-all bullshit. "I told you before"
is equally rude.
> I was explaining to you.
I do not need, or desire, any "explaining to" by you. It is patronizing
and rude, not to mention incorrectly implies negative things about my
intellect.
> Secondly, just because you tell me to do something (or refrain from
> doing something), that doesn't put me under any obligation to obey
> you.
No, the rules of polite society, the terms of service of your ISP, and
the charters of these three newsgroups put you under the obligation to
stop posting these off-topic character assassinations to these three
newsgroups.
>> Fuck off. You are clearly a complete waste of bandwidth and
>> congenitally incapable of remaining polite or civil.
>
> You are the one
No, you are the one who first resorted to namecalling and personal
attacks in what had up till then been a technical discussion.
>>> I'm still treating you like an intelligent man
>> Ordinarily, one does not treat intelligent men as shoddily as
>> you've treated me.
>
> [calls me an idiot]
No, I am not. You, however, are a liar.
>> In particular, when an intelligent man requests
>> that you drop a condescending tone,
>
> I haven't even reached for my condescending tone during this whole
> conversation so far.
Another lie, and calling me a liar to boot.
>> or drop an entire line of questioning,
>
> I haven't /had/ a line of questioning.
You have been questioning my intelligence, in public, practically from
day one. I posted a harmless little aside and then you, who had never
even met me before and had no prior involvement in this thread, jumped
in and called me an idiot. Something is obviously the matter with you,
but I'm damned if I know what, exactly, it is.
> I've pointed out a mistake
You've attacked me, viciously and without provocation.
I. Do. Not. Make. Mistakes.
Stop lying about me in public.
> You are the one who is prolonging this discussion
No, you are. If you stop posting, this discussion ends after only a few
more rebuttals by me.
I on the other hand don't have that choice because I must correct all
erroneous public statements made about me, for obvious reasons.
> Each time you post anything that amounts to such a claim, it's a
> mistake
No, it is not. The mistake being made here is to continue picking on me,
and that mistake is being made by YOU.
> [insults deleted]
The mistake being made here is you continuing to pick on me. I just want
to be left alone. AFTER rebutting all outstanding insults posted about me.
You are demanding the last word, pretty clearly insisting that the final
post in this thread must be by you, insulting me. But that is something
that I cannot allow, and it is something that it's entirely within my
power to prevent, so you can just give up on that goal right now.
>> then unless you are a police interrogator and he is a
>> murder suspect, you do so! Any other behavior is extremely
>> impolite.
>
> Do you consider swearing to be extremely impolite?
I consider you to be extremely impolite, and politeness to be wasted on
you. I tried politeness on you, setting an example and all that, and all
I got in return was more public beratings from you. Obviously, then,
time to try a different tack.
> And you are losing 2-0
I am not losing anything. What are you hopped up on, anyway?
>>> That opinion, however, is beginning to change.
>> Is that a threat?
>
> [numerous vicious insults deleted]
All lies, of course.
I am quite intelligent. Intelligent enough not to waste my time with a
point by point rebuttal of your latest outpouring of vitriol, or to give
it any extra air time by quoting it all verbatim for that matter.
I have tried already to explain to you why a) you are wrong about me and
b) I am not interested in "learning" your insulting "curriculum" but you
are apparently unwilling to listen to my explanations.
>> Actually, I frankly don't care about your opinion of me,
>
> Neither do I.
Then please do shut up about me.
> But I /do/ care about the public understanding of sizeof, which is
> what I'm trying to discuss in this thread and which you appear to me
> to be making every effort to avoid discussing.
I am not interested in discussing it, or anything else, with you. I am
interested in one thing and one thing only: setting the record straight
about my intelligence, which you have, incorrectly, publicly slurred.
Your behavior indicates that you object to my setting the record
straight. That immediately brands you a liar and a muckraker, or
something like it, and puts the lie to your claimed motives, above.
If you really want to discuss sizeof, why not find a willing partner and
go discuss sizeof with him? Leaving my name out of it, of course.
That you insist instead on following up to my posts and casting
aspersions about me proves that your claimed motive is a lie.
> You are devoting far more typing to your reaction to ... my opinion
> of you than you are to the actual subject at hand.
Because the "actual subject at hand" clearly IS your opinion of me, and
also because the various opinions about me are the only part of this
that continues to interest me. Clearly, I cannot just sit idly by and
watch you tell the whole world what an idiot I supposedly am, hence my
replies, which are not actually meant for your consumption at all, since
your opinion is clearly entrenched, but are meant instead for the
benefit of everyone else, who might otherwise be misled by your
erroneous statements about me.
>> just so long as you don't broadcast it loudly but keep it to
>> yourself as a polite person would.
>
> By prolonging the discussion of your behaviour, you are making its
> continuation more likely.
This discussion is not about my behavior, it is about your opinion of me
and why you should keep it to yourself.
And I don't care for your threatening tone. What you just wrote amounts
to: "If you post defending yourself again, I will post attacking you again".
I have every right to defend myself when publicly slandered, and you
have no right to threaten me for doing so. Do I make myself clear?
> If that's what you want (despite what you
> say), fine. If it's not what you want, you might want to consider
> what effective action /you/ can take to stop it.
Well, let's see. If I remain silent, you will be free to go on
blathering your nasty lies about me unopposed, eventually convincing the
world that Seamus MacRae is an idiot, and who knows what other nasty
things, so that none will have anything to do with me.
Clearly, that is a bad move on my part. It hands you victory on a
platter. So I must post something.
What, then? Obviously I should rebut the erroneous claims you make about
me, for starters. The problem is, when I do that, it seems you insist on
posting another bunch of erroneous claims, so I'll be at it till
doomsday. Which means I also have to shut you up somehow.
That can proceed by one of two ways: I convince you to shut up, or I
force you to shut up. Apparently I can't convince you to shut up. So I
guess I'm going to have to have a little chit-chat with the abuse
department at your ISP. What about? Well, there seem to be quite a lot
of off-topic posts in several comp.* newsgroups lately, and Richard
Heathfield seems to be the author of dozens of them ...
Failing that, I guess I'll have to get lawyers involved.
>>>> Please go look in a mirror and adjust that attitude you're
>>>> wearing.
>>> "Please" is a good start [rest of patronizing crap deleted]
>
> 3-0.
What's that, the PONG score in your game with your imaginary playmate?
> But what I said was not patronising. It was a carefully measured point
It was a vehicle for more lies and personal attacks.
> If you want a civil discussion
I'll settle for silence.
> you are going to have to work at it by being civil.
After you.
> [calls me a liar]
You're the liar here.
>> Either discuss the original subject matter or remain silent
>> please.
>
> I'm trying to discuss the original subject matter
You are not. Otherwise you would have no objections to discussing the
original subject matter WHILE LEAVING MY NAME, and your opinion of me,
OUT OF IT.
If you really have no such objections, then please start doing so
immediately.
> you seem remarkably reluctant to contribute
I lost all interest in it when it turned into a vehicle for personal
attacks instead of a neutral, impersonal technical subject.
> which is why that part of the conversation is all but dead,
> despite my attempts to keep it going.
If you want to revive it, revive it *without* my name being involved, or
any implications about my intelligence (or any other traits of mine)
being made.
> You seem determined to prolong all this extraneous discussion about
> *you*
Not really. You seem to think that my posts are replies to yours.
They're not. They're public bulletins pointing out the errors you have
made about me, in the interests of sparing the public (and myself) any
bad consequences of the misinformation you have spread about me. I'd be
quite happy if you didn't even see my posts now.
> which I find terribly tedious
Then please drop the subject.
> and which I'd be as happy to drop if only you would stop making all
> these ridiculous claims.
These "ridiculous claims" are me defending myself when publicly
slandered. And no, I will not stop defending myself. You have made a
very childish demand above, basically "stop blocking me and let me hit
you! Then I'll go away."
Yeah, right. If I stop defending myself, you'll think "sitting duck" and
go for the throat, more likely.
Regardless, basically insisting that you'll keep pulling my hair unless
I say "uncle" proves your juvenile temperament, and probable
single-digit age. And it likely destroys your credibility pretty
thoroughly as well, which, given the nasty and false statements you've
been publicly making about me, suits me just fine.
>>>>>> Do not personally attack me or accuse me of intellectually
>>>>>> dishonest behavior again. You have been warned.
>>>>> It wasn't a personal attack
>>>> Like hell it wasn't. You publicly berated me
>>> Actually, I
>> Actually, I'm not interested in your explanations or excuses.
>
> That reaction leads me to suspect that you're not interested
I'm not interested in debating my intelligence, or alleged lack thereof,
no. I'm only interested in asserting that my intelligence is (at least)
normal. There is no room for compromise here, except perhaps in the
upwards direction.
>> I'm interested in two things:
>>
>> 1. Shutting down this unwelcome and off-topic inquiry into the
>> status of my mental functioning, and
>
> But I have made no such enquiry.
You have too, liar.
> It is not I who turned this discussion of sizeof into a slanging match.
A ridiculous claim, when your very first post in response to any post of
mine was a slap right across the face. You do know that Google Groups
archives your posts, right, and that it's easy for anyone to verify that
your first post was a slap? I have to ask, because you seem to think
that maybe you can somehow fool people into actually believing you
didn't start the slapping match.
>> 2. Getting an apology, if one might be forthcoming, though I will
>> settle for complete silence instead.
>
> You certainly won't get an apology, because I don't make a habit of
> apologising for being right
But you were entirely, 100% wrong about me.
> continuing to make a noise is not the right way to achieve complete
> silence, so why do you continue to post?
To correct, for the public record, the erroneous statements that have
been made about me. As I already told you several bloody times.
>> Shall I repeat what I just said? About the unwelcome nature of any
>> further public inquiry into my mental functioning?
>
> You can if you like, but it won't make any difference to your
> misunderstanding
I understand you perfectly. I just don't agree with your opinions about
me, nor will I let you broadcast them loudly and publicly without
opposition.
>> I understand perfectly.
>
> And yet you [numerous insults deleted]
As I was saying before I was so rudely interrupted, I understand you
perfectly. I just don't agree with your opinions about me, nor will I
let you broadcast them loudly and publicly without opposition.
>> I do not, however, agree with your stated
>> opinions of me, and I will not ever agree with them.
>
> I can live with that.
Then why do you insist on rebroadcasting those opinions every time I
publicly challenge them?
> [implies something stupid]
No, I'm not wrong about your opinion of me, either. Your attempts to
publicly impugn my intelligence are futile. For every attack post, there
is an equal and opposite rebuttal post. You're on a treadmill going
nowhere fast. Ready to stop yet?
>> You cannot gain anything by continuing this.
>
> All I am continuing is a discussion of sizeof in a programming
> forum.
Nonsense. I've already explained, above, why that cannot actually be
your motive, despite your claims.
> If you wish to partake in that discussion, you are free to do so.
I do not.
> If you don't, why do you still post?
To correct the errors in the public record regarding my intelligence.
> Again, that's your decision, but it does seem to be rather an odd
> decision.
Not really. If someone suddenly started telling half the world that you
were a moron, wouldn't you take some sort of corrective action rather
than let such propaganda circulate unopposed? People told one thing
repeatedly will tend to eventually start believing it unless they also
come across conflicting messages.
>> If you drop the subject now, we both walk away and get on with our
>> lives.
>
> The subject is sizeof.
The subject is your opinions of me. I couldn't care less about sizeof at
this point.
> I don't know why you continue to introduce extraneous material
I don't. You do, by constantly attacking me personally instead of making
nothing but sober, my-name-left-out-of-it,
nothing-implied-about-me-indirectly-either statements of a technical
nature about sizeof.
> but I would prefer it if you didn't do that.
That's my line.
> And I have no intention of dropping the sizeof subject at this time
I'm not asking you to. I'm asking you to drop the Seamus MacRae subject
at this time. That is, to stop mentioning me, quoting me, or saying or
implying anything about me.
>> If you continue to publicly insinuate various unpleasant things
>> about my mental functioning, you will be in for a world of shit.
>
> Firstly, what you infer is your responsibility, not mine. I have
> actually said very little about you in this thread,
but implied a great deal.
>> You'll get at least as good as you give
>
> When, for pity's sake? So far, I've been giving great stuff on
> sizeof
You have not.
> and all I've had back is this personal stuff, which I don't
> want and don't care about.
If that were true, you'd stop casting aspersions about me and stick to
the original topic, wouldn't you?
> What I'd like is to find out your technical justification
No. I no longer have any interest in discussing the subject with you,
because I expect it will only encourage you to cast even more aspersions
in reply.
>> and will likely lose your usenet access in the bargain.
>
> That isn't going to happen, for at least two reasons:
>
> 1) I haven't done anything wrong, as the record will show;
You have posted a large number of off-topic posts to at least three
Usenet newsgroups.
> 2) Nowadays, ISPs mostly don't care anyway, not even about spam -
> they should, but they don't.
Well, let me enlighten you:
INTRODUCTION - ACCEPTABLE USE POLICY (AUP)
INTRODUCTION
For the Internet to operate in a manner that satisfies the majority of
its users, all users need to observe some rules and behaviours governing
their use of it. These requirements are usually contained or referred to
in the relevant terms and conditions governing the particular Internet
service as well as the law.
To enable its customers to have a better understanding of what is and is
not acceptable when using the Internet, and to help you get the best out
of the Internet, BT has developed a number of Acceptable Usage Policies.
These policies should help you benefit from safer surfing and minimise
the risk of suffering "online abuse".
We have also included some general advice on how to protect you and your
computer to each of these policies which we encourage you to follow.
Illegal and inappropriate activities
As an Internet user, whilst connected to the Internet via BT you must
comply with the relevant laws that apply in the UK. You should also be
mindful of the fact that the Internet is a global medium and is
regulated by the laws of many different countries. Material which is
legal in this country may be illegal in another and vice versa.
These are some of the things that you must not do whilst connected to
the Internet:
You must not, by using the service, download, possess or transmit in any
way, illegal material (for example indecent images of children).
You must not send, publish, distribute, circulate or otherwise propagate
any material that may be deemed to be grossly offensive or of an
indecent, obscene nature or menacing in character.
[So far you haven't posted anything that rises to the level of
"menacing", though you have sometimes been childishly threatening in a
definitely non-menacing way.]
You must not send, with the intention of causing annoyance,
inconvenience or needless anxiety a message that you know to be false,
or to cause such a message to be sent
[Bright-line violation here.]
or to persistently make use of our service for that purpose.
[And here.]
You must not gain or attempt to gain unauthorised access to any computer
systems for any purpose, including accessing the Internet.
You must not, without authorisation intentionally impair or attempt to
impair the operation of any computer, prevent or hinder access to any
program or data held in any computer or to impair the operation of any
such program or the reliability of any such data (this could include
deleting files, changing the desktop settings introducing viruses etc.).
You must not infringe the rights of others, including the right of
privacy and copyright (an example would be sharing without permission of
the copyright owner protected material such as a music or video file).
[Arguably, posting about me publicly after repeated requests to stop
violates my right of privacy.]
Many of these activities could result in legal action, a fine or a term
of imprisonment or both.
If you are in any doubt as to the legality of anything, take independent
legal advice before proceeding.
BT�s obligations
BT is obliged under the Regulation of Investigatory Powers Act to
disclose information to Law Enforcement Agencies and Public Authorities
that are legally entitled to obtain such information. Similarly BT must
comply with court orders to disclose information. In serious instances
of abuse we may also notify the police or relevant law enforcement agency.
BT cannot and does not monitor content of its� customers webspace or
content of chat rooms, instant messaging, email, newsgroup or indeed of
any communications and therefore BT cannot and does not guarantee that
all of these are free of illegal material or other content considered
unacceptable by others including the Internet community.
Changes to the Acceptable Use Policies
We may change the Acceptable Usage Policies� from time to time and will
inform you on this website when we do so. To make the most of the
guidance contained in the AUPs, please keep up to date with changes and
look at them on a regular basis. We hope you will find them useful and
informative.
Please note that our AUP's were last updated in [December 2006].
Breaches of Acceptable Use Policies
Reports of breaches of these acceptable use policies by BT customers can
be sent to ·····@btbroadband.com
[On its way already.]
BT may operate systems to ensure compliance with these acceptable use
policies, including without limitation network scanning and testing of
open servers and mail relays.
>> It's your choice.
>
> I choose to discuss sizeof
Yet you did not.
>>>> and implied in front of a large audience that I was stupid
>>>> and/or incompetent.
>>> No
>> Yes. Publicly insulting me was bad enough. Now you have the gall
>> to lie about it?
>
> Pointing out that you are [insult deleted]
I am not.
> is not the same as saying you are stupid or incompetent.
Sure it is. It implies that one or the other must be the case.
> Nor do you get to decide what I imply.
I'm not deciding what you implied. I'm just making an observation about
what you implied.
> If you wish to infer in front of a large audience that you are stupid
I have done nothing of the sort, and the mere insinuation otherwise is a
lie. In fact, I have strenuously *denied* being stupid.
>>>> What the hell is the MATTER with you?
>>> Nothing, really. What is the matter with you
>> Nothing. And that is final.
>
> Except that [insult deleted]
No.
>> I am not interested in discussing or negotiating or anything like
>> that. My stance regarding my own mental functioning is firm, and
>> you will not budge it. You will only let yourself in for a nasty
>> and pointless flamewar if you insist on continuing to poke into a
>> subject matter where you have been warned repeatedly now that
>> you're not welcome.
>
> I'm not *interested*.
Then *stop*.
> I don't know why you think I am.
Because the vast bulk of each of your ridiculously-long posts consists
of casting aspersions about me in public, that's why!
>>>> And with several other people in these newsgroups?
>>> "It was a terrible parade. [rest deleted]
>> Parades are not on topic here.
>
> The comment was relevant to the discussion.
It was not. Parades have not been the topic of this discussion at all.
Indeed, I believe yours was the first mention of parades in this entire,
thousand-post-plus mess of a thread.
> [calls me a liar]
No, I'm not one of those, either. You are.
>>>>> You are taking this far too personally.
>>>> That isn't for you to decide.
>>> True enough. I will rephrase. I *believe* you are taking this far
>>> too personally.
>> Irrelevant. If I say I don't welcome a continued discussion of me
>> in public, then the subject is closed, whether or not you would
>> mind if our positions were reversed.
>
> If you think the discussion is closed, why are you still
> contributing to it?
Because you forgot to shut up about me, and your latest erroneous
statements about me require public correction.
>> When it's your mental competence that's being discussed in public,
>> then it's your turn to decide the same things.
>
> I'm not interested in your mental competence.
Then let the topic drop already!
>> Fair's fair.
>
> It doesn't say fair on the box.
This, too, is childishness. You are basically saying you will do
whatever you please, fair or not, simply because you believe you can get
away with it. That is not the behavior of a civilized, mature adult. It
is the behavior of a child, or a sociopath.
> If you're looking for some kind of resolution, there probably won't
> be one
Is that a threat? Or just you childishly insisting on having the last
word yet again.
>>>>> This is a discussion, not a lawsuit.
>>>> It's not a polite discussion, and it hasn't been since you
>>>> started making things personal.
>>> It could be polite. I am doing my best to remain polite, and I
>>> think that mostly I'm succeeding.
>> You're not succeeding.
>
> [lies deleted]
You were impolite from the moment you butted into this thread and called
me an idiot to my face.
>>>> You made several nasty errors:
>>>> 2. Then when I responded to smooth things over,
>>> I don't recall your trying to smooth things over.
>> Yes. In <································@bt.com> you nitpicked
>> me,
>
> [calls me a liar]
No, you're the liar.
>> apparently unaware that the correct response to my post was to
>> either leave it alone or agree.
>
> [calls me a liar]
No, you're the liar.
>> In <············@news.eternal-september.org> I responded in such a
>> way that you could have just left that post to stand unmolested
>> and everything would have been fine. Instead, you attacked and
>> here we are now.
>
> In that article, you screwed up
I DID NOT.
> [rest of insults deleted]
No. You're the stupid one here, as has been repeatedly demonstrated.
>> Given that you had several opportunities to leave me alone and
>> chose instead to blast me with increasingly-stronger shots each
>> time, I have to conclude that you want a fight.
>
> No
Yet here you are, fighting some more, viciously insulting me again and
again and again.
I think you don't even know your own mind very well.
>>>> you replied with
>>>> a more direct and serious attack instead of letting sleeping
>>>> dogs lie. Big mistake.
>>> Again, got a msg-ID?
>> Yes: <································@bt.com>
>
> That's not a serious attack.
I'll be the judge of that.
> [calls me a liar]
Says the liar.
>> This you should definitely never have posted.
>
> Why not?
Because it implied vicious lies about me, doofus. Why else?
>>> My own recollection is that you appeared to continue to
>>> misunderstand
>> I HAVE NO INTEREST IN CONTINUING TO DISCUSS YOUR OPINION OF MY
>> MENTAL FUNCTIONING. HAVE I MADE MYSELF CLEAR?
>
> Yes, you have. I have no interest in it either.
Then stop doing so! Or, by continuing to do so, prove beyond any
remaining sliver of a doubt that you are, indeed, a liar.
>> Why are you so unwilling to respect multiple boundaries?
>>
>> 1. The topic bounds. These newsgroups are for discussing
>> programming, not people.
>
> sizeof qualifies.
Seamus MacRae's intellect does not, and comprises the bulk of the
subject matter in your excessively-long posts.
>> 2. The personal boundaries around one another. You do not publicly
>> speculate about another person's mental functioning without
>> permission! Jeezus.
>
> I am not interested in speculating about your mental functioning.
Then stop doing so! Or, by continuing to do so, prove beyond any
remaining sliver of a doubt that you are, indeed, a liar.
>> 3. The relevance bounds. The arguments about Lisp vs. Java,
>> emacs vs. Eclipse, and Seed7 warnings, and the original
>> job-search topics, all have relevance bounds. My mental
>> functioning is irrelevant to all of those topics. The only
>> person whose mental functioning might be relevant to any of
>> them is Robert Maas, the original job-seeker.
>
> In this thread, I'm not interested in any of these things.
Then this is the wrong thread for you. It's that simple.
>>>> 3. You continued to not back down when I continued to try to
>>>> reset things to the appropriate state so that the
>>>> discussion could move on in other directions.
>>> Why would I back down from a correct position?
>> I refer to your arguments about my mental functioning.
>
> I'm not *interested* in your mental functioning. Please can we drop
Then do so! Or, by continuing to discuss it, prove beyond any remaining
sliver of a doubt that you are, indeed, a liar.
> [implied insults]
Wrong again, fatso.
>> You hold certain *opinions* there. They are not "correct" in my
>> opinion,
>
> So what? [further insults deleted]
So you seem to treat your *opinions* regarding my intelligence as if
they were matters of *fact*.
Which is especially odd, because if they're just *opinions*, then you
simply have an opinion like anyone might, but if they are matters of
*fact*, then you are *wrong*. Wouldn't you rather be opinionated than be
wrong?
>> And I say you are to stop discussing me in public altogether.
>
> I'm not trying to discuss you.
Then stop doing so! Or, by continuing to do so, prove beyond any
remaining sliver of a doubt that you are, indeed, a liar.
> if there's one thing that's likely to make me want to continue to
> discuss a subject, it's a demand for me to stop.
That's because you're perverse and childish and probably have
Oppositional Defiant Disorder. Basically means you habitually disrespect
your elders, such as me.
>> Killfile me if you must, but henceforth, please pretend that I do
>> not exist.
>
> I'm okay with pretending you don't exist.
Then do so! Or, by failing to do so, prove beyond any remaining sliver
of a doubt that you are, indeed, a liar.
> So - we have this invisible man who doesn't exist (if I shut my
> eyes), but this invisible man who doesn't exist is [calls me a
> liar]. How can we solve this problem?
Get you off the drugs. You're clearly hallucinating, or, perhaps, just
plain delusional.
>> That means if you see a post by me, it does not exist
>> so you will not post a followup. If you hold an opinion about me,
>> it does not exist so you will not post mentioning it or implying
>> it.
>
> [But I demand the last word! I DEMAND IT! WAAAAAH!]
>
>> I hope I've made myself clear enough this time.
>
> [But I demand the last word! I DEMAND IT! WAAAAAH!] I hope I've
> made myself clear enough this time.
All too clear, crybaby.
>>>> Don't do that!
>>> You don't get to control my actions.
>> Ordinarily, no, but when your actions include making public
>> statements about me, my rights of privacy and publicity enter into
>> it, and I say I don't want you discussing me in public.
>
> I'm not interested in discussing you in public.
Then stop doing so! Or, by continuing to do so, prove beyond any
remaining sliver of a doubt that you are, indeed, a liar.
>> Really, I am none of your business anyway so you have no good
>> reason to be doing so;
>
> It is you, not me, who prolong this discussion.
You're the one who keeps insisting upon having to have the last word,
remember?
>>> You don't get to control my actions.
>> You're missing the point. I am attempting to explain rules of
>> polite society to you that apparently you don't get.
>
> [insult deleted]
No, you're the rude one.
>> You don't keep pressing someone that clearly doesn't want a
>> fight. You leave them alone.
>
> I don't want a fight.
Then stop fighting! Or, by continuing to do so, prove beyond any
remaining sliver of a doubt that you are, indeed, a liar.
>>> If you screw up
>> That never happens.
>
> It happened. [rest of insulting lies deleted]
It did not.
>> If it ever did, then you should certainly not keep aggressively
>> poking at someone who is trying to save face.
>
> [calls me a liar]
No, you're the liar, remember?
>> That's how big, nasty fights start, when someone disrespects
>> someone else's right to be left alone.
>
> If you don't want people to respond to your articles, in my
> experience the best way to achieve that is not to post them.
But I have to post rebuttals to each of your erroneous posts attacking
me, lest somebody read your post, see that it was allowed to pass
unchallenged, and think that what you said about me was actually true.
You, on the other hand, don't have to reply to those.
> Anything you do post is very likely to get discussed, even if the
> thing you post is "please don't discuss this". That's human nature
> for you.
No, that's childish crybaby nature for you. You might notice that nobody
else is discussing those posts of mine except you.
>>>> You'll have said
>>>> your opinion, they'll have said theirs, and everyone can move
>>>> on.
>>> You can move on any time you like. Nobody forces you to respond.
>> Oh, is that what this is about? You keep posting because you have
>> a childish insistence on having the last word? How disappointing.
>
> I've already explained elsethread that you can have the last word.
Then shut up! Or, by failing to do so, prove beyond any remaining sliver
of a doubt that you are, indeed, a liar.
> If you want to suppress discussion of a subject you find
> uncomfortable, telling people not to discuss it is simply the wrong
> strategy.
Oh? Then what, in your *opinion*, WOULD be the right strategy?
Postcondition: after the strategy is executed, the "discussion" has
stopped and no negative claim about me stands unchallenged -- all have
at least one followup, in all of the same newsgroups, asserting that the
insults targeted at me are 100% erroneous and I'm really a great guy
despite what some schmuck said.
>>>> If, instead, you respond by restating your opinion more
>>>> forcefully, it starts a fight instead, and nobody benefits from
>>>> that.
>>> If someone (anyone, not just you) disagrees with a point I've
>>> made in an article, either they are right (in which case I'm
>>> wrong and I'd like to know about it), or they are not right (in
>>> which case it may be worth trying to put things in a way that is
>>> easier to grasp)
>> Insulting. I think you should be thinking "worth trying to put
>> things in a way that preserves both sides' dignity", don't you? Or
>> does the dignity of other people not concern you?
>
> [lies deleted]
I think you should be thinking "worth trying to put things in a way that
preserves both sides' dignity", don't you? Or does the dignity of other
people not concern you?
>> I'm getting a very disturbing picture here: that you are not
>> willing to agree to disagree on any subject, nor do you care about
>> preserving the dignity of others.
>
> I think your picture is not so much disturbing as distorted.
> [rest deleted]
No, you're the one that hallucinates, remember?
>>> In this case, you [insult deleted]
>> I repeat: I am not interested in your opinion of me. Neither is
>> anyone else. Don't. Post it. Again.
>
> I repeat: you don't get to control my actions.
That's a definite threat to badmouth me in public.
I don't respond well to threats.
>>> you didn't seem to see why
>> I see exactly why you hold your opinion of me.
>
> You don't know what my opinion of you is
Sure I do. It is very easy to infer from the opinion of me that your
posts are designed to induce in readers.
> [more namecalling, etc.]
Up yours, liar.
>> I also don't give a shit. My concern is with your *posting that
>> opinion in public*, and posting things apparently designed to
>> induce *other people to develop the same, negative opinion*.
>> You can surely understand why I don't want that happening,
>> particularly the latter part.
>
> What I don't understand is why you [insults deleted]
I don't. You lie, as usual, about me.
>> What I don't understand is why you seem to be insistent that that
>> happen, and that I not be permitted to speak up in my own defense?
>
> Of course you are permitted to speak up in your own defence.
Yet you keep telling me not to do so, threatening me with dire
consequences (such as more insults by you) if I do do so, and insulting
me whenever I do do so.
You certainly don't *seem* to want me to do so, at least not and have my
defense stand unchallenged.
(You could prove that wrong, of course, by simply not replying to this
post.)
> But you are not being attacked.
A lie.
> [calls me a liar]
But we've already established which one of us is the liar, and it wasn't
me, remember?
>> Really, I just want to be left alone.
>
> Would you prefer it if nobody responded to your articles?
I would certainly prefer it if you did not.
> [threats deleted]
I don't respond well to threats.
>> If, after this post, you continue to harass me,
>
> I'm not trying to harass you.
Then stop doing so! Or, by continuing to do so, prove beyond any
remaining sliver of a doubt that you are, indeed, a liar.
>> I will have to
>> conclude that your purpose is in fact to start a fight. There is
>> no other explanation for someone posting an attack post in
>> response to "I just want to be left alone", after all.
>
> I am *not* attacking you.
Liar.
> but not at the expense of giving in to what I perceive to be
> attempts at coercion.
You're one to talk. Shut up or else. I WILL have the last word. Do not
defend yourself dammit! And so forth.
>>> I have even now not made it clear enough (although the middle
>>> part of this reply is another attempt).
>> Your opinion is crystal clear. I hope by now so is mine: I do not
>> want you to make yours even clearer. I want you to drop the
>> subject and leave me in peace.
>
> The subject is [calls me names yet again]
The subject is moot. The discussion is over. I am not, and never have
been, stupid, and that is final. Non-negotiable. Do you understand the
meaning of the phrase "non-negotiable"?
>>>>> I described your argument as a strawman argument because
>>>> you're an asshole. Yes, yes, I know.
>>> Selective quotation
>> Please do not change the subject.
>
> [calls me a liar]
You changed the subject from your being an asshole to quotations. I can
see why you might find the former subject uncomfortable in a public
discussion, but hey, turnabout is fair play. Changing the subject as a
dodge, on the other hand, is cheating.
>>>>> your flawed understanding
>>>>> led you to believe, mistakenly
>>>> Stop personally-attacking me at once.
>>> Firstly, I'm not personally attacking you.
>> Yes, you are.
> No, I'm not.
Yes, you are. This latest magnum opus of yours is just oozing with
contempt and dripping with personal attacks.
>> You are publicly calling my intelligence into question. That is
>> an insult.
>
> No, it isn't.
Yes, it is.
> [more silly namecalling from Richard]
Give it a rest.
>> It's the same as if you posted "Seamus MacRae is an idiot" on
>> the billboard at Times Square.
>
> No, it isn't.
Yes, it is.
> If I did as you described, it would be impractical and
> possibly even counter-productive to put up another poster saying
> "no he isn't". But on Usenet
On Usenet, it's easy for me to say no I'm not, but then it's just as
easy for you to keep reiterating yes, you are, and then we get stuck in
an endless loop that is equally impractical.
> I suspect that you are probably not an idiot
So, at last you admit the truth!
>> How would you like it if someone put "Richard Heathfield is an
>> idiot" on there?
>
> If you posted such a comment on Usenet, you would not be the first.
> And I would not react by trying to stop you from posting.
What if I didn't do it just once, but again and again and again, and
explicitly expressed an intention to do so again every single time you
posted to protest that you were not one?
Then what would you do?
> Instead, I'd try to find out why you thought I was an idiot, and
> then I'd explain why it wasn't the case.
Been there, done that, didn't work. What next?
>> I'm guessing you wouldn't.
>
> I wouldn't particularly revel in it, no, but on the other hand I'm a
> grown-up and able to take care of myself in a discussion without
> having to resort to trying to shut the other guy up (which never,
> ever works).
Ooh -- more namecalling and more threats. I'm so scared!
Not.
Meanwhile, you neglect to consider the question of what you would do if
the other guy keeps going on and on and on, in public, about what a
horrible person and doofus you are. Surely you'd have to do *something*,
and given the impracticality of spending hours every day posting
rebuttal after rebuttal, you'd figure out the obvious shortcut!
>> Please let this entire matter just drop, for both of our sakes.
>
> If you mean the matter of sizeof
NO, I MEAN THE MATTER OF ME.
>>> I am having a discussion on Usenet.
>> You are discussing a person in public without that person's
>> consent. That is a no-no.
>
> Very little is a no-no on Usenet
Are you forgetting your internet provider's terms of service, which I
posted above? I marked out the sections you were clearly violating, for
your benefit. Perhaps you'd like to review it now, before continuing
with this clearly-erroneous line of debate.
>>> Secondly, I am sure you would agree that you are wholly
>>> entitled to make your own choice about whether to take part in,
>>> or to withdraw from, this discussion.
>> Then I choose to withdraw from it, by which is meant my name will
>> not appear any further in it, which in turn means you do not talk
>> about me and you do not follow up to one of my posts.
>
> You don't get to control my actions.
Another threat! My oh my!
>> Is that clear?
>
> Your opinion is clear enough.
Good.
>> Otherwise, I am "taking part" by being mentioned or quoted in it,
>> against my will and in violation of that very entitlement that you
>> just admitted I possess.
>
> You get to choose what you do.
And I choose not to have my name mentioned in this any more. Simple, right?
>>>> You will not again use the
>>>> words "flawed" or "mistaken" to describe me in public. Do I make
>>>> myself clear?
>>> You make yourself perfectly clear, but [insults deleted]
>>> You don't get to decide what I write.
>> Fuck you.
>
> [puerile babblings deleted]
I said, "fuck you". What part of "fuck you" don't you understand?
>> Obviously, you understand me perfectly and are explicitly refusing
>> to leave me alone.
>
> No, I'm exercising my right to post to Usenet
Go ahead and post. Just leave me the fuck out of it, OK?
>> Fine. If you want a fight, let's fight.
>>
>> Your mother is so fat, she is required by law to wear a "wide
>> load" sign and beep when she backs up.
>
> [calls me a liar]
Nope, sorry, no can do. We've been over that already, see?
> [insults deleted]
How boring. The same old insults to the intelligence thing. Not even a
poke regarding my mental health, let alone my mother or my sexual
preferences. You keep picking fights but you're just *terrible* at flaming!
>> Your turn.
>
> Let's get back to sizeof, shall we?
Nah. Your girlfriend's so loose you'd rather fuck a goat.
>>>> Leave. Me. Alone.
>>> If you don't wish to communicate with me, you can stop doing so
>>> at any time.
>> I don't wish to be communicated ABOUT in public by you.
>
> Fine. I don't wish to pay tax. But we don't always get what we want.
I don't respond well to threats.
> As it happens, however, I'm not overly excited about the prospect
> of communicating about you either.
Then stop doing so! Or, by continuing to do so, prove beyond any
remaining sliver of a doubt that you are, indeed, a liar.
>>>> These newsgroups are for discussing programming, not people. I
>>>> am off-topic here.
>>> I agree
>> Then stop talking about me!
>
> You don't get to control my actions.
I don't respond well to threats.
>>> sizeof *is* topical, and that's what I'm discussing.
>> Get real. This stopped being about "sizeof" several posts ago when
>> you decided to make things personal.
>
> So you claim. But I disagree.
Then you're a nut.
>>> All this extraneous guff is just a side issue.
>> All this "extraneous guff" is what actually matters to me. If you
>> consider it a mere "side issue" then that's another reason for you
>> to drop this thread and move on -- topic drift has taken it
>> outside of your area of interest.
>
> I'm very ready to drop all the personal stuff
Then do so! Or, by failing to do so, prove beyond any remaining sliver
of a doubt that you are, indeed, a liar.
>>>>>>>>> I've worked in environments like that, and found it quite
>>>>>>>>> workable.
>>>>>>>> Now I know why so much C software is crash-prone and
>>>>>>>> generally buggy.
>>>>> Spot the (groundless) personal attack, to which I reacted.
>>>> There was no personal attack in my post.
>>> That's called "special pleading".
>> No, it's called pointing out that insulting software is not
>> insulting a human being, and therefore is not a personal attack.
>
> No, it's called "special pleading".
No, it's called pointing out that insulting software is not insulting a
human being, and therefore is not a personal attack. For an attack to be
personal it has to be directed AT A PERSON! Get it?
> [calls me a liar]
No, you're the liar.
>> For it to have been a *personal* attack it would have had to imply
>> something negative about some specific *person*.
>
> Even granting for the sake of argument (and without prejudice to
> future dispute) that this definition is correct, how is my
> [implication that Seamus MacRae is an idiot] a "personal attack"?
That you even asked the question speaks volumes about YOUR intelligence.
>>>> Saying that environments
>>>> that ignore a lot of compiler warnings generate buggy code is
>>>> not an attack on any particular person.
>>> Who said anything about ignoring compiler warnings?
>> You did.
>
> No
Yes, you did.
> [calls me an idiot again]
No, you're the idiot, remember?
>> Fuck you.
>
> Is that five?
Yeah, with the middle one upraised and the others closed into a fist.
>> I've had it with you. You pretend to some kind of civilized
>> character but your real objective is simply to go around
>> badmouthing anyone you disagree with,
>
> No
Yes. You've proven it by your actions.
>> have the last word in any discussion, and generally shove your
>> weight around. How old are you, about three?
>
> Even older than three. In fact, I'm all gwowed-up now
That's a laugh. I'm guessing no more than about seven. Though you
probably did think of seven as "all gwowed up" four years ago when you
were three.
>>> (a) it's impossible to satisfy every compiler, and code that is
>>> required for eliminating a warning on one compiler may itself
>>> cause a warning on another; therefore, a clean build is not
>>> actually possible in the general case for non-trivial code that
>>> must build on multiple compilers;
>> Doesn't follow. Ever heard of #ifdef and its friends? Conditional
>> compilation means being able to satisfy multiple compilers, and
>> produce more portable code.
>
> The cure is worse than the disease
In your humble opinion.
> Stupid stupid stupid.
Yes, you most certainly are.
>>> Nevertheless, you have clearly made them.
>> I have *now*,
>
> You started way back.
I started after you did.
>> when you continued to publicly badmouth me. You asked for it,
>> you got it. Now, are you ready to quit, or are you thirsty
>> for more?
I guess that question has now been answered in the affirmative.
> Or are you determined to follow your self-destructive path?
Another threat! My my! Perhaps I should be calling the police now, and
nevermind my lawyer or your ISP's abuse department. Your implication now
is that you intend to drive me to suicide! That's murder in at least
some jurisdictions, and sure reads as a death threat to me no matter what.
>>>>>> You've said your piece and I've said mine. Move on.
>>>>> I'm already in the right place.
>>>> NO. YOU ARE NOT.
>>> I respectfully disagree.
>> Respect? That's a joke. You've shown no respect for my wishes, for
>> my boundaries, or for any of the three newsgroups' topic
>> boundaries, at least thus far.
>
> I have tried to show restraint and respect
If so, you've done an astonishingly lousy job of it.
> continually try to avoid in favour of extraneous waffle about
> personalities.
You were the one to drag personalities into this, way back when you
first posted and, by doing so, erroneously implied that I was an idiot.
>>>> You've said your piece. It does not bear repeating.
>>> Am I right to interpret this as "Seamus is not interested in
>> You are right to interpret this as "Seamus is not interested in
>> continuing this discussion, or in being the subject of any
>> discussion in which you participate".
>
> Then the solution is easy - you can simply killfile me
That won't work, because it will leave you to continue badmouthing me
unopposed. In other words, I'd be handing you victory on a platter.
Nice try, but I'm far too intelligent to fall for such a lame trick.
Methinks you've swallowed too much of your own propaganda and started
actually believing that I'm stupid and things like that. Well, let me
enlighten you ...
>>>> MOVE ON.
>>> I'm already in the right place.
>> No. See above.
>
> Your failure
I have no failures. You do, remember?
>>>> Calling me a liar will not make me friendlier.
>>> I don't believe I've called you a liar.
>> Implied it, at any rate.
>
> No.
Yes.
> [calls me a liar again]
See?
>>> Irony is always dangerous.
>> So is a complaint to your internet provider for flooding three
>> newsgroups with offtopic drivel.
>
> I am trying to discuss sizeof, not offtopic drivel.
You're failing. Spectacularly.
>>>>> Okay, so I'll retract "buffoon" - but for heaven's sake,
>>>>> lighten up a little
>>>> After you.
>>> I'm not the one who introduced expletives into the discussion.
>> You are, however, the one who introduced rudeness, personal
>> innuendos,
>
> I don't think so.
Do I need to post the msgids again?
>>> Nor will I sink to your level
>> My God, are you really trying to claim the moral high ground now?
>
> Why would I need to do that?
Because you're hip-deep in quicksand and sinking fast?
>> How utterly ridiculous. It's never available at any price to the
>> guy that shot first, so you can give up on that idea right quick.
>
> My first "shot" as you call it was [calls me an idiot]
Yes, I know. You don't seem to think calling people idiots in a public
place is a biggie. Well, I happen to disagree, so fuck you.
[large irrelevant aside deleted]
>>> It's more cost-effective to xxx in a public article than to send
>>> emails to every single subscriber.
>
> That is a lie.
No, you are the liar, remember?
>> Anyway, I guess it's now your move. Will you decide to leave
>> things be, and consider this match a draw,
>
> It's not a match.
Then stop fighting! Or, by continuing to do so, prove beyond any
remaining sliver of a doubt that you are, indeed, a liar.
> This isn't a competition. It's [calls me an idiot]
Oh, it's idiocy alright, but the idiocy is all coming from some guy who
calls himself Richard Heathfield.
On Jun 3, 12:58 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
> That can proceed by one of two ways: I convince you to shut up, or I
> force you to shut up. Apparently I can't convince you to shut up. So I
> guess I'm going to have to have a little chit-chat with the abuse
> department at your ISP.
> Failing that, I guess I'll have to get lawyers involved.
Seamus, because of your nazi-like threats bordering on crimes against
humanity your ISP has decided that you're very close to being banned.
Now because of your mental disease, we can get you a job at McDonalds
in Sunnyvale.
Now stop your nazi-like threats and personal attacks Seamus.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p21p$gi9$1@news.eternal-september.org>
MarkH wrote:
> On Jun 3, 12:58 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
>
>> That can proceed by one of two ways: I convince you to shut up, or I
>> force you to shut up. Apparently I can't convince you to shut up. So I
>> guess I'm going to have to have a little chit-chat with the abuse
>> department at your ISP.
>
>> Failing that, I guess I'll have to get lawyers involved.
>
> Seamus, because of your nazi-like threats bordering on crimes against
> humanity your ISP has decided that you're very close to being banned.
This is a pack of lies.
1. My ISP has received no complaints about me to date.
2. I am not making "Nazi-like threats". I am quite properly warning my
attacker that his behavior oversteps the bounds set by the law, for
which there are consequences.
3. I have done nothing remotely warranting a comparison to Nazis or
allusions to "crimes against humanity".
> Now because of your mental disease
I have no mental disease.
Also, according to Godwin's Law, your side just lost the argument due to
your post.
So I guess that concludes this flamewar.
Seamus 1, comp.lang.lisp flamers 0.
Rematch in one year? :)
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh2dknu.b5g.willem@snail.stack.nl>
Seamus MacRae wrote:
) <snip>
) I. Do. Not. Make. Mistakes.
) <snip>
You claimed that sizeof always evaluates its operand,
but sizeof only evaluates its operand when it's a VLA.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p1ru$ecg$3@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) <snip>
> ) I. Do. Not. Make. Mistakes.
> ) <snip>
>
> [calls me a liar AND an idiot in one sentence]
I am neither.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh305eh.1m0l.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> Seamus MacRae wrote:
)> ) <snip>
)> ) I. Do. Not. Make. Mistakes.
)> ) <snip>
)>
)> You claimed that sizeof always evaluates its operand,
)> but sizeof only evaluates its operand when it's a VLA.
)
) I am neither.
Huh ? That doesn't make sense. What does 'I am neither'
have to do with my statement about your claim ?
By the way, the statement 'I do not make mistakes' is delusional
and megalomanic. If you really believe that you should get
professional help. If not, you've just proven yourself a liar.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
On 2009-06-10, Willem <······@snail.stack.nl> wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Seamus MacRae wrote:
> )> ) <snip>
> )> ) I. Do. Not. Make. Mistakes.
> )> ) <snip>
>
> By the way, the statement 'I do not make mistakes' is delusional
> and megalomanic. If you really believe that you should get
> professional help. If not, you've just proven yourself a liar.
Keep in mind that this is the same person who in our '07 exchange
authored such gems as
---
No. No point that is contradictory to something that I've said ever
"stands", and none of the nasty things that you have said or implied
about me are at all true.
---
Nothing is ever my fault.
---
If you've done so, then you need to get your eyesight checked. It is
not possible for a genuine observation to contradict me; you could no
more observe that than you could observe two plus two adding up to
five. If you thought you did, then you saw something illusory, or
perhaps hallucinatory.
---
I HAVE FLATLY CONTRADICTED YOUR FLATLY CONTRADICTING MY CLAIM HERE SO
NOTHING THAT YOU HAVE SAID IS FUCKING UNOPPOSED, FUCKWIT!!
NOW FUCK OFF!!!
---
(Ok, the last one isn't directly relevant but it did bring a smile to
my face at the time.)
At points in that thread we went into some detail about his various
delusions, those who wish themselves emotional harm may want to peruse
the comp.lang.java.programmer "Great SWT Program" thread of
yesteryear. It starts with an innocent question, continues with a
discussion of emacs and vi vs other editors and devolves into the sort
of debate we've been seeing here over the last several weeks. Except
we went at it for quite a bit longer and frankly the material started
getting a bit stale after the 3,000th post or so.
At the time he went under a variety of names, of which "Twisted" was
perhaps the most apt one. He discontinued them after the thread died
down and has occasionally re-emerged in c.l.j.p with new names, only
to have his behaviour recognized, participate in a brief exchange and
then disappear again. What has made the current reincarnation
particularly long-lived, I expect, is that he is an unknown phenomenom
in c.l.l and c.p so wasn't as readily ignored.
To his credit, the god complex seems far less pronounced this time
than it was back then. Perhaps he is getting better. The most notable
change since then, however, is that this time he's largely stuck to
only two aliases throughout while it used to be half a dozen or more.
I made a pledge at the time to the c.l.j.p regulars that I would
discontinue the exchange. For that reason I have posted this only to
c.l.l and c.p. This is somewhat rude of me as I do not read either of
those groups, but on the other hand I will not be around to respond to
Seamus' inevitable rebuttal so there's a silver lining I suppose.
Cheers,
Bent D
--
Bent Dalager - ···@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Bent C Dalager wrote:
> On 2009-06-10, Willem <······@snail.stack.nl> wrote:
>> Seamus MacRae wrote:
>> ) Willem wrote:
>> )> Seamus MacRae wrote:
>> )> ) <snip>
>> )> ) I. Do. Not. Make. Mistakes.
>> )> ) <snip>
>>
>> By the way, the statement 'I do not make mistakes' is delusional
>> and megalomanic. If you really believe that you should get
>> professional help. If not, you've just proven yourself a liar.
>
> Keep in mind that this is the same person who in our '07 exchange
Who the heck are you? I have never had any exchange with you that I can
recall.
Until now.
> At points in that thread we went into some detail about his various
> delusions
You are the one with delusions. You've apparently imagined a detailed
interaction between the two of us that never actually happened. In fact,
a flamewar from the sounds of it.
> At the time he went under a variety of names, of which "Twisted" was
> perhaps the most apt one.
I have never used that name, nor any other besides Seamus MacRae.
[rest of Bent C. Dalager's delusions deleted unread.]
On Jun 10, 5:27 pm, Bent C Dalager <····@pvv.ntnu.no> wrote:
> On 2009-06-10, Willem <······@snail.stack.nl> wrote:
> > Seamus MacRae wrote:
> > ) Willem wrote:
> > )> Seamus MacRae wrote:
> > )> ) <snip>
> > )> ) I. Do. Not. Make. Mistakes.
> > )> ) <snip>
>
> > [Willem viciously insulting Seamus]
>
> Keep in mind that this is the same person who in our '07 exchange
> authored such gems as
>
> ---
> No. No point that is contradictory to something that I've said ever
> "stands", and none of the nasty things that you have said or implied
> about me are at all true.
No, that was me. I am not either Willem or Seamus.
> I HAVE FLATLY CONTRADICTED YOUR FLATLY CONTRADICTING MY CLAIM HERE SO
> NOTHING THAT YOU HAVE SAID IS FUCKING UNOPPOSED, FUCKWIT!!
>
> NOW FUCK OFF!!!
> ---
>
> (Ok, the last one isn't directly relevant but it did bring a smile to
> my face at the time.)
That's because you're a psychopath.
> At points in that thread we went into some detail about [insult deleted]
No, you're the crazy one.
None of the nasty things that you have said or implied about me are at
all true.
> It starts with an innocent question, continues with a
> discussion of emacs and vi vs other editors and devolves into the sort
> of debate we've been seeing here over the last several weeks. Except
> we went at it for quite a bit longer and frankly the material started
> getting a bit stale after the 3,000th post or so.
Yes, because you kept repeating yourself endlessly.
By the way, it's still going on, though not in cljp, and I'm heading
over there right after I'm done mopping up loose ends here.
> At the time he went under a variety of names, of which "Twisted" was
> perhaps the most apt one.
None of the nasty things that you have said or implied about me are at
all true.
> He discontinued them after the thread died
> down and has occasionally re-emerged in c.l.j.p with new names
I have not. I post almost exclusively under my real name now, and have
only very rarely posted in cljp in the past two years, generally only
when someone gets it into their head that maybe I've stopped keeping
tabs on that group and takes a random and irrelevant potshot at me
hoping it will stand unopposed. Then I show up again briefly to
disabuse them of that notion and set the record straight. As I am
doing here, now.
> What has made the current reincarnation particularly long-lived, I
> expect, is that he is an unknown phenomenom in c.l.l and c.p so
> wasn't as readily ignored.
I haven't posted to comp.lang.lisp, except for responses to
crossposted Xah Lee threads that also hit cljp, until today. I can't
recall ever posting to comp.programming before this thread, and I've
only posted to this thread once or twice before, when a cljp flamer
took a random and irrelevant potshot at me in it (usually Larse or
Arne).
> To his credit, [implied insult deleted].
No, you're the crazy one.
None of the nasty things that you have said or implied about me are at
all true.
> The most notable change since then, however, is that this time he's
> largely stuck to only two aliases throughout while it used to be
> half a dozen or more.
I've largely stuck to only two aliases: Jerry Gerrone (my real name)
and ······@gmail.com (alt account for when Google Groups has "issues"
that make my primary account temporarily unusable).
> This is somewhat rude of me
Believe me, we've noticed.
> but on the other hand I will not be around to respond to
> Seamus' inevitable rebuttal
Mine is the rebuttal you have to worry about.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u7h2$vdm$6@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) I am neither.
>
> Huh ? That doesn't make sense. What does 'I am neither'
> have to do with my statement about your claim ?
It doesn't make sense when you misquote my post to make it not make sense.
Here is my actual post, as I actually wrote it:
> Willem wrote:
>> Seamus MacRae wrote:
>> ) <snip>
>> ) I. Do. Not. Make. Mistakes.
>> ) <snip>
>>
>> [calls me a liar AND an idiot in one sentence]
>
> I am neither.
Clearly, "neither" refers to "a liar" and "an idiot". It makes perfect
sense when it is not taken out of context and misquoted.
> [calls me a liar AND a crazy person in one sentence]
I am neither.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh35ah1.ejf.willem@snail.stack.nl>
Seamus MacRae wrote:
) It doesn't make sense when you misquote my post to make it not make sense.
*you* misquoted *my* post, remember ?
I just put back what I wrote in the first place.
You know, the bit where it sais 'Willem wrote' ?
That's me. Not you. So I get to decide what goes there. Not you.
Why are you misquoting other people's posts anyway ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h10n4k$jpm$6@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) It doesn't make sense when you misquote my post to make it not make sense.
>
> *you* misquoted *my* post, remember ?
No. I indicated editorial comments in square brackets, a commonly
accepted practise. I did not quietly alter quoted material without
giving any indication of having done so. You did.
> I just put back what I wrote in the first place.
The problem is, your post made my "I'm neither" look nonsensical, and
then pointed out its supposed nonsensical nature, when in actual fact in
its actual context my "I'm neither" was perfectly understandable. In
short, you dishonestly misquoted my message to make something I said
*look* nonsensical that never actually was.
> Why are you misquoting other people's posts anyway ?
I am not. You are, remember?
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh37snl.16kl.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> Seamus MacRae wrote:
)> ) It doesn't make sense when you misquote my post to make it not make sense.
)>
)> *you* misquoted *my* post, remember ?
)
) No. I indicated editorial comments in square brackets, a commonly
) accepted practise. I did not quietly alter quoted material without
) giving any indication of having done so. You did.
You removed quoted material and then replaced them with your so-called
'editorial comments'. The commonly accepted practise for editorial
comments is to *leave the original quote in place*. What you did was
dishonest and deceitful, and can only be explained as intentionally
misquoting somebody. Basically, you knowingly claimed I said something I
did not say, which is a lie.
That proves that you a liar. I believe Richard proved the same earlier.
)> I just put back what I wrote in the first place.
)
) [Calls me a liar]
What I just did here is the same as what you started.
)> Why are you misquoting other people's posts anyway ?
)
) I am not. You are, remember?
I am not. You are, remember? See above for the explanation.
(Also see my previous post from which you snipped the explanation of why
my changing of *my own* quote, *back to what it was* is not misquoting.)
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h13aha$dg7$1@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Seamus MacRae wrote:
> )> ) It doesn't make sense when you misquote my post to make it not make sense.
> )>
> )> *you* misquoted *my* post, remember ?
> )
> ) No. I indicated editorial comments in square brackets, a commonly
> ) accepted practise. I did not quietly alter quoted material without
> ) giving any indication of having done so. You did.
>
> You removed quoted material and then replaced them with your
> 'editorial comments'.
Yes, I believe I said that. So?
> dishonest and deceitful
Yes, you are. I *had* noticed.
> Basically, you knowingly claimed I said something I did not say, which is a lie.
I did not. I did reduce what you said to the bits that I found
important, namely your calling me two particular names, and ignored the
rest, but that is perfectly normal; the rest wasn't relevant to the
debate about how good or bad a person Seamus MacRae is, and it's normal
usenet practice to trim what's not relevant.
> That proves that you a liar.
No, you're the liar, remember?
The problem is, your post made my "I'm neither" look nonsensical, and
then pointed out its supposed nonsensical nature, when in actual fact in
its actual context my "I'm neither" was perfectly understandable. In
short, you dishonestly misquoted my message to make something I said
*look* nonsensical that never actually was.
> )> Why are you misquoting other people's posts anyway ?
> )
> ) I am not. You are, remember?
>
> I am not.
Yes, you are.
> (Also see my previous post from which you snipped the explanation of why
> my changing of *my own* quote, *back to what it was* is not misquoting.)
It is, too, in two ways.
First of all, if you write
> Seamus MacRae wrote:
>> Willem wrote:
>>> Something Seamus MacRae didn't quote
then you're quoting me as quoting you on something that I didn't
actually quote you on. In other words, you're quoting me as saying
something, namely "Willem wrote: something", that I never actually said.
In other words, you're misquoting me.
Second of all, your edit altered the context of my phrase "I'm neither",
and it no longer made sense in the altered context. In other words, you
misquoted me.
Furthermore, you read the "I'm neither" in the original setting, where
it made perfect sense, then misquoted it as described, and then loudly
pointed out how it seemed to not make sense. Which puts the lie to your
claim to have been innocently restoring removed quoted material. You
knew exactly what I meant by "I'm neither", so your only reason for
making out like it was nonsense like that was to lie to people about me.
You knew it wasn't nonsense, yet intentionally portrayed it as if it
were -- that is lying! And your quote-editing has the obvious,
transparent motive of aiding you in perpetrating that lie.
So don't play any "I was just innocently restoring some deleted quoted
material" games. Maybe people MIGHT have believed you if you had NOT
also made those highly dishonest remarks about my "I'm neither" seeming
nonsensical, which it only seemed when the surrounding quoted material
was intentionally altered to MAKE it seem that way.
As things stand, you've been caught in a dishonest manipulation. Own up
to it and apologize or your credibility is shot.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3afgo.1mob.willem@snail.stack.nl>
(NB: Followups were set to a different newsgroup, without notice. This, in
and of itself is deceitful.)
Seamus MacRae wrote:
) Willem wrote:
)> You removed quoted material and then replaced them with your
)> 'editorial comments'.
)
) Yes, I believe I said that. So?
)
)> dishonest and deceitful
)
) Yes, you are. I *had* noticed.
As seen right here, you even go as low as to quote parts of a sentence out
of context, thus giving them a different meaning. In other words, claiming
I said something which I did not.
)> Basically, you knowingly claimed I said something I did not say, which is a lie.
)
) I did not.
You did it again, just a few lines above.
) I did reduce what you said to the bits that I found
) important, namely your calling me two particular names,
I did not actually call you those names. *You* did, in your so-called
'editorial comments'. In other words,
) and ignored the rest, but that is perfectly normal;
You did not 'reduce' what I said. You *completely* deleted it and replaced
it with your so-called 'editorial comments'. You write 'Willem wrote:',
followed *only* by things that *you* wrote, and *nothing* that I wrote.
As far as I can tell, you are prefectly aware of this, so stop lying about
it and own up.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1642i$1ko$1@news.eternal-september.org>
Willem wrote:
> (NB: Followups were set to a different newsgroup, without notice. This, in
> and of itself is deceitful.)
Not when the intent is to suppress a lie rather than the truth, it's not.
Next time RESPECT THE FOLLOWUP-TO: HEADER. Do NOT post any further
replies in comp.*! Got it? Better yet, do not post any further replies,
period. You don't seem to take a hint, so I guess I have to spell it out
for you: SHUT. UP.
> Seamus MacRae wrote:
> ) Willem wrote:
> )> You removed quoted material and then replaced them with your
> )> 'editorial comments'.
> )
> ) Yes, I believe I said that. So?
> )
> )> dishonest and deceitful
> )
> ) Yes, you are. I *had* noticed.
>
> [calls me a liar]
No, you're the liar, remember?
> )> Basically, you knowingly claimed I said something I did not say, which is a lie.
> )
> ) I did not.
>
> [calls me a liar]
No, you're the liar, remember?
> ) I did reduce what you said to the bits that I found
> ) important, namely your calling me two particular names,
>
> I did not actually call you those names.
Yes, you did. You implied that I was a liar and an idiot. I objected to
your mischaracterization of me. You then deceitfully attempted to make
it seem like my objection was nonsensical, when it clearly was not.
> [calls me a liar]
No, you're the liar, remember?
> As far as I can tell, [calls me a liar]
No, you're the liar, remember?
> SaSW
If this stands for something insulting, I hereby state for the record
that it is factually incorrect.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3d759.2e0v.willem@snail.stack.nl>
Notice: I have now also pointed followups (however, I pointed them to an
existing newsgroup). Let's see if Seamus takes his own advice and respects
the Followup-To: header.
Seamus MacRae wrote:
) Willem wrote:
)> (NB: Followups were set to a different newsgroup, without notice. This, in
)> and of itself is deceitful.)
)
) Not when the intent is to suppress
Suppressing others, are we ? Where do you think we are, North Korea ?
) You don't seem to take a hint, so I guess I have to spell it out
) for you: SHUT. UP.
You first.
)> I did not actually call you those names.
)
) Yes, you did. You implied that I was a liar and an idiot.
These two statements contradict each other.
Furthermore, neither of them represents the truth.
Note: In the rest of your post, you were only replying to yourself
(i.e. your 'editorial comments'), so I deleted it unread.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18jgs$g1d$4@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> (NB: Followups were set to a different newsgroup, without notice. This, in
> )> and of itself is deceitful.)
> )
> ) Not when the intent is to suppress deceitful posts
>
> Suppressing others
Suppressing misinformation about me is perfectly legitimate.
> ) You don't seem to take a hint, so I guess I have to spell it out
> ) for you: SHUT. UP.
>
> You first.
No. You fired the first shot; it's only fair that we exchange equal
numbers of blows, rather than you getting to have one more than me.
> )> I did not actually call you those names.
> )
> ) Yes, you did. You implied that I was a liar and an idiot.
>
> These two statements contradict each other.
No, they do not.
> [calls me a liar]
No, you're the liar, remember?
> Note: In the rest of your post, you were only replying to yourself
I was not. I was replying to the things you'd publicly implied about me.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3fm33.153.willem@snail.stack.nl>
It appears that you did not honour the Followup-To header.
No surprise there.
Seamus MacRae wrote:
) No. You fired the first shot;
Nope, you did, as I have already stated.
)> )> I did not actually call you those names.
)> )
)> ) Yes, you did. You implied that I was a liar and an idiot.
)>
)> These two statements contradict each other.
)
) No, they do not.
'actually call you' and 'implied' are opposites.
)> Note: In the rest of your post, you were only replying to yourself
)
) I was not. I was replying to the things you'd publicly implied about me.
There was nothing in the rest of the post that was even written by me.
It was comprised solely of your so-called 'editorial comments'.
(Note: I'm using quotes because there was nothing left to comment on)
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1bcd8$c6r$2@news.eternal-september.org>
Willem wrote:
> It appears that you did not honour the Followup-To header.
I will not honor any request of yours, not given the way you've treated
me and not given your motives and intentions.
> Seamus MacRae wrote:
> ) No. You fired the first shot;
>
> [calls me a liar]
No, you're the liar, remember?
You attacked me before I ever attacked you.
> )> )> I did not actually call you those names.
> )> )
> )> ) Yes, you did. You implied that I was a liar and an idiot.
> )>
> )> These two statements contradict each other.
> )
> ) No, they do not.
>
> 'actually call you' and 'implied' are opposites.
No, they aren't. Implying it is one way of calling me it. A way amenable
to trying to weasel out of it later when charged with being
intentionally insulting. A way very suited to a very dishonest person
such as yourself, in other words.
> )> Note: In the rest of your post, you were only replying to yourself
> )
> ) I was not. I was replying to the things you'd publicly implied about me.
>
> There was nothing in the rest of the post that was even written by me.
> It was comprised solely of your so-called 'editorial comments'.
Those comments, however, were summing up the things that YOU said.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3ieka.l03.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> There was nothing in the rest of the post that was even written by me.
)> It was comprised solely of your so-called 'editorial comments'.
)
) Those comments, however, were summing up the things that YOU said.
They were not. They were summing up the things that YOU wanted everybody
to think that I said, so that you could then act all indignant about it.
I hereby state for the record that none of the 'editorial comments' that
Seamus has written was in any way representative of anything I have said.
Having said that, I will now ignore any further reply by yours to any
'editorial comment', given that these are, as I just stated, false.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1gj4g$ckj$1@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> There was nothing in the rest of the post that was even written by me.
> )> It was comprised solely of your so-called 'editorial comments'.
> )
> ) Those comments, however, were summing up the things that YOU said.
>
> They were not.
They were too.
> They were summing up the things that YOU wanted everybody
> to think that I said, so that you could then act all indignant about it.
Nonsense. I would prefer everyone to think you were complimenting me,
not insulting me.
> [calls me a liar]
No, you're the liar.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <tpOdnTQtoIilYrvXnZ2dnUVZ8jqdnZ2d@bt.com>
[Two introductory points. Firstly, as Seamus MacRae rightly points
out, the semantics of sizeof are off-topic in comp.lang.lisp and
comp.lang.java.programmer. I have therefore set followups to
comp.programming, no doubt to the relief of cll and cljp. I should
have done this some time ago, so I apologise to subscribers to
those groups for the noise. Secondly, the sizeof this subthread is
getting a little ludicrous. Radical snippage undertaken (and marked
as such). Refer to ancestor articles if required. As a result of
this radical snippage, this article is a little over half the size
of the article to which it is a response. I am beginning to think
that Seamus MacRae is trolling. In fact, I hope he is, because if
he's serious I am rather worried about him.]
Seamus MacRae said:
> Richard Heathfield wrote:
[alternately; no other contributors are quoted in chevrons in this
article, so count chevrons to establish ID - even = me, odd = SMR.
We lead off with SMR.]
<snip>
>>> Then please drop this.
>>>
>>> NOW!!!
>
> You forgot to drop it. Sorry, please hang up and try again.
You forgot that you don't get to control my actions. I am not
optimistic that you will remember this time, either.
<snip>
> You are in error about me.
I don't think so, but then I haven't actually said very much about
you. Most of what has been said about you has been said by you.
>>>>> Next time, do not "debunk" unsolicited.
>>>> If you don't wish for mistakes in your articles to be
>>>> corrected, you have two choices - (a) don't make mistakes, or
>>>> (b) don't post them.
>>> I go for option (a), always.
>>
>> [calls me a liar]
>
> You are in error about me.
You are in error to think that I called you a liar at that point in
my article. There is a difference between saying "you are a liar"
and "you have said something that is clearly not true". People can
say untrue things by mistake. I surmised that this was what had
happened here. (Later on in my previous article, however, I did
identify an actual lie of yours, which I pointed out.)
<snip>
> You are in error about me.
Assertion is not argument. Can you *demonstrate* that I'm in error
about you? What is it that you think I think about you that you
think I'm in error about? It is far from clear.
<snip>
> The problem is the thing you apparently want to teach to the
> world: "Seamus MacRae is an idiot".
That seems to be apparent only to you. It certainly isn't apparent
to me. I am far more concerned with discussing the semantics of
sizeof, which you appear to be determined to avoid. If you're so
convinced you're right about sizeof, it should be easy to
demonstrate that you're right. Why not give it a try? (Your
attempts so far have not addressed the issue at hand.)
> It is, of course, incorrect,
Can you demonstrate this? One way to do so would be to revert to a
technical discussion.
<snip>
>>> Well, now that you're aware of the possibility, you should know
>>> to just quietly move on now.
>>
>> This is Usenet. I don't have to move anywhere.
>
> Yes, you do.
Why?
> Have you forgotten that whether or not Seamus MacRae
> is an idiot is irrelevant to all three newsgroups you're spewing
> your crap into?
I'm not actually *interested* in whether you're an idiot. I don't
give tuppence for whether you're an idiot. Neither does anyone else
as far as I know - apart from you.
> And your occasional asides about C are irrelevant
> to two of them.
That is actually quite true. I have set followups accordingly.
>> What do /you/ mean by the metaphor "move on"? Do you mean
>> "quietly forget that Seamus MacRae [insults deleted]"
>
> I mean stop posting about Seamus MacRae. Period. Do not mention me
> again, in public, indirectly or directly, ever again.
You don't get to control my actions, remember?
<snip>
>>>> I think you're confusing
>>> I am not.
>> Then you must be confused.
>
> I just told you: I am not.
As we have already seen, just because you say something, that
doesn't necessarily make it true. You can be mistaken (as you were
about sizeof), and you can lie (as you did by deliberately
misquoting me). So just because you say you're not confused, that
doesn't mean you're not confused. Can you /demonstrate/ that you
are not confused about the semantics of sizeof?
<snip>
>
>> I used the word in passing (in what I consider to be a legitimate
>> way
>
> There is no "legitimate way" to call a stranger an idiot loudly in
> a print medium.
To say "I think you're confusing X with Y" is perfectly legitimate,
and is a far cry from calling you an idiot.
<snip>
>> [...elided...] I'm interested in sizeof.
>
> I'm not.
Then why express an opinion on it? (And an erroneous one at that.)
>>> Drop it.
>>
>> You don't get to control my actions, remember?
>
> Are you threatening to publicly badmouth me some more?
Mu.
> Do I need
> to get a lawyer involved in this?
A good lawyer would advise you not to be so daft as to involve the
courts in this. If you do, however, I will defend, I will win, and
I will counter-sue.
<snip>
>>>>> Regardless, it's been drilled in repeatedly: if "*foo" is
>>>>> encountered when foo is uninitialized, Bad Things may happen.
>>>> Sure - but this isn't *foo; it's sizeof *foo
>>> Which contains *foo as an argument, for heaven's sake.
>>
>> No, it doesn't.
>
> Yes, it does. We have an occurrence of the structure "operator
> argument". This is clear to anyone that isn't blind.
Ah, an attempt at a technical argument. Well, pretend I'm blind, and
explain why your theory overrides ISO/IEC 9899's position on the
matter, which is that an argument occurs only in a function call or
a function-like macro invocation.
>> I know from experience that you don't take a lot of notice of
>> proof
>
> I don't take a lot of notice of flawed arguments purporting to
> prove me an idiot, you mean. Because I know for a fact that I am
> not an idiot.
But I haven't attempted to prove you an idiot. To do so with any
authority, I would need to be a psychiatrist, which I'm not. What I
have attempted (successfully) to prove is that, in
struct tm *foo = calloc(1, sizeof *foo);
sizeof does not evaluate its operand (see one of my earlier articles
for the proof), and that sizeof's operand is not an argument
(again, see one of my earlier articles for the proof).
>> but here it is anyway. It proves you [insults deleted]
>
> Fuck you, liar.
Temper temper. If you think I'm lying about what the C Standard
says, check it yourself. I also invite anyone else to check it and
report back to see whether I've quoted it correctly. (My quote is
from the C89 draft. The C99 PDF may vary in slight detail, but it
says essentially the same thing.)
> I am not an idiot and no amount of "proof"
> otherwise posted by you will change that fact.
Fine, but that's not what I'm trying to prove.
> The only thing you're proving is that you're an asshole.
No, I'm proving that sizeof doesn't evaluate a struct tm operand,
and that sizeof's operand is not an argument.
<snip>
>> You have snipped the explanation I gave of why I considered you
>> to have missed my point.
>
> Because I was not interested in it.
It seems to me (and this is just my impression - I don't claim it as
an objective fact) that you aren't interested in anything that
might conceivably expose you to new information and new
perspectives and new way of thinking about things.
> Your conclusion was a negative
> statement about me and therefore could not possibly be correct.
Not true. Here's the explanation:
++++++ quote from previous article of mine ++++++
I repeat again - in the past, things often worked a
bit differently to the way they normally work now. Things changed,
so that they now work in what you probably think of as the only way
they're ever going to work. A more cautious attitude would be "if
they've changed before, they can change *again* - and if I program
according to the rules, I can to some extent protect my code
against such changes."
+++++++++++++++++++++++++++++++++++++++++++++++++
As everyone can see who reads this, the conclusion is that a
cautious attitude can help to protect code against changes in
architecture that were not envisioned at the time the code was
written.
<snip>
>>>>>> Fine, you're entitled to think that
>>>>> Don't patronize me.
>>>> Firstly, I told you before
>>> I said, don't patronize me. And what's the next thing you do?
>>> Patronize me!
>>
>> Firstly, no, I wasn't patronising you
>
> Yes you were. Twice. "Fine, you're entitled to think that" is
> patronizing, holier-than-thou, know-it-all bullshit.
No, it isn't. It's an acknowledgement, that's all. It is meant to be
an attempt to express recognition of your right to think that C is
for "systems-level stuff", whilst pointing out at the same time
that it is not a universally held opinion. If you see that as
patronising, well, that's your problem, not mine.
> "I told you before" is equally rude.
With your record of expletives and histrionics you are in no
position to be taken seriously on the subject of rudeness.
>> I was explaining to you.
>
> I do not need, or desire, any "explaining to" by you. It is
> patronizing and rude, not to mention incorrectly implies negative
> things about my intellect.
That's just bizarre. I cannot imagine any able programmer holding
such an attitude to explanations.
<snip>
>>>> I'm still treating you like an intelligent man
>>> Ordinarily, one does not treat intelligent men as shoddily as
>>> you've treated me.
>>
>> [calls me an idiot]
Poor editing. What I actually said was "Intelligent men do not react
in the way you react. I have therefore changed my opinion of you."
That is not the same as calling you an idiot.
> No, I am not. You, however, are a liar.
I have demonstrated, to a high standard of proof and in an objective
way, that you have lied at least once. Can you demonstrate
objectively that I have lied? (I know I haven't, so I know you
can't, but I'm interested in finding out whether you think you
can.)
>>> In particular, when an intelligent man requests
>>> that you drop a condescending tone,
>>
>> I haven't even reached for my condescending tone during this
>> whole conversation so far.
>
> Another lie, and calling me a liar to boot.
You don't seem to know what "lie" means. And yes, I've called you a
liar, but then I took the trouble to be sure of my ground before
doing so.
>
>>> or drop an entire line of questioning,
>>
>> I haven't /had/ a line of questioning.
>
> You have been questioning my intelligence, in public, practically
> from day one.
Wrong.
> I posted a harmless little aside and then you, who
> had never even met me before and had no prior involvement in this
> thread, jumped in and called me an idiot.
Wrong. I said you'd made a mistake about sizeof. Making a mistake is
not the same as being an idiot.
> Something is obviously
> the matter with you, but I'm damned if I know what, exactly, it
> is.
It's called "getting it right". It's a disease you should try some
time.
>
>> I've pointed out a mistake
>
> You've attacked me, viciously and without provocation.
Nonsense.
> I. Do. Not. Make. Mistakes.
Yeah, right. And I'm Elvis.
<wow, already line 346 as I write - let's do a BIG ol' snip for as
long as it's just same ol' same ol'>
<snip>
> I have every right to defend myself when publicly slandered,
Written defamation is libel, not slander - and I haven't either
libelled you or slandered you.
> and
> you have no right to threaten me for doing so. Do I make myself
> clear?
Nor have I threatened you. No, you don't make yourself clear,
because you don't stick to the facts.
> That can proceed by one of two ways: I convince you to shut up, or
> I force you to shut up. Apparently I can't convince you to shut
> up. So I guess I'm going to have to have a little chit-chat with
> the abuse department at your ISP.
Feel free. There are two possible outcomes: (a) they think you're
being a twit, in which case they'll ignore you, or (b) they'll take
your side, in which case I'll move ISP (which I was thinking about
doing in any case, and this would certainly tip the balance).
> What about? Well, there seem to
> be quite a lot of off-topic posts in several comp.* newsgroups
> lately, and Richard Heathfield seems to be the author of dozens of
> them ...
I am also the author of many thousands of highly topical articles.
How do your percentages look?
> Failing that, I guess I'll have to get lawyers involved.
A bright, honest lawyer will advise you not to be so daft. I can
demonstrate that you lied. That won't look good to a jury.
<snip>
>> I'm trying to discuss the original subject matter
>
> You are not. Otherwise you would have no objections to discussing
> the original subject matter WHILE LEAVING MY NAME, and your
> opinion of me, OUT OF IT.
I've hardly mentioned your name. In the attribs, sure, but that's
because I'm /supposed/ to attribute material that I quote. Apart
from that, I don't think I've mentioned it to excess. As for my
opinion of you, I have spared you that, at least.
<snip>
>>> I'm interested in two things:
>>>
>>> 1. Shutting down this unwelcome and off-topic inquiry into the
>>> status of my mental functioning, and
>>
>> But I have made no such enquiry.
>
> You have too, liar.
No, I haven't. Really I haven't. I'm not *interested* in the
"status", as you call it, of your mental functioning.
>> It is not I who turned this discussion of sizeof into a slanging
>> match.
>
> A ridiculous claim, when your very first post in response to any
> post of mine was a slap right across the face.
No, it was a technical correction.
> You do know that
> Google Groups archives your posts, right, and that it's easy for
> anyone to verify that your first post was a slap?
I know that Google Groups archives articles, yes. So it's easy for
anyone to verify that my first response to you was a technical
correction. Here it is again:
"Firstly, the preferred idiom is:
struct tm *foo = calloc(sizeof *foo);
which (for all types other than void *, for which sizeof is a bit
pointless anyway) survives a foo type change without editing.
Secondly, although all-bits-zero does indeed represent 0.0 or NULL
on many platforms, it is not guaranteed by the C Standard so to do.
Those who must cater for unusual platforms cannot necessarily rely
on calloc to initialise all members to 0-of-the-correct-type for
them."
And, further down:
"I've worked in environments like that, and found it quite
workable."
I see no slap here.
> I have to ask,
> because you seem to think that maybe you can somehow fool people
> into actually believing you didn't start the slapping match.
See above.
>>> 2. Getting an apology, if one might be forthcoming, though I
>>> will
>>> settle for complete silence instead.
>>
>> You certainly won't get an apology, because I don't make a habit
>> of apologising for being right
>
> But you were entirely, 100% wrong about me.
In your opinion, perhaps. In my opinion, I was 100% right about
sizeof, which is what I've been discussing. All this extraneous
guff is of no consequence to me whatsoever.
<snip>
>> The subject is sizeof.
>
> The subject is your opinions of me.
So you appear to think. But I'm not really fussed about you. I am,
however, fussed about sizeof.
> I couldn't care less about
> sizeof at this point.
Perhaps you should. It would be a lot more interesting.
<snip>
>>> If you continue to publicly insinuate various unpleasant things
>>> about my mental functioning, you will be in for a world of shit.
>>
>> Firstly, what you infer is your responsibility, not mine. I have
>> actually said very little about you in this thread,
>
> but implied a great deal.
Look up "imply". Where my statements are concerned, I get to choose
what I imply. Where my statements are concerned, you only get to
choose what you infer. You can imply what you like when you make
statements, but I cannot justifiably claim that you have implied
something in those statements. I can reasonably infer something
from them, but that's as far as I can go. Same applies to you.
Writer chooses what he implies, reader chooses what he infers.
<snip>
>>> and will likely lose your usenet access in the bargain.
>>
>> That isn't going to happen, for at least two reasons:
>>
>> 1) I haven't done anything wrong, as the record will show;
>
> You have posted a large number of off-topic posts to at least
> three Usenet newsgroups.
I have posted a HUGE number of *topical* articles to several
newsgroups.
>> 2) Nowadays, ISPs mostly don't care anyway, not even about spam -
>> they should, but they don't.
>
> Well, let me enlighten you:
>
> INTRODUCTION - ACCEPTABLE USE POLICY (AUP)
>
<snip>
> You must not send, with the intention of causing annoyance,
> inconvenience or needless anxiety a message that you know to be
> false, or to cause such a message to be sent
>
> [Bright-line violation here.]
Wrong. I have sent no such message, nor have I caused such a message
to be sent.
> or to persistently make use of our service for that purpose.
>
> [And here.]
Wrong again.
<snip>
> You must not infringe the rights of others, including the right of
> privacy and copyright (an example would be sharing without
> permission of the copyright owner protected material such as a
> music or video file).
>
> [Arguably, posting about me publicly after repeated requests to
> [stop violates my right of privacy.]
Wrong. Posting in a public forum noted for discussions is
effectively an invitation to have a discussion.
<snip>
> Reports of breaches of these acceptable use policies by BT
> customers can be sent to ·····@btbroadband.com
>
> [On its way already.]
If anything comes of it, I shall lodge a complaint with BT. If that
is not resolved satisfactorily, I will change my ISP, and take such
other steps as I feel are appropriate. But I doubt very much
whether anything will come of it.
<snip>
>>> It's your choice.
>>
>> I choose to discuss sizeof
>
> Yet you did not.
Sheesh, can't you read?
<snip>
>> Pointing out that you are [insult deleted]
(the "insult" was the word "mistaken")
> I am not.
You are certainly mistaken about sizeof.
>> is not the same as saying you are stupid or incompetent.
>
> Sure it is. It implies that one or the other must be the case.
No, sir, it does not. Firstly, look up "imply", since I have no
desire to explain it to you again. Secondly, people make mistakes
all the time without it meaning they are stupid or incompetent. I
make lots of mistakes, but I'm not so stupid as to pretend I didn't
make them or that they are someone else's fault. Nor am I so stupid
as to try to cover them up and blame other people for pointing them
out.
>> Nor do you get to decide what I imply.
>
> I'm not deciding what you implied. I'm just making an observation
> about what you implied.
But the implication you claim simply isn't there.
>> If you wish to infer in front of a large audience that you are
>> stupid
>
> I have done nothing of the sort,
While you're looking up "imply", look up "if". If your dictionary is
small enough, it might even be on the same page, which will save
some time.
> and the mere insinuation otherwise is a lie.
Just look up "if". You might want to look up "insinuate" while
you're at it. It doesn't apply here.
> In fact, I have strenuously *denied* being stupid.
Just denying it doesn't make it false. It doesn't make it true
either.
>
>>>>> What the hell is the MATTER with you?
>>>> Nothing, really. What is the matter with you
>>> Nothing. And that is final.
>>
>> Except that [insult deleted]
Context: the "insult", in full, was "Except that you still don't
understand sizeof". That's not an insult. It's just a statement of
fact.
> No.
If that means you agree, no, you don't understand sizeof, then okay.
If it means you disagree, i.e. no, you /do/ understand sizeof, then
all I can say is that you have not demonstrated such understanding
in this thread.
<snip>
>> If you're looking for some kind of resolution, there probably
>> won't be one
>
> Is that a threat?
No, it's just an observation based on a decade or so of Usenet
experience.
<snip>
>>>>> You made several nasty errors:
>>>>> 2. Then when I responded to smooth things over,
>>>> I don't recall your trying to smooth things over.
>>> Yes. In <································@bt.com> you nitpicked
>>> me,
>>
>> [calls me a liar]
>
> No, you're the liar.
This is unbelievable. I didn't call you a liar (at this point in the
discussion); I merely demonstrated you to be wrong. Calling me a
liar is pointless, because what I said is evidently true. See the
above message ID (which you quote above), and it will be evident to
anyone who reads it that the article is a note of thanks to Ben
Bacarisse for nitpicking me.
>
>>> apparently unaware that the correct response to my post was to
>>> either leave it alone or agree.
>>
>> [calls me a liar]
You might want to look up "liar", too, since it's pretty obvious
that you don't know what it means.
> No, you're the liar.
See above.
>
>>> In <············@news.eternal-september.org> I responded in such
>>> a way that you could have just left that post to stand
>>> unmolested and everything would have been fine. Instead, you
>>> attacked and here we are now.
>>
>> In that article, you screwed up
>
> I DID NOT.
Did too. Sheesh, man, I've /proved/ it, and so have one or two other
people.
<snip>
> I think you don't even know your own mind very well.
>
>>>>> you replied with
>>>>> a more direct and serious attack instead of letting
>>>>> sleeping dogs lie. Big mistake.
>>>> Again, got a msg-ID?
>>> Yes: <································@bt.com>
>>
>> That's not a serious attack.
>
> I'll be the judge of that.
Obviously you can decide for yourself whether you consider it a
serious attack. But you can't decide on other people's behalf.
>
>> [calls me a liar]
>
> Says the liar.
Look up "liar" again.
[The next statement refers to
<································@bt.com> which is a technical
rebuttal of a mistaken claim about sizeof]
>>> This you should definitely never have posted.
>>
>> Why not?
>
> Because it implied vicious lies about me, doofus. Why else?
But it doesn't. It's just a technical rebuttal.
<snip>
>> If you want to suppress discussion of a subject you find
>> uncomfortable, telling people not to discuss it is simply the
>> wrong strategy.
>
> Oh? Then what, in your *opinion*, WOULD be the right strategy?
Not taking technical corrections as a personal affront would be a
great start. If I did that, I'd have been mortally offended a
thousand times over by now. Sheesh.
<snip>
> I think you should be thinking "worth trying to put things in a
> way that preserves both sides' dignity", don't you? Or does the
> dignity of other people not concern you?
It is up to you to preserve your dignity, and it is up to me to
preserve mine. I am quite happy with mine, thank you.
<snip>
>>> I repeat: I am not interested in your opinion of me. Neither is
>>> anyone else. Don't. Post it. Again.
>>
>> I repeat: you don't get to control my actions.
>
> That's a definite threat to badmouth me in public.
No, it's a statement that I'm not about to kowtow to your demands.
You are not my boss, my wife, or my monarch. Like any reasonable
man, I am amenable to persuasion. You're not trying to persuade me,
however; you're trying to force me. That doesn't work.
> I don't respond well to threats.
I haven't threatened you. Nor will I. I don't do threats.
<snip>
> Shut up or else. I WILL have the last word. Do not defend yourself
> dammit!
That was selective quotation on my part. I admit it freely. I did it
for a reason - to attempt to demonstrate to you why it is
considered an unfair debating trick. It is a trick you use a lot.
<snip>
>> I suspect that you are probably not an idiot
>
> So, at last you admit the truth!
I have yet to be completely convinced, however.
>
>>> How would you like it if someone put "Richard Heathfield is an
>>> idiot" on there?
>>
>> If you posted such a comment on Usenet, you would not be the
>> first. And I would not react by trying to stop you from posting.
>
> What if I didn't do it just once, but again and again and again,
> and explicitly expressed an intention to do so again every single
> time you posted to protest that you were not one?
What if you did? It would say more about you than it did about me.
If you did that, after a while I would probably just killfile you.
> Then what would you do?
Like I said, probably killfile you.
>> Instead, I'd try to find out why you thought I was an idiot, and
>> then I'd explain why it wasn't the case.
>
> Been there, done that, didn't work.
As far as I can recall at present, I haven't actually called you an
idiot even once. (It's possible that I am mistaken about that.) But
I certainly haven't done it over and over. What I *have* done is
pointed out that you have demonstrated at least two separate
misunderstandings about the nature of sizeof. You seem to equate
this with calling you an idiot, which is rather a bizarre way to
interpret it.
<snip>
>> You get to choose what you do.
>
> And I choose not to have my name mentioned in this any more.
If you wish to refrain from mentioning your name, that's fine. You
don't get to choose what other people do, however. Usenet
convention requires me to attribute quotations, and I choose to do
so by using the originator's name. That's my choice, not yours.
> You keep picking fights but you're just
> *terrible* at flaming!
I haven't started flaming. Nor will I. Losing one's temper (e.g.
resorting to expletives) is normally a sign that one has no
rational arguments.
>>> For it to have been a *personal* attack it would have had to
>>> imply something negative about some specific *person*.
>>
>> Even granting for the sake of argument (and without prejudice to
>> future dispute) that this definition is correct, how is my
>> [implication that Seamus MacRae is an idiot] a "personal attack"?
Original text: "how is my explanation of sizeof a "personal
attack"?"
>
> That you even asked the question speaks volumes about YOUR
> intelligence.
Well, no - it's an obvious question with no obvious answer other
than "hey, look, it isn't a personal attack after all".
>>>>> Saying that environments
>>>>> that ignore a lot of compiler warnings generate buggy code is
>>>>> not an attack on any particular person.
>>>> Who said anything about ignoring compiler warnings?
>>> You did.
>>
>> No
>
> Yes, you did.
I explained in crystal clear detail why filtering selected warnings
is not the same as ignoring them.
<snip>
>>> have the last word in any discussion, and generally shove your
>>> weight around. How old are you, about three?
>>
>> Even older than three. In fact, I'm all gwowed-up now
>
> That's a laugh. I'm guessing no more than about seven.
And I started posting to Usenet three or four years before I was
born. Right.
<snip>
>> Or are you determined to follow your self-destructive path?
>
> Another threat!
While you've got the dictionary out, look up "self".
> My my! Perhaps I should be calling the police now,
> and nevermind my lawyer or your ISP's abuse department. Your
> implication now is that you intend to drive me to suicide!
At this point I can only conclude that you're laughing your socks
off because you're actually trolling. The alternative - that you
are certifiably insane - does not bear thinking about.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p5fi$duc$1@news.eternal-september.org>
Richard Heathfield wrote:
> I am beginning to think that Seamus MacRae is trolling.
I am not.
You, on the other hand, have posted a ridiculously long attack post
after promising to stop doing that. You are a liar and a hypocrite.
> In fact, I hope he is, because if
> he's serious I am rather worried about him.
An implied insult of my mental health. Well, we're off to a great start,
aren't we? Looks like he does indeed intend to "prove" his points by
that age-old method, argumentum ad hominem.
>>>> Then please drop this.
>>>>
>>>> NOW!!!
>> You forgot to drop it. Sorry, please hang up and try again.
>
> You forgot
I forget nothing, liar.
>> You are in error about me.
>
> I don't think so
Yet you are.
>>>>>> Next time, do not "debunk" unsolicited.
>>>>> If you don't wish for mistakes in your articles to be
>>>>> corrected, you have two choices - (a) don't make mistakes, or
>>>>> (b) don't post them.
>>>> I go for option (a), always.
>>> [calls me a liar]
>> You are in error about me.
>
> You are in error
I am not.
>> You are in error about me.
>
> Assertion is not argument.
That applies equally to you. Your bald assertions that I'm stupid,
mentally ill, or what-have-you are equally unconvincing, either about
the thing asserted or about whatever the original bone of contention was.
> Can you *demonstrate* that I'm in error about you?
I do *that* every time I make another erudite, fairly polite, reasoned
response to your latest outpouring of fuming vitriol. An idiot obviously
could not accomplish such a feat; the erudition would surely be lacking,
and the reason. Nor could a nutcase; the retention of calm, polite
level-headedness would not be possible in that case.
>> The problem is the thing you apparently want to teach to the
>> world: "Seamus MacRae is an idiot".
>
> That seems to be apparent only to you.
If you're saying you hope nobody else has seen through you to your real
motives, well, I'm sorry to say people tend to be smarter than you give
them credit for.
>> It is, of course, incorrect,
>
> Can you demonstrate this?
Argumentum ad hominem is never a logically-valid form of argument.
>>>> Well, now that you're aware of the possibility, you should know
>>>> to just quietly move on now.
>>> This is Usenet. I don't have to move anywhere.
>> Yes, you do.
>
> Why?
Because your attack posts are off-topic here.
>> Have you forgotten that whether or not Seamus MacRae
>> is an idiot is irrelevant to all three newsgroups you're spewing
>> your crap into?
>
> I'm not actually *interested* in whether you're an idiot.
So you keep saying, unconvincingly.
>> And your occasional asides about C are irrelevant
>> to two of them.
>
> That is actually quite true.
>
>>> What do /you/ mean by the metaphor "move on"? Do you mean
>>> "quietly forget that Seamus MacRae [insults deleted]"
>> I mean stop posting about Seamus MacRae. Period. Do not mention me
>> again, in public, indirectly or directly, ever again.
>
> [threat deleted]
I don't respond well to threats, as you are so fond of saying.
>>>>> I think you're confusing
>>>> I am not.
>>> Then you must be confused.
>> I just told you: I am not.
>
> As we have already seen, just because you say something, that
> doesn't necessarily make it true.
Wrong again. I am not a liar, nor am I an idiot, nor am I "confused".
>>> I used the word in passing (in what I consider to be a legitimate
>>> way
>> There is no "legitimate way" to call a stranger an idiot loudly in
>> a print medium.
>
> To say "I think you're confusing X with Y" is perfectly legitimate
No, it is not, and repeatedly asserting otherwise does NOT constitute a
logical argument in favor of your position that you should be permitted
to publicly insult anyone you please.
>>> [...elided...] I'm interested in sizeof.
>> I'm not.
>
> Then why express an opinion on it?
I did not. I stated certain facts about myself, such as that I am not an
idiot, that you keep attacking.
>>>> Drop it.
>>> You don't get to control my actions, remember?
>> Are you threatening to publicly badmouth me some more?
>
> Mu.
Nonsensical response.
>> Do I need to get a lawyer involved in this?
>
> A good lawyer would advise you not to be so daft [rest of insult
> and threat deleted]
I am not an idiot. Furthermore, I do not respond well to threats.
>>>>>> Regardless, it's been drilled in repeatedly: if "*foo" is
>>>>>> encountered when foo is uninitialized, Bad Things may happen.
>>>>> Sure - but this isn't *foo; it's sizeof *foo
>>>> Which contains *foo as an argument, for heaven's sake.
>>> No, it doesn't.
>> Yes, it does. We have an occurrence of the structure "operator
>> argument". This is clear to anyone that isn't blind.
>
> Ah, an attempt at a technical argument. Well, pretend I'm blind, and
> explain why your theory overrides ISO/IEC 9899's position on the
> matter, which is that an argument occurs only in a function call or
> a function-like macro invocation.
You're attempting to reject a technical comment with semantic
word-games. Making some sort of fine distinction among "argument",
"operand", &c. is pointless hair-splitting and is not valid argumentation.
>>> I know from experience that you don't take a lot of notice of
>>> proof
>> I don't take a lot of notice of flawed arguments purporting to
>> prove me an idiot, you mean. Because I know for a fact that I am
>> not an idiot.
>
> But I haven't attempted to prove you an idiot.
Sure you have. You haven't *succeeded* mind you, and you never will, but
that isn't stopping you from trying.
> What I have attempted (successfully) to prove is that [Seamus MacRae
> is an idiot]
Attempted, yes, successfully no.
>>> but here it is anyway. It proves you [insults deleted]
>> Fuck you, liar.
>
> Temper temper.
You try being even half as patient as I have been when every time you
check newsgroups there is ANOTHER 3000-line-long paean to what an idiot
you supposedly are, cross-posted irrelevantly to three public newsgroups
and in need of an equally-public, detailed rebuttal!
>> I am not an idiot and no amount of "proof"
>> otherwise posted by you will change that fact.
>
> Fine
Then you're giving up now? Hooray!
>> The only thing you're proving is that you're an asshole.
>
> No
Oh, yes, you are.
>>> You have snipped the explanation I gave of why I considered you
>>> to have missed my point.
>> Because I was not interested in it.
>
> It seems to me (and this is just my impression - I don't claim it as
> an objective fact) that you aren't interested in anything that
> might conceivably expose you to new information and new
> perspectives and new way of thinking about things.
Just your impression, and a wrong one, too. What I am not interested in
is anything that might conceivably trick a public audience into
believing something negative about me, which might in turn have negative
consequences for me if those people then treat me differently, and
worse, because of that.
Well, by that I mean I'd rather not see any such thing posted.
Obviously, once it is posted, I'm interested in it in the way one is
interested in any potential threat to one's well-being.
>> Your conclusion was a negative
>> statement about me and therefore could not possibly be correct.
>
> Not true.
No, you're the wrong one. No negative statement about me can ever be
correct.
>>>>>>> Fine, you're entitled to think that
>>>>>> Don't patronize me.
>>>>> Firstly, I told you before
>>>> I said, don't patronize me. And what's the next thing you do?
>>>> Patronize me!
>>> Firstly, no, I wasn't patronising you
>> Yes you were. Twice. "Fine, you're entitled to think that" is
>> patronizing, holier-than-thou, know-it-all bullshit.
>
> No, it isn't.
Yes, it is. It is a mock-respectful way of calling someone an idiot, in
point of fact.
>> "I told you before" is equally rude.
>
> With your record of expletives and histrionics
My record is irrelevant; we are discussing YOUR rudeness right now. My
not quite having saint-like patience for your constant, ludicrously-long
public berations is hardly a flaw, let alone license for you to be as
boorish as you have been, or a valid excuse to let you dodge an
accusation of rudeness slung your way.
>>> I was explaining to you.
>> I do not need, or desire, any "explaining to" by you. It is
>> patronizing and rude, not to mention incorrectly implies negative
>> things about my intellect.
>
> That's just bizarre. I cannot imagine any able programmer holding
> such an attitude to explanations.
Explanations in general, no. But the "explanations" from you are quite
another story.
It is one thing to explain to someone something new about programming
that they previously did not know. It is quite another to "explain" to
them something they already do know, only in a mutated form and implying
in the process that they are stupid or incompetent in some way. Talking
down to them like a teacher to a poorly-performing student and all that
is just icing on the rudeness cake.
>>>>> I'm still treating you like an intelligent man
>>>> Ordinarily, one does not treat intelligent men as shoddily as
>>>> you've treated me.
>>> [calls me an idiot]
>
> Poor editing.
No. You are the one doing things poorly here, not I. One problem is that
you keep trying to criticize me. If you were criticizing a target that
was actually deserving of criticism, that would be one thing, but
misdirecting it instead at me is definitely poor behavior.
>> No, I am not. You, however, are a liar.
>
> [calls me a liar]
No, you're the liar, remember?
>>>> In particular, when an intelligent man requests
>>>> that you drop a condescending tone,
>>> I haven't even reached for my condescending tone during this
>>> whole conversation so far.
>> Another lie, and calling me a liar to boot.
>
> You don't seem to know
Wrong!
>>>> or drop an entire line of questioning,
>>> I haven't /had/ a line of questioning.
>> You have been questioning my intelligence, in public, practically
>> from day one.
>
> [calls me a liar]
No, you're the liar, remember?
>> I posted a harmless little aside and then you, who
>> had never even met me before and had no prior involvement in this
>> thread, jumped in and called me an idiot.
>
> [calls me a liar]
No, you're the liar, remember?
>> Something is obviously the matter with you, but I'm damned if I
>> know what, exactly, it is.
>
> [calls me an incompetent idiot]
Wrong!
>> You've attacked me, viciously and without provocation.
>
> [calls me a liar]
No, you're the liar, remember?
>> I. Do. Not. Make. Mistakes.
>
> [calls me a liar]
No, you're the liar, remember?
>> I have every right to defend myself when publicly slandered,
>
> [calls me a liar]
No, you're the liar, remember?
>> and you have no right to threaten me for doing so. Do I make
>> myself clear?
>
> [calls me a liar twice]
No, you're the liar, remember?
>> That can proceed by one of two ways: I convince you to shut up, or
>> I force you to shut up. Apparently I can't convince you to shut
>> up. So I guess I'm going to have to have a little chit-chat with
>> the abuse department at your ISP.
>
> [insult deleted]
Wrong!
>> What about? Well, there seem to be quite a lot of off-topic posts
>> in several comp.* newsgroups lately, and Richard Heathfield seems
>> to be the author of dozens of them ...
>
> I am also the author of many thousands of highly topical articles.
For which I have only your word.
> How do your percentages look?
So I'm a recent user, who lurked until a few months ago. Is that some
sort of a crime? The fact is, I have posted on topic except for direct
rebuttals when publicly badmouthed.
>> Failing that, I guess I'll have to get lawyers involved.
>
> A bright, honest lawyer will advise you not to be so daft.
Namecalling again. That appears to be your answer to everything. How
disappointing.
>>> I'm trying to discuss the original subject matter
>> You are not. Otherwise you would have no objections to discussing
>> the original subject matter WHILE LEAVING MY NAME, and your
>> opinion of me, OUT OF IT.
>
> I've hardly mentioned your name.
Explicitly? No. But you keep implying nasty things about me, when you're
not saying them outright.
>>>> I'm interested in two things:
>>>>
>>>> 1. Shutting down this unwelcome and off-topic inquiry into the
>>>> status of my mental functioning, and
>>> But I have made no such enquiry.
>> You have too, liar.
>
> [calls me a liar]
No, you're the liar, remember?
>>> It is not I who turned this discussion of sizeof into a slanging
>>> match.
>> A ridiculous claim, when your very first post in response to any
>> post of mine was a slap right across the face.
>
> [calls me a liar]
No, you're the liar, remember?
>> You do know that Google Groups archives your posts, right, and that
>> it's easy for anyone to verify that your first post was a slap?
>
> [calls me a liar]
No, you're the liar, remember?
Google does, indeed, archive posts. Shocker, innit?
>>>> 2. Getting an apology, if one might be forthcoming, though I
>>>> will settle for complete silence instead.
>>> You certainly won't get an apology, because I don't make a habit
>>> of apologising for being right
>> But you were entirely, 100% wrong about me.
>
> In your opinion, perhaps.
In actual fact. I've had my IQ measured. I will state for the record
that it was not less than 100. Furthermore, my every post is evidence
that I possess the vocabulary and education of a non-idiot.
>>> The subject is sizeof.
>> The subject is your opinions of me.
>
> [calls me a liar]
No, you're the liar, remember?
>> I couldn't care less about sizeof at this point.
>
> Perhaps you should.
Nah.
>>>> If you continue to publicly insinuate various unpleasant things
>>>> about my mental functioning, you will be in for a world of shit.
>>> Firstly, what you infer is your responsibility, not mine. I have
>>> actually said very little about you in this thread,
>> but implied a great deal.
>
> Look up "imply".
More condescension and rudeness. You made statements with the property
that anyone taking them at face value would infer that I was stupid. In
particular, you have repeatedly criticized me. That is incorrect behavior.
>>>> and will likely lose your usenet access in the bargain.
>>> That isn't going to happen, for at least two reasons:
>>>
>>> 1) I haven't done anything wrong, as the record will show;
>> You have posted a large number of off-topic posts to at least
>> three Usenet newsgroups.
>
> I have posted
You have posted a large number of off-topic posts to at least three
newsgroups.
>> You must not send, with the intention of causing annoyance,
>> inconvenience or needless anxiety a message that you know to be
>> false, or to cause such a message to be sent
>>
>> [Bright-line violation here.]
>
> [calls me a liar]
No, you're the liar, remember?
Several posts ago I made it quite apparent to you that your posting
these very long and insulting posts of yours causes me annoyance and
inconvenience at the very least.
You have since continued to make more such posts. Those posts were made
with the full knowledge of these effects, so even if you claim the
earlier ones were not intended to cause those effects, the later ones
certainly were.
As for the messages being false, as I noted above, I had my IQ measured
and I've demonstrated vocabulary and education beyond what is attainable
by idiots, and therefore your repeated insinuations about my intellect
have been soundly disproven.
>> or to persistently make use of our service for that purpose.
>>
>> [And here.]
>
> [calls me a liar]
No, you're the liar.
I'd call your obsessive replying to all of my posts, and to many other
posts by the likes of Kaz and Thomas, with more reams and reams of
insults, "persistent", and I bet your ISP's abuse department would, too.
>> You must not infringe the rights of others, including the right of
>> privacy and copyright (an example would be sharing without
>> permission of the copyright owner protected material such as a
>> music or video file).
>>
>> [Arguably, posting about me publicly after repeated requests to
>> stop violates my right of privacy.]
>
> [calls me a liar]
No, you're the liar, remember?
I have, indeed, requested repeatedly that you not discuss me in public
(explicitly or by insinuation) any more, and yet you keep doing so.
> If anything comes of it, I shall lodge a complaint with BT. If that
> is not resolved satisfactorily, I will change my ISP, and take such
> other steps as I feel are appropriate.
That last part reads as a threat to me.
>>>> It's your choice.
>>> I choose to discuss sizeof
>> Yet you did not.
>
> [calls me an idiot]
Wrong!
>>> Pointing out that you are [insult deleted]
>> I am not.
>
> [calls me a liar]
No, you're the liar, remember?
>>> is not the same as saying you are stupid or incompetent.
>> Sure it is. It implies that one or the other must be the case.
>
> [calls me a liar]
No, you're the liar, remember?
>>> Nor do you get to decide what I imply.
>> I'm not deciding what you implied. I'm just making an observation
>> about what you implied.
>
> [calls me a liar]
No, you're the liar, remember?
>>> If you wish to infer in front of a large audience that you are
>>> stupid
>> I have done nothing of the sort,
>
> [insult deleted]
Wrong!
>> and the mere insinuation otherwise is a lie.
>
> [calls me a liar]
No, you're the liar, remember?
>> In fact, I have strenuously *denied* being stupid.
>
> [calls me a liar]
No, you're the liar, remember?
>>>>>> What the hell is the MATTER with you?
>>>>> Nothing, really. What is the matter with you
>>>> Nothing. And that is final.
>>> Except that [insult deleted]
>
> [calls me an idiot]
Wrong!
>> No.
>
> If that means you agree, [that I'm an idiot]
I do not.
> [calls me a liar]
No, you're the liar, remember?
>>> If you're looking for some kind of resolution, there probably
>>> won't be one
>> Is that a threat?
>
> [calls me a liar]
No, you're the liar, remember?
>>>>>> You made several nasty errors:
>>>>>> 2. Then when I responded to smooth things over,
>>>>> I don't recall your trying to smooth things over.
>>>> Yes. In <································@bt.com> you nitpicked
>>>> me,
>>> [calls me a liar]
>> No, you're the liar.
>
> This is unbelievable.
Yes it is. You are very, very repetitive. Are you sure you're not a bot?
> [calls me a liar repeatedly]
No, you're the liar, remember?
>>>> apparently unaware that the correct response to my post was to
>>>> either leave it alone or agree.
>>> [calls me a liar]
>
> [calls me an idiot]
Wrong!
>> No, you're the liar.
>
> [calls me a liar]
No, you're the liar, remember?
>>>> In <············@news.eternal-september.org> I responded in such
>>>> a way that you could have just left that post to stand
>>>> unmolested and everything would have been fine. Instead, you
>>>> attacked and here we are now.
>>> In that article, you screwed up
>> I DID NOT.
>
> [calls me a liar]
No, you're the liar, remember? And you're the screwup, too.
>>>>>> you replied with
>>>>>> a more direct and serious attack instead of letting
>>>>>> sleeping dogs lie. Big mistake.
>>>>> Again, got a msg-ID?
>>>> Yes: <································@bt.com>
>>> That's not a serious attack.
>> I'll be the judge of that.
>
> Obviously you can decide for yourself whether you consider it a
> serious attack.
Well, there you go, then.
>>> [calls me a liar]
>> Says the liar.
>
> [calls me a liar]
No, you're the liar, remember?
> [The next statement refers to
> <································@bt.com> which [calls me
> an idiot]]
And therefore was wrong.
>>>> This you should definitely never have posted.
>>> Why not?
>> Because it implied vicious lies about me, doofus. Why else?
>
> But
But nothing. It implied vicious lies about me.
>>> If you want to suppress discussion of a subject you find
>>> uncomfortable, telling people not to discuss it is simply the
>>> wrong strategy.
>> Oh? Then what, in your *opinion*, WOULD be the right strategy?
>
> [implied insults deleted]
My mental health is fine, thanks.
Please try again. And this time, don't snip the all-important
postcondition. You should know better than to ignore key parts of a
requirements document!
Here it is again:
>> Oh? Then what, in your *opinion*, WOULD be the right strategy?
>> Postcondition: after the strategy is executed, the "discussion"
>> has stopped and no negative claim about me stands unchallenged
>> -- all have at least one followup, in all of the same newsgroups,
>> asserting that the insults targeted at me are 100% erroneous and
>> I'm really a great guy despite what some schmuck said.
Please do at least try to get it right this time.
>> I think you should be thinking "worth trying to put things in a
>> way that preserves both sides' dignity", don't you? Or does the
>> dignity of other people not concern you?
>
> It is up to you to preserve your dignity
The problem is that you are making a concerted effort to prevent me from
doing so.
>>>> I repeat: I am not interested in your opinion of me. Neither is
>>>> anyone else. Don't. Post it. Again.
>>> I repeat: you don't get to control my actions.
>> That's a definite threat to badmouth me in public.
>
> [calls me a liar]
No, you're the liar, remember?
>> I don't respond well to threats.
>
> [calls me a liar]
No, you're the liar, remember?
>> Shut up or else. I WILL have the last word. Do not defend yourself
>> dammit!
>
> That was selective quotation on my part. I admit it freely.
Well, there you go, then.
> [calls me a liar]
No, you're the liar, remember? As you've just admitted.
>>> I suspect that you are probably not an idiot
>> So, at last you admit the truth!
>>>> How would you like it if someone put "Richard Heathfield is an
>>>> idiot" on there?
>>> If you posted such a comment on Usenet, you would not be the
>>> first. And I would not react by trying to stop you from posting.
>> What if I didn't do it just once, but again and again and again,
>> and explicitly expressed an intention to do so again every single
>> time you posted to protest that you were not one?
>
> What if you did? It would say more about you than it did about me.
> If you did that, after a while I would probably just killfile you.
With no concern whatsoever for the effects on other people? We have
already seen evidence that the various lies being spread about me are
beginning to sway others, and that's WITH my efforts to neutralize their
effects. I can only imagine how much worse things would be if you, and
the others like you, were spouting as much filthy nonsense about me
without any visible opposition. People might even take my silence as a
guilty one.
>> Then what would you do?
>
> Like I said, probably killfile you.
Perhaps you should do that anyway and save us both a lot of grief.
>>> Instead, I'd try to find out why you thought I was an idiot, and
>>> then I'd explain why it wasn't the case.
>> Been there, done that, didn't work.
>
> As far as I can recall at present, I haven't actually called you an
> idiot even once.
You've suggested, insinuated, and otherwise pushed that viewpoint dozens
of times by now, if not hundreds. Every time you've publicly criticized
anything I wrote, for starters.
> What I *have* done is pointed out that you [are an idiot]
See? There you go again. But I am not actually an idiot, so you are
wrong again. Or perhaps lying again.
>>> You get to choose what you do.
>> And I choose not to have my name mentioned in this any more.
>
> [attempt at sophistry deleted]
You cannot excuse the fact that you continue to publicly smear my name
despite my wishes and your own claim that I have the absolute and
inalienable right to have those particular wishes granted.
>> You keep picking fights but you're just
>> *terrible* at flaming!
>
> [insult deleted]
Rational? You? That's a laugh.
>>>> For it to have been a *personal* attack it would have had to
>>>> imply something negative about some specific *person*.
>>> Even granting for the sake of argument (and without prejudice to
>>> future dispute) that this definition is correct, how is my
>>> [implication that Seamus MacRae is an idiot] a "personal attack"?
>> That you even asked the question speaks volumes about YOUR
>> intelligence.
>
> [calls me a liar]
No, you're the liar, remember?
>>>>>> Saying that environments
>>>>>> that ignore a lot of compiler warnings generate buggy code is
>>>>>> not an attack on any particular person.
>>>>> Who said anything about ignoring compiler warnings?
>>>> You did.
>>> No
>> Yes, you did.
>
> [calls me a liar]
No, you're the liar, remember?
>>>> have the last word in any discussion, and generally shove your
>>>> weight around. How old are you, about three?
>>> Even older than three. In fact, I'm all gwowed-up now
>> That's a laugh. I'm guessing no more than about seven.
>
> [calls me a liar]
No, you're the liar, remember?
>>> Or are you determined to follow your self-destructive path?
>> Another threat!
>
> [calls me an idiot]
Wrong!
>> My my! Perhaps I should be calling the police now,
>> and nevermind my lawyer or your ISP's abuse department. Your
>> implication now is that you intend to drive me to suicide!
>
> At this point I can only conclude that you're laughing your socks
> off because you're actually trolling. The alternative - that you
> are certifiably insane - does not bear thinking about.
I am neither trolling nor insane.
And here is a bit you forgot to address:
>>>> What I don't understand is why you seem to be insistent that that
>>>> happen, and that I not be permitted to speak up in my own defense?
>>>
>>> Of course you are permitted to speak up in your own defence.
>>
>> Yet you keep telling me not to do so, threatening me with dire
>> consequences (such as more insults by you) if I do do so, and
>> insulting me whenever I do do so.
>>
>> You certainly don't *seem* to want me to do so, at least not and
>> have my defense stand unchallenged.
>>
>> (You could prove that wrong, of course, by simply not replying to
>> this post.)
By replying to that post, you of course proved me right and yourself
wrong, when you could have easily done the opposite.
It is apparent that not only am I NOT an idiot, I am in fact of greater
intelligence than yourself, and therefore you are outmatched in this
contest. You may as well just give up now, since you're getting your ass
handed to you.
On Jun 10, 3:35 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
>
> Then you're giving up now? Hooray!
>
No, there's your problem. C.L.L will always be talking about your
fascist crimes and mental malfunctions, so you're basically stuck here
forever, wasting 10 hours or so a week for the rest of your life
responding to the group.
Even if this thread goes away, we'll be sure to bring you up, laugh
behind your back every couple months or so.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <tdCdnS6cp-qXPa3XnZ2dnUVZ8k6dnZ2d@bt.com>
MarkH said:
> On Jun 10, 3:35 pm, Seamus MacRae <··········@live.ca.invalid>
> wrote:
>
>>
>> Then you're giving up now? Hooray!
>
> No, there's your problem.
His problems appear to be many and varied. That's just /one/ of his
problems, and not even remotely the most significant one as far as
comp.programming is concerned. No, his problems are that he doesn't
understand sizeof, he doesn't understand arguments, and now it has
become clear that he doesn't understand variable-length arrays. He
exposes his ignorance further with every denial thereof.
Funny thing is - *I* don't understand VLAs (in the C99 context)
either. I haven't bothered to study them, because they seem pretty
pointless to me - they can't do anything for me that I can't do
already without them - but even I know you can't stick one in a
struct.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u7ts$e3l$1@news.eternal-september.org>
Richard Heathfield wrote:
> MarkH said:
>> On Jun 10, 3:35 pm, Seamus MacRae <··········@live.ca.invalid>
>> wrote:
>>
>>> Then you're giving up now? Hooray!
>> No, there's your problem.
>
> His problems appear to be many and varied.
Yes, and these problems have names:
Richard Heathfield
MarkH
Ben Pfaff
Thomas Mertes
Lars Enderin
Nick Keighley
Paul Donnelly
Duane
Kaz Kylheku
ChrisF
Ten of you against one of me. Not very nice odds, or very fair play, is it?
Then again, that changes quickly when the team captain didn't pick
carefully and went instead for quantity over quality, with the result
that one or two of 'em are prone to scoring own-goals via Godwin's Law.
I *like* those odds!
> No, his problems are that [vicious insults deleted]
No, I have none of the claimed problems. The incompetents are all on
your side, particularly those teammates of yours that keep scoring those
inconvenient own-goals.
On Jun 12, 9:48 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
> Richard Heathfield wrote:
> > MarkH said:
> >> On Jun 10, 3:35 pm, Seamus MacRae <··········@live.ca.invalid>
> >> wrote:
>
> >>> Then you're giving up now? Hooray!
> >> No, there's your problem.
>
> > His problems appear to be many and varied.
>
> Yes, and these problems have names:
>
> Richard Heathfield
> MarkH
> Ben Pfaff
> Thomas Mertes
> Lars Enderin
> Nick Keighley
> Paul Donnelly
> Duane
> Kaz Kylheku
> ChrisF
I didn't make the list???
I guess I need to practice my trollbaiting, and not give up so early
on in the fight.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h10nah$vp9$1@news.eternal-september.org>
Adlai wrote:
> On Jun 12, 9:48 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
>> Richard Heathfield wrote:
>>> MarkH said:
>>>> On Jun 10, 3:35 pm, Seamus MacRae <··········@live.ca.invalid>
>>>> wrote:
>>>>> Then you're giving up now? Hooray!
>>>> No, there's your problem.
>>> His problems appear to be many and varied.
>> Yes, and these problems have names:
>>
>> Richard Heathfield
>> MarkH
>> Ben Pfaff
>> Thomas Mertes
>> Lars Enderin
>> Nick Keighley
>> Paul Donnelly
>> Duane
>> Kaz Kylheku
>> ChrisF
>
> I didn't make the list???
I based the list on those active in the Richard-Heathfield-and-fanbois
attack thread, not the Lisp vs. Java one. As near as I can tell, two
partially separate cliques, theirs from comp.programming and yours from
comp.lang.lisp. Only Paul, Duane, Lars, and Kaz seem to overlap both groups.
Furthermore, I limited it to those who have attacked me recently. You
had quieted down, so you were not (any longer) a problem of mine.
> [insult deleted]
That, of course, puts you squarely back on my list of problems. Since
that's what you apparently wanted, you should feel free to not attack me
for having done so and to ignore this post instead.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u7k4$vdm$7@news.eternal-september.org>
MarkH wrote:
> On Jun 10, 3:35 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
>
>> Then you're giving up now? Hooray!
>
> No, there's your problem. C.L.L will always be talking about your
> fascist crimes
I have no fascist crimes, and you've already handed me a clear victory
by invoking Godwin's Law once already, twice already, and three times is
really rather overdoing it wouldn't you say? We get the message -- you
concede defeat. Time to move on. :)
> Even if this thread goes away, we'll be sure to bring you up, laugh
> behind your back every couple months or so.
As your pal Richard is so fond of saying: I don't respond well to threats.
On May 31, 12:43 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
> Richard Heathfield wrote:
>
> [snip]
>
> Stop attacking me.
....
> > Strawman argument.
>
> Do not personally attack me or accuse me of intellectually dishonest
> behavior again. You have been warned.
....
> > Yes, it's at least partly because there are people who don't know
> > [rest of personal attacks deleted]
>
> Stop attacking me.
>
You have a major malfunction "Seamus". Man the hell up, emo boy.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h00bj5$su9$2@news.eternal-september.org>
MarkH wrote:
> On May 31, 12:43 pm, Seamus MacRae <··········@live.ca.invalid> wrote:
>> Richard Heathfield wrote:
>>
>> [snip]
>>
>> Stop attacking me.
>>> Strawman argument.
>> Do not personally attack me or accuse me of intellectually dishonest
>> behavior again. You have been warned.
>>> Yes, it's at least partly because there are people who don't know
>>> [rest of personal attacks deleted]
>> Stop attacking me.
>
> You have a major malfunction "Seamus".
Who the fuck are you, and why is your debut into this thread a personal
attack aimed at a man that has not ever done or said anything to you,
personally, EVER???
On 31 May, 18:43, Seamus MacRae <··········@live.ca.invalid> wrote:
> Richard Heathfield wrote:
<snip>
> >>> Firstly, the preferred idiom is:
>
> >>> struct tm *foo = calloc(sizeof *foo);
>
> >> Surely not? That dereferences an uninitialized pointer, thereby
> >> invoking undefined behavior.
>
> > Surely not! The sizeof operator does not evaluate its operand
>
> It must at least partly do so, in order to know what size of thing *foo
> is referring to.
no. Think about it from the compiler's point of view. It actually
has enough information to calculate the value of "sizeof *foo"
without dereferencing foo. It doesn't need to know the value
of foo but only the type of foo. And since it's the compiler
it can simply look up the type of foo in an internal table
and substitute the size of type of foo. Which it also *must*
know since its the compiler (baring incomplete definitions
etc.).
calloc (sizeof *foo);
might well compile to
load R1 #sizeof(struct-tm)
call calloc
where #sizeof(struct-tm) is some sort of internal compiler
directive that in turn expands to something like
load R1 LIT 24
in in a more compact assembler
ld r1 #24
In fact not only is the compiler *able* to do this
but it is *required* to do this. sizeof is not
a function call but an operator
printf ("%ul\n", sizeof (* ((int*)0) ));
won't crash (assuming I got all me brackets right!)
<snip>
--
Nick Keighley
But ye have set at nought all my counsel, and would none of my
reproof:
I also will laugh at your calamity; I will mock when your fear
cometh;
[Proverbs 1:25]
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h00blj$su9$3@news.eternal-september.org>
····················@hotmail.com attacked as well:
> On 31 May, 18:43, Seamus MacRae <··········@live.ca.invalid> wrote:
>> Richard Heathfield wrote:
>>>>> Firstly, the preferred idiom is:
>>>>> struct tm *foo = calloc(sizeof *foo);
>>>> Surely not? That dereferences an uninitialized pointer, thereby
>>>> invoking undefined behavior.
>>> Surely not! The sizeof operator does not evaluate its operand
>> It must at least partly do so, in order to know what size of thing *foo
>> is referring to.
>
> no.
Yes. See other posts.
> It doesn't need to know the value of foo but only the type
> of foo.
There are variable-length arrays in C99.
On 1 June, 11:48, Seamus MacRae <··········@live.ca.invalid> wrote:
> ····················@hotmail.com attacked as well:
>
> > On 31 May, 18:43, Seamus MacRae <··········@live.ca.invalid> wrote:
> >> Richard Heathfield wrote:
> >>>>> Firstly, the preferred idiom is:
> >>>>> struct tm *foo = calloc(sizeof *foo);
> >>>> Surely not? That dereferences an uninitialized pointer, thereby
> >>>> invoking undefined behavior.
> >>> Surely not! The sizeof operator does not evaluate its operand
> >> It must at least partly do so, in order to know what size of thing *foo
> >> is referring to.
>
> > no.
>
> Yes. See other posts.
Panto Time! Look out behind you!
Ah, well there is no point in arguing with the man who won't listen.
I merely adress the massed ranks of the Lurkers.
> > It doesn't need to know the value of foo but only the type
> > of foo.
>
> There are variable-length arrays in C99.
yes, you are correct. I tend only to think about C89.
I'm not convinced that variable-length arrays were
a good idea. And even less convinced that sizeof(vararr)
was a good idea.
--
Nick Keighley
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gKWdne2dPPy2n7nXnZ2dnUVZ8ghi4p2d@bt.com>
····················@hotmail.com said:
> On 1 June, 11:48, Seamus MacRae <··········@live.ca.invalid>
> wrote:
>> ····················@hotmail.com attacked as well:
>>
<snip>
>> > It doesn't need to know the value of foo but only the type
>> > of foo.
>>
>> There are variable-length arrays in C99.
>
> yes, you are correct. I tend only to think about C89.
More to the point, the sizeof in question was taking the size of a
struct tm, not a VLA.
> I'm not convinced that variable-length arrays were
> a good idea. And even less convinced that sizeof(vararr)
> was a good idea.
I share your lack of conviction wrt VLAs. Nevertheless, they /are/
part of C99, so when C99 eventually becomes widespread (perhaps in
only a few more decades) it will become important to understand
VLAs.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h044mj$p58$3@news.eternal-september.org>
Richard Heathfield wrote:
> ····················@hotmail.com said:
>> On 1 June, 11:48, Seamus MacRae <··········@live.ca.invalid>
>> wrote:
>>> ····················@hotmail.com attacked as well:
>>>> It doesn't need to know the value of foo but only the type
>>>> of foo.
>>> There are variable-length arrays in C99.
>> yes, you are correct. I tend only to think about C89.
>
> More to the point
[snip]
No points here. Move on.
>> I'm not convinced that variable-length arrays were
>> a good idea. And even less convinced that sizeof(vararr)
>> was a good idea.
>
> I share your lack of conviction wrt VLAs. Nevertheless, they /are/
> part of C99, so when C99 eventually becomes widespread (perhaps in
> only a few more decades) it will become important to understand
> VLAs.
On 1 June, 17:36, Richard Heathfield <····@see.sig.invalid> wrote:
> ····················@hotmail.com said:
> > On 1 June, 11:48, Seamus MacRae <··········@live.ca.invalid>
> > wrote:
> >> ····················@hotmail.com attacked as well:
> >> > It doesn't need to know the value of foo but only the type
> >> > of foo.
>
> >> There are variable-length arrays in C99.
>
> > yes, you are correct. I tend only to think about C89.
>
> More to the point, the sizeof in question was taking the size of a
> struct tm, not a VLA.
yes, I missed that
> > I'm not convinced that variable-length arrays were
> > a good idea. And even less convinced that sizeof(vararr)
> > was a good idea.
>
> I share your lack of conviction wrt VLAs. Nevertheless, they /are/
> part of C99, so when C99 eventually becomes widespread (perhaps in
> only a few more decades) it will become important to understand
> VLAs.
when that time comes I'll learn about VLAs. I operate a YAGNI policy.
--
Nick Keighley
"Remember, the TAB key is your friend!"
Computer Training at <large insurance company>
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <Af2dnXHQYpXt7LvXnZ2dnUVZ8iZi4p2d@bt.com>
····················@hotmail.com said:
> On 1 June, 17:36, Richard Heathfield <····@see.sig.invalid> wrote:
<snip>
>> I share your lack of conviction wrt VLAs. Nevertheless, they
>> /are/ part of C99, so when C99 eventually becomes widespread
>> (perhaps in only a few more decades) it will become important to
>> understand VLAs.
>
> when that time comes I'll learn about VLAs. I operate a YAGNI
> policy.
Okay, I'll bite - YAGNI?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Alf P. Steinbach
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h05rp1$rh7$1@news.eternal-september.org>
* Richard Heathfield:
> ····················@hotmail.com said:
>
>> On 1 June, 17:36, Richard Heathfield <····@see.sig.invalid> wrote:
>
> <snip>
>
>>> I share your lack of conviction wrt VLAs. Nevertheless, they
>>> /are/ part of C99, so when C99 eventually becomes widespread
>>> (perhaps in only a few more decades) it will become important to
>>> understand VLAs.
>> when that time comes I'll learn about VLAs. I operate a YAGNI
>> policy.
>
> Okay, I'll bite - YAGNI?
http://acronyms.tfd.com/YAGNI
I have a Thunderbird extension where you just have to right-click on things and
select "search dictionary", it's very practical. :-)
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <WuydnflQ-NW67rvXnZ2dnUVZ8jBi4p2d@bt.com>
Alf P. Steinbach said:
> * Richard Heathfield:
>> ····················@hotmail.com said:
>>
<snip>
>>> when that time comes I'll learn about VLAs. I operate a YAGNI
>>> policy.
>>
>> Okay, I'll bite - YAGNI?
>
> http://acronyms.tfd.com/YAGNI
Ah, I was thinking along the lines of "Yet Another *".
One lives and learns.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h06dlj$nti$2@news.eternal-september.org>
····················@hotmail.com wrote:
> On 1 June, 17:36, Richard Heathfield <····@see.sig.invalid> wrote:
>> ····················@hotmail.com said:
>>> On 1 June, 11:48, Seamus MacRae <··········@live.ca.invalid>
>>> wrote:
>>>> ····················@hotmail.com attacked as well:
>
>>>>> It doesn't need to know the value of foo but only the type
>>>>> of foo.
>>>> There are variable-length arrays in C99.
>>> yes, you are correct. I tend only to think about C89.
>> More to the point
More to the point, it torpedoes the entire argument about why I'm
supposedly a moron.
I am not a moron.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h044jg$p58$2@news.eternal-september.org>
····················@hotmail.com wrote:
> On 1 June, 11:48, Seamus MacRae <··········@live.ca.invalid> wrote:
>> ····················@hotmail.com attacked as well:
>>> On 31 May, 18:43, Seamus MacRae <··········@live.ca.invalid> wrote:
>>>> Richard Heathfield wrote:
>>>>>>> Firstly, the preferred idiom is:
>>>>>>> struct tm *foo = calloc(sizeof *foo);
>>>>>> Surely not? That dereferences an uninitialized pointer, thereby
>>>>>> invoking undefined behavior.
>>>>> Surely not! The sizeof operator does not evaluate its operand
>>>> It must at least partly do so, in order to know what size of thing *foo
>>>> is referring to.
>>> no.
>> Yes. See other posts.
>
> Panto Time! Look out behind you!
Non-sequitur.
> Ah, well there is no point in arguing with the man who won't listen.
Then please don't.
> I merely adress the massed ranks of the Lurkers.
Not about me, you don't, not if you know what's good for you.
>>> It doesn't need to know the value of foo but only the type
>>> of foo.
>> There are variable-length arrays in C99.
>
> yes, you are correct.
On 2 June, 22:12, Seamus MacRae <··········@live.ca.invalid> wrote:
> ····················@hotmail.com wrote:
<snip>
> > I merely adress the massed ranks of the Lurkers.
>
> Not about me, you don't, not if you know what's good for you.
are you threatening me!? With what? What will happen if I discuss
your idocy on the internet? Will you cry? Come round to my house?
I'm genuinely interested.
It obviously doesn't pay to be reasonable with some people...
--
Nick Keighley
The world you perceive is drastically simplified model of the real
world
(Herbert Simon)
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h06dpa$nti$3@news.eternal-september.org>
····················@hotmail.com wrote:
> On 2 June, 22:12, Seamus MacRae <··········@live.ca.invalid> wrote:
>> ····················@hotmail.com wrote:
>>> I merely adress the massed ranks of the Lurkers.
>> Not about me, you don't, not if you know what's good for you.
>
> are you threatening me!? With what? What will happen if I discuss
> your idocy on the internet?
If you continue to slander me publicly, I may initiate legal
proceedings. Before that, I'm likely to have a little chitchat with your
internet provider's abuse department regarding your off-topic and
inflammatory posts.
And I am not an idiot.
> It obviously doesn't pay to be reasonable with some people...
Evidently. I tried being reasonable with both you and Heathfield, but to
no avail.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh2dkpk.b5g.willem@snail.stack.nl>
Seamus MacRae wrote:
) Evidently. I tried being reasonable with both you and Heathfield, but to
) no avail.
When ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0p5ge$duc$2@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Evidently. I tried being reasonable with both you and Heathfield, but to
> ) no avail.
>
> When ?
More than a week ago, but no more than three.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh32bh3.ct8.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> Seamus MacRae wrote:
)> ) Evidently. I tried being reasonable with both you and Heathfield, but to
)> ) no avail.
)>
)> When ?
)
) More than a week ago, but no more than three.
Do you have a message-ID ? I seem to have missed that post.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h0u840$e3l$2@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Seamus MacRae wrote:
> )> ) Evidently. I tried being reasonable with both you and Heathfield, but to
> )> ) no avail.
> )>
> )> When ?
> )
> ) More than a week ago, but no more than three.
>
> Do you have a message-ID ? I seem to have missed that post.
<············@news.eternal-september.org>
Dated 30 May, roughly two weeks ago.
That's my initial response to the first potshot by Richard Heathfield.
As you can see, it tries to be calm and reasonable and polite, and
apparently succeeds. The only remark there that can possibly be taken
personally, other than quoted ones, is the very last line, and as I
subsequently explained, that was aimed at C coding shops that engage in
sloppy development practices, rather than at any particular person.
Anyone, however good, might find themselves working for such a company
and it therefore shouldn't reflect on them.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh35bl0.ejf.willem@snail.stack.nl>
Seamus MacRae wrote:
)<············@news.eternal-september.org>
)
) Dated 30 May, roughly two weeks ago.
)
) That's my initial response to the first potshot by Richard Heathfield.
) As you can see, it tries to be calm and reasonable and polite, and
) apparently succeeds.
In that post, you firstly (and falsely) accused Richard of dereferencing
an uninitialized pointer, which is tantamount to calling him an idiot.
Secondly, you also patronized him with your remark about floating point
0.0, which is hardly polite.
That is hardly 'being reasonable', is it ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h10nd6$vp9$2@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> )<············@news.eternal-september.org>
> )
> ) Dated 30 May, roughly two weeks ago.
> )
> ) That's my initial response to the first potshot by Richard Heathfield.
> ) As you can see, it tries to be calm and reasonable and polite, and
> ) apparently succeeds.
>
> In that post, you firstly (and falsely) accused
I have never falsely accused anyone of anything. Unlike you.
Since it is clearly based on an erroneous premise, the rest of your post
has been deleted unread.
I now repeat my previous message:
<············@news.eternal-september.org>
Dated 30 May, roughly two weeks ago.
That's my initial response to the first potshot by Richard Heathfield.
As you can see, it tries to be calm and reasonable and polite, and
apparently succeeds.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh37t1a.16kl.willem@snail.stack.nl>
Seamus MacRae wrote:
) I have never falsely accused anyone of anything. Unlike you.
)
) Since it is clearly based on an erroneous premise, the rest of your post
) has been deleted unread.
You accused Richard of dereferencing an uninitialized pointer, did you not ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gaqdnYpvxeplZK7XnZ2dnUVZ8t1i4p2d@bt.com>
Willem said:
> Seamus MacRae wrote:
> ) I have never falsely accused anyone of anything. Unlike you.
> )
> ) Since it is clearly based on an erroneous premise, the rest of
> your post ) has been deleted unread.
>
> You accused Richard of dereferencing an uninitialized pointer, did
> you not ?
Forgive thou him, for he knows not what he does.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Bruce C. Baker
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <M2UYl.157$cx5.35@newsfe01.iad>
"Richard Heathfield" <···@see.sig.invalid> wrote in message
·····································@bt.com...
Richard, Willem, et al: Is this comp.programming, or comp.bedlam? And if the
latter, what does that make us?
"The lunatics were first called "patients" in 1700, and "curable" and
"incurable" wards were opened in 1725-34. In the 18th century people used to
go to Bedlam to stare at the lunatics. For a penny one could peer into their
cells, view the freaks of the "show of Bethlehem" and laugh at their antics,
generally of a sexual nature or violent fights. Entry was free on the first
Tuesday of the month. Visitors were permitted to bring long sticks with
which to poke and enrage the inmates. In 1814 alone, there were 96,000 such
visits."
http://en.wikipedia.org/wiki/Bethlem_Royal_Hospital
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h13als$dg7$4@news.eternal-september.org>
Bruce C. Baker wrote:
> "Richard Heathfield" <···@see.sig.invalid> wrote in message
> ·····································@bt.com...
>
> Richard, Willem, et al: Is this comp.programming, or comp.bedlam? And if the
> latter, what does that make us?
You said it: they're a bunch of nuts.
Not that it matters. Now its alt.fucknozzles.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3afjg.1mob.willem@snail.stack.nl>
Seamus MacRae wrote:
) Not that it matters. Now its alt.fucknozzles.
Setting followups without notification is deceitful and dishonest.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1643f$1ko$2@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Not that it matters. Now its alt.fucknozzles.
>
> Setting followups without notification is deceitful and dishonest.
Not when the purpose is to suppress a lie.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3d77n.2e0v.willem@snail.stack.nl>
Notice: followups set. To an existing newsgroup.
Seamus MacRae wrote:
) Willem wrote:
)> Setting followups without notification is deceitful and dishonest.
)
) Not when the purpose is to suppress a lie.
No, you're the liar, remember ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18jkm$g1d$5@news.eternal-september.org>
Willem wrote:
> Notice: followups set.
If you don't think this crap belongs in cll or cljp, why post there?
Your true motive is clear: you want your crap about me to be posted to
all three groups but to inhibit my responding in my own defense. If you
really cared about the newsgroups, your own posts would not have gone
out to all three groups.
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Setting followups without notification is deceitful and dishonest.
> )
> ) Not when the purpose is to suppress a lie.
>
> No
Yes. It's a simple moral calculus. A small lie of omission that prevents
a much bigger lie of commission weighs in as a net positive.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3fma9.153.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> Notice: followups set.
)
) If you don't think this crap belongs in cll or cljp, why post there?
It's standard Usenet practise to post to all groups in a reply to a
crosspost, and set followups to the relevant groups. This is so that
the readers know that they can follow the continued discussion in the
mentioned newsgroup. This is also why you should warn on the setting
of followups. (Which is also standard usenet practise.)
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1bcfj$c6r$3@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Notice: followups set.
> )
> ) If you don't think this crap belongs in cll or cljp, why post there?
>
> It's standard Usenet practise to post to all groups in a reply to a
> crosspost, and set followups to the relevant groups.
Oh, sure it is.
You just want to insult me in two of the groups without being rebutted
in those two groups.
Sorry, but I refuse to cooperate with that. For obvious reasons.
"Bruce C. Baker" <···@undisclosedlocation.net> writes:
<snip>
> Richard, Willem, et al: Is this comp.programming, or comp.bedlam? And if the
> latter, what does that make us?
>
> [...] In the 18th century people used to
> go to Bedlam to stare at the lunatics. For a penny one could peer into their
> cells, view the freaks of the "show of Bethlehem" and laugh at their antics,
> generally of a sexual nature or violent fights. Entry was free on the first
> Tuesday of the month. Visitors were permitted to bring long sticks with
> which to poke and enrage the inmates. [...]"
>
> http://en.wikipedia.org/wiki/Bethlem_Royal_Hospital
I take your point, but I disagree. SMR's behaviour is consistent with
his being of entirely sound mind. In fact the technique he is using
is standard practise for some publicists, lobbyists and PR firms these
days. I suspect it is also quite effective. The small technical
error he made that started this whole thing is now buried in a snow
storm of personal accusations, out-of-context quotes and what could
most charitably be called "editorialised" messages.
I agree with what I assume is your main point: that replying is not a
good idea. Not because replies are like the sticks in your quote, but
because every reply (no doubt including this one!) is just a hook on
which hang another editorial comment.
--
Ben.
From: Bruce C. Baker
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <QHhZl.1289$jI6.278@newsfe11.iad>
"Ben Bacarisse" <··········@bsb.me.uk> wrote in message
····························································@bsb.me.uk...
[...]
>
> I take your point, but I disagree. SMR's behaviour is consistent with
> his being of entirely sound mind. In fact the technique he is using
> is standard practise for some publicists, lobbyists and PR firms these
> days. I suspect it is also quite effective. The small technical
> error he made that started this whole thing is now buried in a snow
> storm of personal accusations, out-of-context quotes and what could
> most charitably be called "editorialised" messages.
>
> I agree with what I assume is your main point: that replying is not a
> good idea. Not because replies are like the sticks in your quote, but
> because every reply (no doubt including this one!) is just a hook on
> which hang another editorial comment.
Replying to SMR sure seems like aiding and abetting either his technique or
his lunacy, will not advance the discussion, and certainly does no credit to
any of the parties involved. It smacks of bear-baiting.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h164nj$54j$4@news.eternal-september.org>
Bruce C. Baker wrote:
> "Ben Bacarisse" <··········@bsb.me.uk> wrote in message
> ····························································@bsb.me.uk...
>
> [...]
>
>> SMR's behaviour is consistent with his being of entirely sound mind.
True, but off-topic. At least one of you admits I'm not nuts.
>> [calls me an idiot]
Now admit that I'm not an idiot, either.
> Replying to SMR sure seems like aiding and abetting either his technique or
> his lunacy
I have no lunacy, and the phrase "aiding and abetting" dishonestly
implies criminal conduct on my part, when no such conduct has taken place.
> will not advance the discussion, and certainly does no credit to
> any of the parties involved. It smacks of bear-baiting.
Don't make me angry. You wouldn't like me when I'm angry.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <VMGdnewktef546jXnZ2dnUVZ8o9i4p2d@bt.com>
Ben Bacarisse said:
<snip>
> The small technical
> error he made that started this whole thing is now buried in a
> snow storm of personal accusations, out-of-context quotes and what
> could most charitably be called "editorialised" messages.
The first small technical error he made (which received a polite
response, no matter what he make think) can be exhumed using this
message ID: <············@news.eternal-september.org>
> I agree with what I assume is your main point: that replying is
> not a good idea. Not because replies are like the sticks in your
> quote, but because every reply (no doubt including this one!) is
> just a hook on which hang another editorial comment.
Well, nobody can take the shovel away from him, so I suppose he'll
keep digging his hole.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Paul Donnelly
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <87ws7egzwd.fsf@plap.localdomain>
Richard Heathfield <···@see.sig.invalid> writes:
> Ben Bacarisse said:
>
> <snip>
>
>> The small technical
>> error he made that started this whole thing is now buried in a
>> snow storm of personal accusations, out-of-context quotes and what
>> could most charitably be called "editorialised" messages.
>
> The first small technical error he made (which received a polite
> response, no matter what he make think) can be exhumed using this
> message ID: <············@news.eternal-september.org>
>
>> I agree with what I assume is your main point: that replying is
>> not a good idea. Not because replies are like the sticks in your
>> quote, but because every reply (no doubt including this one!) is
>> just a hook on which hang another editorial comment.
>
> Well, nobody can take the shovel away from him, so I suppose he'll
> keep digging his hole.
You could at least take away the earth he's digging in.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h164jp$54j$3@news.eternal-september.org>
Paul Donnelly wrote:
> Richard Heathfield <···@see.sig.invalid> writes:
>
>> Ben Bacarisse said:
>>
>> <snip>
>>
>>> [calls me an idiot]
>> [calls me an idiot]
No, you're the idiots.
>> [implied insult]
>
> [implied insult]
I hereby state for the record that these implied insults are factually
incorrect.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h164ib$54j$2@news.eternal-september.org>
Richard Heathfield wrote:
> Ben Bacarisse said:
>> [calls me an idiot]
>
> [calls me an idiot]
I am not. You are, remember?
> [implies another insult]
I hereby state for the record that the insulting thing that Richard just
implied is factually incorrect.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3d7p9.2e0v.willem@snail.stack.nl>
Notice: Followups set.
Seamus MacRae wrote:
) Richard Heathfield wrote:
)> Ben Bacarisse said:
)>> [calls me an idiot]
)>
)> [calls me an idiot]
)
) I am not. You are, remember?
)
)> [implies another insult]
)
) I hereby state for the record that the insulting thing that Richard just
) implied is factually incorrect.
You wrote every single word in the above post(*). Not a single letter has
been written by anybody else. Do you enjoy talking to yourself ?
*) With the exception of 'Ben Bacarisse said:' and perhaps
'Richard Heathfield wrote:', which were written by posting software.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18jn7$g1d$6@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Richard Heathfield wrote:
> )> [implies another insult]
> )
> ) I hereby state for the record that the insulting thing that Richard just
> ) implied is factually incorrect.
>
> [irrelevant mumblings deleted]
I hereby state for the record that the insulting things that these
jerkwads have implied about me are factually incorrect.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h164g1$54j$1@news.eternal-september.org>
Ben Bacarisse wrote:
> "Bruce C. Baker" <···@undisclosedlocation.net> writes:
>
> <snip>
>> Richard, Willem, et al: Is this comp.programming, or comp.bedlam? And if the
>> latter, what does that make us?
A bunch of madmen. You, Willem, Richard, the lot of you. Mad.
> SMR's behaviour is consistent with his being of entirely sound mind.
This statement, though true, is entirely off topic here.
> In fact the technique he is using is standard practise for some
> publicists, lobbyists and PR firms these days. I suspect it is also
> quite effective. The [calls me an idiot] is now buried in a snow
> storm of personal accusations, out-of-context quotes and [insult]
Burying the publicly-made insults is, obviously, an objective of mine.
As it might well be yours, were people to start flaming you unreasonably.
What I find disturbing is that it seems a certain segment of the 'net
population just doesn't get it with regard to civility, politeness, and
allowing one another space. They criticize, but the actual bad thing is
that when the criticizee speaks up in his own defense and addresses the
criticisms, certain people don't simply leave it at that, but repeat
their criticisms, generally more strongly and more shrilly, and even
recruit others to join in the carping, like the pick-a-little ladies in
that play.
Something definitely has to be done to establish a right of preservation
of dignity on the net, a right not to be subjected to endless shrill
carping or worse, smear/stalking/anti-publicity campaigns against one's
will; a right to have each side have said their peace and then that's
the end of it.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3d7ih.2e0v.willem@snail.stack.nl>
Notice: Followups were dishonestly and deceitfully set to a non-existing
newsgroup, and therefore ignored. Followups have now been set to a
sensible and existing newsgroup, and should therefore be followed.
Seamus MacRae wrote:
) that when the criticizee speaks up in his own defense and addresses the
) criticisms, certain people don't simply leave it at that,
Of course not. Civil people, when confronted with evidence of their
mistakes, usually admit those mistakes instead of feeling insulted.
) a right to have each side have said their peace and then that's
) the end of it.
Then why did you keep on replying after Richard said his piece ?
(When he told you you were wrong about sizeof evaluating its operand.)
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18k6c$oah$1@news.eternal-september.org>
Willem wrote:
> Notice: Followups were dishonestly and deceitfully set
Nothing that I have done has been dishonest or deceitful. In particular,
making it more difficult for you to lie about me here is the very opposite.
> to a non-existing newsgroup
This is also a lie. The newsgroup assuredly does exist, even if your
news carrier is too interested in playing moral guardian instead of
simply doing its job as a bit-schlepper to carry that group.
> Seamus MacRae wrote:
> ) that when the criticizee speaks up in his own defense and addresses the
> ) criticisms, certain people don't simply leave it at that,
>
> Of course not.
Because those people are assholes. They think that the only valid
response to their criticisms is for their target to roll over and say
"uncle". They are bullies, in other words. In fact, YOU are a bully.
So they get very annoyed when someone does not treat them like a king
and accept their every decree as tantamount to being the word of God.
They seem to really get their panties in a twist if openly and
explicitly defied and contradicted. Funny that, when they are so willing
to do the exact same thing to other people. What a double standard! Thou
Shalt Not Contradict Richard, even though he contradicted you first.
The lot of you are completely laughable. Nobody should take you
seriously now that your true colors have been exposed for all the world
to see. Richard thinks he's Napoleon and you what? His knight-errant?
When actually you're just errant.
> ) a right to have each side have said their peace and then that's
> ) the end of it.
>
> Then why did you keep on replying after Richard said his piece ?
Because he'd lied about me, personally, and those lies had to be corrected.
> (When he told you [insult deleted])
For the obvious reason.
You see, you seem to think the way it should end is:
Hapless Guy: says something
Richard: insults Hapless Guy
Hapless Guy: meekly slinks off to lick his wounds
or at least that Richard (or you) have some God-given right to have the
last word. When what's actually fair is:
Hapless Guy: says something
Richard: insults Hapless Guy
Hapless Guy: explains why he's not the sort of person Richard said he is
or anything that has no more insults than rebuttals of same.
Note that this is not asymmetrical; if it were HG that started by
insulting Richard out of the blue then Richard would deserve the last
word -- at least so long as it was a non-insulting one that just stated
that Richard was an OK guy.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3fmu4.153.willem@snail.stack.nl>
Seamus MacRae wrote:
) You see, you seem to think the way it should end is:
)
) Hapless Guy: says something
) Richard: insults Hapless Guy
) Hapless Guy: meekly slinks off to lick his wounds
No, the way it could end is:
Seamus: says something factually incorrect
Richard: corrects mistake
Seamus: acts indignant at perceived insult, and replies with insults
Richard: explains that it was not an insult
Seamus: accepts explanation that it was not an insult
See ? You don't even have to admit your mistake.
Of course, civilized people do admit when they make mistakes.
) Note that this is not asymmetrical; if it were HG that started by
) insulting Richard out of the blue then Richard would deserve the last
) word -- at least so long as it was a non-insulting one that just stated
) that Richard was an OK guy.
Then why did you start insulting other people ?
And I don't mean implied insults, I mean actual direct insults.
This is how you seemingly want it to end:
Seamus: says something that contains a mistake
Richard: corrects factual mistake
Seamus: takes factual correction as personal insult and replies with
lots more insults.
Richard: meekly slinks off to lick his wounds
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Kaz Kylheku
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <20090628152002.61@gmail.com>
On 2009-06-16, Willem <······@snail.stack.nl> wrote:
> This is how you seemingly want it to end:
>
> Seamus: says something that contains a mistake
> Richard: corrects factual mistake
This is where Richard should leave it, yes. Everyone can see that
Richard is right. The facts are easily researched in two minutes of
googling. The job is done; the misinformation has been adequately addressed.
> Seamus: takes factual correction as personal insult and replies with
> lots more insults.
At this point, the trolling dipshit is turning it personal, without adding
anything to the topic that was being discussed, or addressing his mistake.
This should be ignored. Everyone can still see that Richard was right.
Any reply to this followup constitutes a participation in the troll's game.
There is no way that it's about correctness any longer after this point.
> Richard: meekly slinks off to lick his wounds
Are you serious? What wounds? An insult can only come from someone on your own
level, or higher. Shameful Macro would have to go back and re-live most of his
entire miserable life differently to attain a position from which insulting
Richard would be possible.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1bcu1$prv$1@news.eternal-september.org>
Kaz Kylheku wrote:
> On 2009-06-16, Willem <······@snail.stack.nl> wrote:
>> This is how you seemingly want it to end:
>>
>> [calls me an idiot]
I am not.
> the misinformation
I am about the only person here NOT spreading misinformation. Meanwhile,
your own post is an instance of you spreading misinformation about me.
> At this point, the trolling dipshit
The only trolling dipshit here is you.
> [calls me more names, including an idiot]
I am not.
>> Richard: meekly slinks off to lick his wounds
>
> Are you serious? What wounds? An insult can only come from someone on your own
> level, or higher. Shameful Macro would have to go back and re-live most of his
> entire miserable life differently to attain a position from which insulting
> Richard would be possible.
This is outrageously inaccurate. First of all, an insult can obviously
come from anybody. Second, there is nothing whatsoever wrong with how
I've lived my life -- indeed, with a few wise investments and a decent
work ethic I've managed to sock away over three million dollars in my
retirement fund, while many people have been losing nest-eggs left and
right in the dot-com bubble and then the realestate bubble.
Third, I am on Richard's level, or higher. Certainly I'm much more
respectful of other people's dignity than he is, and his better in many
other ways, social-skills-wise. Probably also better than him at Java.
And last, but not least, my name is Seamus MacRae. Learn to spell it
correctly, please, or else refrain from referencing me in public.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1bckm$c6r$4@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) You see, you seem to think the way it should end is:
> )
> ) Hapless Guy: says something
> ) Richard: insults Hapless Guy
> ) Hapless Guy: meekly slinks off to lick his wounds
>
> No, the way it could end is:
>
> [calls me an idiot]
That, of course, is simply not possible.
> Seamus: accepts
No. I will never cry "uncle". No amount of attempting to twist my arm
will make me comply. I am resistant to coercion by my nature.
> See ? You don't even have to admit your mistake.
I have none to admit.
> ) Note that this is not asymmetrical; if it were HG that started by
> ) insulting Richard out of the blue then Richard would deserve the last
> ) word -- at least so long as it was a non-insulting one that just stated
> ) that Richard was an OK guy.
>
> Then why did you start insulting other people ?
I did not, except to call you and a few others out for dishonesty when
you'd clearly been dishonest.
> This is how you seemingly want it to end:
>
> Seamus: says something that contains a mistake
No. I do not choose to do such things, so you are incorrect in claiming
that that is any part of how I want anything to end.
> Richard: meekly slinks off to lick his wounds
That, on the other hand, would be satisfying to see.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3ieof.l03.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> Seamus: says something that contains a mistake
)
) No. I do not choose to do such things, so you are incorrect in claiming
) that that is any part of how I want anything to end.
You don't *choose* to make mistakes. You simply make them unwittingly.
That's how mistakes work. When this is pointed out, civilized people
realize their mistake and accept the correction thereof.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <OuidnU3uIo7c6KTXnZ2dnUVZ8tCdnZ2d@bt.com>
Willem said:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Seamus: says something that contains a mistake
> )
> ) No. I do not choose to do such things, so you are incorrect in
> claiming ) that that is any part of how I want anything to end.
>
> You don't *choose* to make mistakes. You simply make them
> unwittingly.
> That's how mistakes work. When this is pointed out, civilized
> people realize their mistake and accept the correction thereof.
And the obvious conclusion can be drawn about those who do not.
What I want to know - not desperately, I'm merely kinda curious - is
who he is trying to persuade that he's not an idiot. The way he has
chosen to go about it is most strange. Perhaps /he/ finds his
assertions and denials persuasive, but I doubt very much whether
anyone else does. (His mother, perhaps. Some mothers can be very
loyal.)
Clearly the lawsuit threats are electronic tigers (i.e. not even
paper tigers). In a way, that's too bad. Imagine a jury trying to
keep a straight face as they read his articles!
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1gjbu$ckj$3@news.eternal-september.org>
Richard Heathfield wrote:
> Willem said:
>> Seamus MacRae wrote:
>> ) Willem wrote:
>> )> Seamus: says something that contains a mistake
>> )
>> ) No. I do not choose to do such things, so you are incorrect in
>> claiming ) that that is any part of how I want anything to end.
>>
>> You don't *choose* to make mistakes.
Isn't that what I just said.
>> You simply make them unwittingly.
No. I do not do anything at all unwittingly.
>> [calls me uncivilized]
No, you two are the uncivilized ones here, remember?
> And the obvious conclusion can be drawn about those who do not.
No.
> What I want to know - not desperately, I'm merely kinda curious - is
> who he is trying to persuade that he's not an idiot.
The same people you are trying to persuade of the opposite.
> [accuses me of being bad at persuasion]
<stoop level="Richard Heathfield's">
I know you are, but what am I?
</stoop>
> Clearly the lawsuit threats are electronic tigers (i.e. not even
> paper tigers). [insult deleted]
I wouldn't stake several hundred thousand dollars on that. You might get
taken to the cleaners.
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1gj6n$ckj$2@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Seamus: says something that contains a mistake
> )
> ) No. I do not choose to do such things, so you are incorrect in claiming
> ) that that is any part of how I want anything to end.
>
> You don't *choose* to make mistakes.
Indeed. That's exactly what I just said.
> You simply make them unwittingly.
No, I do not. I do not do anything unwittingly.
> [calls me uncivilized]
Describing yourself and misattributing it to me? How lame.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3nm2j.2gfl.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> You don't *choose* to make mistakes.
)
) Indeed. That's exactly what I just said.
)
)> You simply make them unwittingly.
)
) No, I do not. I do not do anything unwittingly.
Am I correct in understanding that you claim to never make a mistake ?
You've never made a mistake in your life ? Not once ? Ever ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <pbqdnV9tfMkrm6HXnZ2dnUVZ8gRi4p2d@bt.com>
Willem said:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> You don't *choose* to make mistakes.
> )
> ) Indeed. That's exactly what I just said.
> )
> )> You simply make them unwittingly.
> )
> ) No, I do not. I do not do anything unwittingly.
>
> Am I correct in understanding that you claim to never make a
> mistake ?
That would appear to be the case, yes. "I. Do. Not. Make. Mistakes."
Message-ID: <············@news.eternal-september.org>
> You've never made a mistake in your life ? Not once ? Ever ?
I can't recall his actually making that claim (which is slightly
different to the claim above), but it wouldn't surprise me if he
were to make such a claim, or indeed if he had already done so.
The claim he /has/ made, though, the "I. Do. Not. Make. Mistakes."
Message-ID: <············@news.eternal-september.org> claim, is
demonstrably false, since he has made at least three technical
errors in this thread. I say "demonstrably" because he has made
three claims about the C language that flatly contradict the
International Standard for that language.
We all make mistakes (especially me!). Some are of little or no
consequence, and some are quite severe. The mistake of believing
oneself infallible (if one is not in fact infallible) is, in my
opinion, one of the more severe.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1jeb0$e6t$4@news.eternal-september.org>
Richard Heathfield wrote:
> Willem said:
>> Seamus MacRae wrote:
>> ) Willem wrote:
>> )> You don't *choose* to make mistakes.
>> )
>> ) Indeed. That's exactly what I just said.
>> )
>> )> You simply make them unwittingly.
>> )
>> ) No, I do not. I do not do anything unwittingly.
>>
>> [nothing relevant]
>
> [nothing relevant]
>
>> [nothing relevant]
>
> [calls me a liar]
No, you're the liar, remember?
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <p8ednXPkD8hHyaDXnZ2dnUVZ8r6dnZ2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
<snip>
>>
>> [calls me a liar]
Not on that occasion I didn't. Learn the difference between "Seamus
made a mistake" and "Seamus lied". It is a significant difference.
> No, you're the liar, remember?
You have said this quite a few times now. Can you *prove* it in a
way that is *convincing* to people other than yourself (in the same
way, for example, that I can prove you to be a liar)? That is, have
you some objective evidence that will satisfy a standard of proof
greater than "because Seamus MacRae says so"? I predict that you
are incapable of answering this question objectively, and that if
you reply at all it will be with some non-answer such as those to
which we have become accustomed to getting from you.
I asked you recently who you were trying to persuade that you're not
an idiot. In the article with message ID
<············@news.eternal-september.org> you said "The same people
you are trying to persuade of the opposite." Now in my opinion
that's the empty set, because I'm not trying to persuade anyone of
any such thing. Nevertheless, clearly you don't agree, and are of
the opinion that there are people out there who might think you an
idiot if you didn't defend yourself. My question is this: do you
truly believe that behaving in the way that you are behaving will
persuade people that you are not an idiot? Again, I predict that
you are incapable of answering this question objectively, and that
if you reply at all it will be with some non-answer such as those
to which we have become accustomed to getting from you.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1la9b$rnl$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
> <snip>
>>> [calls me a liar]
>
> [calls me a liar]
No, you're the liar, remember?
>> No, you're the liar, remember?
>
> [calls me a liar]
No, you're the liar, remember?
> I asked you recently who you were trying to persuade that you're not
> an idiot.
And I answered it.
> [calls me a liar]
No, you're the liar, remember?
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <576dnVXiwoVWGqPXnZ2dnUVZ8h5i4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Seamus MacRae said:
>>> Richard Heathfield wrote:
>> <snip>
>>>> [calls me a liar]
>>
>> [calls me a liar]
>
> No, you're the liar, remember?
Alas, you have proved my prediction (that you are incapable of
rational argument - see <································@bt.com>
for details) to be correct.
You are not doing yourself any favours.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1ockq$838$1@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Seamus MacRae said:
>>>> Richard Heathfield wrote:
>>> <snip>
>>>>> [calls me a liar]
>>> [calls me a liar]
>> No, you're the liar, remember?
>
> [calls me crazy]
No, you're the crazy person, remember?
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1je8s$e6t$3@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> You don't *choose* to make mistakes.
> )
> ) Indeed. That's exactly what I just said.
> )
> )> You simply make them unwittingly.
> )
> ) No, I do not. I do not do anything unwittingly.
>
> [nothing relevant]
...
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h13ajl$dg7$3@news.eternal-september.org>
Richard Heathfield wrote:
> Willem said:
>
>> Seamus MacRae wrote:
>> ) I have never falsely accused anyone of anything. Unlike you.
>> )
>> ) Since it is clearly based on an erroneous premise, the rest of
>> your post ) has been deleted unread.
>>
>> You accused Richard
I did not accuse him of anything except libel, of which he's
demonstrably guilty.
> Forgive thou him, for he knows not what he does.
I have no need of anyone's forgiveness, for I've done nothing wrong.
From: Richard Heathfield
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <LfCdnVebGfPLzKjXnZ2dnUVZ8kFi4p2d@bt.com>
Seamus MacRae said:
> Richard Heathfield wrote:
>> Willem said:
>>
>>> Seamus MacRae wrote:
>>> ) I have never falsely accused anyone of anything. Unlike you.
>>> )
>>> ) Since it is clearly based on an erroneous premise, the rest of
>>> your post ) has been deleted unread.
>>>
>>> You accused Richard
>
> I did not accuse him of anything except libel, of which he's
> demonstrably guilty.
>
>> Forgive thou him, for he knows not what he does.
>
> I have no need of anyone's forgiveness, for I've done nothing
> wrong.
Well, you lied and I can prove it, but *apart* from that, you've
completely misunderstood sizeof (and VLAs, as it happens), which is
why I said (above) that you don't know what you're doing. It is
quite plain to me that this is in fact the case, and I'm perfectly
happy to defend that statement in court if necessary.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. ····@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h164p9$54j$5@news.eternal-september.org>
Richard Heathfield wrote:
> Seamus MacRae said:
>> Richard Heathfield wrote:
>>> Willem said:
>>>> You accused Richard
>> I did not accuse him of anything except libel, of which he's
>> demonstrably guilty.
>>
>>> Forgive thou him, for he knows not what he does.
>> I have no need of anyone's forgiveness, for I've done nothing
>> wrong.
>
> [calls me a liar and an idiot]
No, you're the liar and the idiot, remember?
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h13aif$dg7$2@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) I have never falsely accused anyone of anything. Unlike you.
> )
> ) Since it is clearly based on an erroneous premise, the rest of your post
> ) has been deleted unread.
>
> You accused Richard
I accused nobody of anything except libel, of which I've seen plenty
lately, so those were not *false* accusations.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3afoa.1mob.willem@snail.stack.nl>
Seamus MacRae wrote:
) Willem wrote:
)> Seamus MacRae wrote:
)> ) I have never falsely accused anyone of anything. Unlike you.
)> )
)> ) Since it is clearly based on an erroneous premise, the rest of your post
)> ) has been deleted unread.
)>
)> You accused Richard
)
) I accused nobody of anything
Then what do you call your comment involving sizeof and dereferencing
of a pointer ? You know, the one in your post which started all this ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
On Sun, 14 Jun 2009 18:18:50 +0000, Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Seamus MacRae wrote:
> )> ) I have never falsely accused anyone of anything. Unlike you. )> )
> )> ) Since it is clearly based on an erroneous premise, the rest of your
> post )> ) has been deleted unread.
> )>
> )> You accused Richard
> )
> ) I accused nobody of anything
>
> Then what do you call your comment involving sizeof and dereferencing of
> a pointer ? You know, the one in your post which started all this ?
Well, to me this whole thread proves that VLA's were a bad invention
after all.
* They serve no purpose (since they are forbidden inside structs, there
will still be a need for 'struct hacks')
* they change the semantics of sizeof
* they drive people to a condition that is close to insanity.
* they cause grown up man to cry and start eating babies.
* they accelerate the decline of usenet.
IMHO, VLA's have 'designed by committee' written all over them.
HTH,
AvK
From: ··········@rsw.digi.com.br
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <uski2txfa.fsf@rsw.digi.com.br>
Moi <····@invalid.address.org> writes:
> On Sun, 14 Jun 2009 18:18:50 +0000, Willem wrote:
>
>> Seamus MacRae wrote:
>> ) Willem wrote:
>> )> Seamus MacRae wrote:
>> )> ) I have never falsely accused anyone of anything. Unlike you. )> )
>> )> ) Since it is clearly based on an erroneous premise, the rest of your
>> post )> ) has been deleted unread.
>> )>
>> )> You accused Richard
>> )
>> ) I accused nobody of anything
>>
>> Then what do you call your comment involving sizeof and dereferencing of
>> a pointer ? You know, the one in your post which started all this ?
>
>
> Well, to me this whole thread proves that VLA's were a bad invention
> after all.
> * They serve no purpose (since they are forbidden inside structs, there
> will still be a need for 'struct hacks')
> * they change the semantics of sizeof
> * they drive people to a condition that is close to insanity.
> * they cause grown up man to cry and start eating babies.
> * they accelerate the decline of usenet.
>
> IMHO, VLA's have 'designed by committee' written all over them.
lol
>
> HTH,
> AvK
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h164sp$54j$7@news.eternal-september.org>
Moi wrote:
> On Sun, 14 Jun 2009 18:18:50 +0000, Willem wrote:
>> Seamus MacRae wrote:
>> ) Willem wrote:
>> )> Seamus MacRae wrote:
>> )> ) I have never falsely accused anyone of anything. Unlike you. )> )
>> )> ) Since it is clearly based on an erroneous premise, the rest of your
>> post )> ) has been deleted unread.
>> )>
>> )> You accused Richard
>> )
>> ) I accused nobody of anything
>>
>> Then what do you call your comment
A comment. No personal accusation was expressed or implied.
> Well, to me this whole thread proves that VLA's were a bad invention
> after all.
Fascinating.
> * they drive people to a condition that is close to insanity.
Not I. Richard seems affected, though, and several others here.
> * they cause grown up man to cry and start eating babies.
Shocker! Who's done this? Richard?
> * they accelerate the decline of usenet.
>
> IMHO, VLA's have 'designed by committee' written all over them.
That they do.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3d84a.2e0v.willem@snail.stack.nl>
Notice: Followups have been set.
Seamus MacRae wrote:
)> On Sun, 14 Jun 2009 18:18:50 +0000, Willem wrote:
)>> Then what do you call your comment
)
) A comment. No personal accusation was expressed or implied.
Your 'comment' implied at least as much accusation as Richard's.
Moreover, your comment was factually incorrect, whereas that of
Richard was factually correct.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18k87$oah$2@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> )> On Sun, 14 Jun 2009 18:18:50 +0000, Willem wrote:
> )>> Then what do you call your comment
> )
> ) A comment. No personal accusation was expressed or implied.
>
> Your 'comment' implied at least as much accusation
It did not.
> Moreover, [calls me an idiot]
No, you're the idiot, remember?
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h164q1$54j$6@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Seamus MacRae wrote:
> )> ) I have never falsely accused anyone of anything. Unlike you.
> )> )
> )> ) Since it is clearly based on an erroneous premise, the rest of your post
> )> ) has been deleted unread.
> )>
> )> You accused Richard
> )
> ) I accused nobody of anything
>
> Then what do you call your comment
A comment. Not an accusation.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3d7v2.2e0v.willem@snail.stack.nl>
Notice: Followups have been set.
Seamus MacRae wrote:
) Willem wrote:
)> Seamus MacRae wrote:
)> ) Willem wrote:
)> )> You accused Richard
)> )
)> ) I accused nobody of anything
)>
)> Then what do you call your comment
)
) A comment. Not an accusation.
You called Richards comment an accusation.
You are using a double standard.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h18kec$oah$3@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) Willem wrote:
> )> Seamus MacRae wrote:
> )> ) Willem wrote:
> )> )> You accused Richard
> )> )
> )> ) I accused nobody of anything
> )>
> )> Then what do you call your comment
> )
> ) A comment. Not an accusation.
>
> You called Richards comment an accusation.
That's because Richard's comment WAS an accusation, unlike mine.
And all of this happened AFTER:
<································@bt.com>
in which, in response to a perfectly civil post by me, Richard was most
uncourteous:
> Firstly, the preferred idiom is:
and so forth. Talking down to me like I was some D student in his class
or something. The nerve! I'm probably a decade or more his senior, I'm
probably smarter than he is, and I certainly seem to know more about how
to be polite and respect others' dignity in public than he does. Unless
he simply doesn't care.
From: Willem
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <slrnh3fndr.153.willem@snail.stack.nl>
Seamus MacRae wrote:
) And all of this happened AFTER:
)
)<································@bt.com>
)
) in which, in response to a perfectly civil post by me, Richard was most
) uncourteous:
)
)> Firstly, the preferred idiom is:
)
) and so forth. Talking down to me like I was some D student in his class
) or something. The nerve! I'm probably a decade or more his senior, I'm
) probably smarter than he is, and I certainly seem to know more about how
) to be polite and respect others' dignity in public than he does. Unless
) he simply doesn't care.
I think it is patently obvious that you perceived a perfectly normal
comment as an insult, and replied with a heap of obvious insults.
That is what started all this. As you seem completely incapable
of admitting error, there is no point in discussing this further.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1bd4a$rhb$1@news.eternal-september.org>
Willem wrote:
> Seamus MacRae wrote:
> ) And all of this happened AFTER:
> )
> )<································@bt.com>
> )
> ) in which, in response to a perfectly civil post by me, Richard was most
> ) uncourteous:
> )
> )> Firstly, the preferred idiom is:
> )
> ) and so forth. Talking down to me like I was some D student in his class
> ) or something. The nerve! I'm probably a decade or more his senior, I'm
> ) probably smarter than he is, and I certainly seem to know more about how
> ) to be polite and respect others' dignity in public than he does. Unless
> ) he simply doesn't care.
>
> I think it is patently obvious that you perceived a perfectly normal
> comment as an insult
Nonsense. Talking down to me and "perfectly normal comment" are mutually
exclusive. When he rattled off that "Firstly, do this instead of that;
secondly ..." you could pretty much *see* his finger wagging and a
disapproving frown glowering on his face.
Let me make one thing especially clear: It is never correct to respond
in a disapproving manner to anything that I've said or done. Whatever it
was, I said or did it to the best of my ability, and no-one can
reasonably demand more than that!
> That is what started all this. As you seem completely incapable
> of admitting error
I am certainly completely unwilling to "admit" an "error" I don't agree
was one.
> there is no point in discussing this further.
Then you'll shut up about me now?
From: stan
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <u9klg6-c0v.ln1@invalid.net>
Seamus MacRae wrote:
<snip>
>> Firstly, the preferred idiom is:
>
> and so forth. Talking down to me like I was some D student in his class
> or something. The nerve! I'm probably a decade or more his senior, I'm
> probably smarter than he is, and I certainly seem to know more about how
> to be polite and respect others' dignity in public than he does. Unless
> he simply doesn't care.
When do the betting windows open???
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h1bd57$rhb$2@news.eternal-september.org>
stan wrote:
> Seamus MacRae wrote:
> <snip>
>>> Firstly, the preferred idiom is:
>> and so forth. Talking down to me like I was some D student in his class
>> or something. The nerve! I'm probably a decade or more his senior, I'm
>> probably smarter than he is, and I certainly seem to know more about how
>> to be polite and respect others' dignity in public than he does. Unless
>> he simply doesn't care.
>
> When do the betting windows open???
They do not.
On 31 May, 09:04, Richard Heathfield <····@see.sig.invalid> wrote:
> Seamus MacRae said:
>
> > Richard Heathfield wrote:
<snip>
> >>>> Some developers even have tools to automatically filter such
> >>>> warnings (comparing the warnings of a new build with those
> >>>> expected for any build).
>
> >>>> I expect this sounds like an awful lot of fuss for a great many
> >>>> programmers - but for some it is a way of life!
> >>> How unfortunate.
>
> >> I've worked in environments like that, and found it quite
> >> workable.
>
> > Now I know why so much C software is crash-prone and generally
> > buggy.
you'll have to explain that. I prefer warning free code. I'm willing
to
jump through some hoops to achieve it. But it remains a fact that not
all warnings indicate a potential error. If I had a compiler that
issued at lot of spurious warnings for my code I'd seriously
consider such a tool.
If you make comments like that about what seem like fairly sane
development methods then your tend to get remarks like those below:-
> Yes, it's at least partly because there are people who don't know
> the semantics of sizeof, but who still insist on writing in C.
> Alternatively, we *could* play nice and back off the "in the
> absence of evidence to the contrary I'll just assume you're a
> moron" tone and discuss this like grown-ups. Your call.
--
Nick Keighley
From: Seamus MacRae
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <h00br6$su9$4@news.eternal-september.org>
····················@hotmail.com attacked:
> On 31 May, 09:04, Richard Heathfield <····@see.sig.invalid> wrote:
>> Seamus MacRae said:
>>> Richard Heathfield wrote:
>>>>>> Some developers even have tools to automatically filter such
>>>>>> warnings (comparing the warnings of a new build with those
>>>>>> expected for any build).
>>>>>> I expect this sounds like an awful lot of fuss for a great many
>>>>>> programmers - but for some it is a way of life!
>>>>> How unfortunate.
>>>> I've worked in environments like that, and found it quite
>>>> workable.
>>> Now I know why so much C software is crash-prone and generally
>>> buggy.
>
> you'll have to explain that. I prefer warning free code. I'm willing
> to jump through some hoops to achieve it. But it remains a fact that
> not all warnings indicate a potential error. If I had a compiler that
> issued at lot of spurious warnings for my code I'd seriously
> consider such a tool.
Whereas I'd seriously consider using a different compiler.
> If you make comments like that about what seem like fairly sane
> development methods then your tend to get remarks like those below
Is that a threat?
Uh-uh. If I make civil, impersonal comments that do not impugn anyone,
directly or indirectly, then I fully expect all responses to be equally
civil. Instead people keep stooping to name-calling when they don't
agree with/don't like what I say. It's like half the people here are
grade-school kids or something. WTF??
> [personal attacks by Richard Heathfield deleted]
From: John B. Matthews
Subject: Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <nospam-F6D8BD.15355516052009@news.aioe.org>
In article
<····································@z5g2000vba.googlegroups.com>,
·············@gmx.at wrote:
> On 15 Mai, 20:10, "John B. Matthews" <······@nospam.invalid> wrote:
[...]
> > Limiting the length to 0x1FFFFFFF (~0.5 GiB) in gets() eliminates
> > the warning:
[...]
> Great. I will use this limit in filGets().
I am unsure where this limit comes from. I'd have thought to change it
in chk_all.sd7, but you may be right to constrain the value to some
maximum in filGets().
[...]
> Regarding the warnings: For some reason your C compiler is not
> capable to evaluate the expression
>
> sizeof(offsettype) == 8
>
> at compile time.
I'm not seeing this in other contexts, but I have not read the seed7
sources closely. FWIW, I get different warnings from gcc v 4.3.4.
> So the C compiler is complaining about things in unreachable code.
> The other warnings can be avoided with casts. I will try to remove
> this warnings.
Excellent. Ping me when it's time to try a new Mac OS build.
> BTW: Thank you for the list of warnings you sent by mail. I will
> take a closer look at the list, but at first sight I consider the
> warnings harmless. I will try to reduce them nevertheless.
I defer to your knowledge of the program.
[...]
> I still have some questions:
> Do you have other ideas regarding Seed7?
You might consider adding the SourceForge logo to your web page and
using one of their source code management services; I like svn:
<http://apps.sourceforge.net/trac/sourceforge/wiki/WikiStart>
> Is the documentation sufficient?
I found build instructions in "read_me" and the fine manual & FAQ in
"doc". I'd say more than sufficient.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Frank GOENNINGER wrote:
> ·············@gmx.at writes:
>
>> On 13 Mai, 21:51, Frank GOENNINGER <······@googlemail.com> wrote:
>>> Hallo Thomas,
>>>
>>> This:
>>>
>>>> http://seed7.sourceforge.net/faq.htm#development_speed_and_type_checking
>>> Quoting from this text (author: Thomas):
>>>
>>> "When comparing compile-time and runtime type checking it can be
>>> concluded that dynamic typed languages save some programming time
>>> by omitting type declarations, but this time must be paid back with
>>> massive interest rates to do the debugging."
>>>
>>> and this:
>>>
>>>> BTW: It is my opinion that syntax matters and that a
>>>> static type system and many other things make sense.
>>> ... gives quite some insight into the coding approach and coding style
>>> chosen.
>> Come on. From this two sentences you think you have insight into my
>> coding approach. I would say you probably don't have the slightest
>> clue what I use as coding approach.
>
> Well, it does tell that you rely on the compiler to check the type of an
> object. I do say that a pure static typing is a PITA when aiming at
> reusable code. I had to do coding where I could not foresee all possible
> data types being used - just "objects".
That's why we Java programmers have the Object class, generics, and
other goodies. For example if we want to require that some objects have
a run() method, but nothing else, we can use a List<Runnable> to hold
them, and they can be of many different actual types. And the compiler
will alert us if we try to put something non-runnable into the list.
On 2009-05-14, Seamus MacRae <··········@live.ca.nospam> wrote:
> Frank GOENNINGER wrote:
>> ·············@gmx.at writes:
>> Well, it does tell that you rely on the compiler to check the type of an
>> object. I do say that a pure static typing is a PITA when aiming at
>> reusable code. I had to do coding where I could not foresee all possible
>> data types being used - just "objects".
>
> That's why we Java programmers have the Object class, generics, and
> other goodies. For example if we want to require that some objects have
> a run() method, but nothing else, we can use a List<Runnable> to hold
> them, and they can be of many different actual types. And the compiler
> will alert us if we try to put something non-runnable into the list.
Okay, so now I have code dealing with List<Runnable>. What if some other code
just has a List<Object>? It's known that all the objects in that list are in
fact runnable. Oops, that code can't pass the List<Object> to code that works
with a List<Runnable>. You've marred the nice concept of a list with this
additional static type attribute.
Of course, you can write routine which will convert one type of list with
another---with a suitable dynamic check that everything being carried over is
Runnable.
Or you can invent some shim, like a MaybeRunnable wrapper object.
A MaybeRunnable would be some type which is itself runnable,
and holds either an Object or a Runnable. If it holds a Runnable,
then its run method delegates to the Runnable's run method,
otherwise it provides some default behavior.
Now you have the ugly problem that the MaybeRunnable doesn't have the same
identity as the object it encapsulates; it has its own identity. If you have a
routine which, say, searches a list of objects to find one which matches a
given one by identity, it won't work on a list of MaybeRunnable adapters
without additional obfuscation.
Kaz Kylheku wrote:
> On 2009-05-14, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Frank GOENNINGER wrote:
>>> ·············@gmx.at writes:
>>> Well, it does tell that you rely on the compiler to check the type of an
>>> object. I do say that a pure static typing is a PITA when aiming at
>>> reusable code. I had to do coding where I could not foresee all possible
>>> data types being used - just "objects".
>> That's why we Java programmers have the Object class, generics, and
>> other goodies. For example if we want to require that some objects have
>> a run() method, but nothing else, we can use a List<Runnable> to hold
>> them, and they can be of many different actual types. And the compiler
>> will alert us if we try to put something non-runnable into the list.
>
> Okay, so now I have code dealing with List<Runnable>. What if some other code
> just has a List<Object>? It's known that all the objects in that list are in
> fact runnable.
Then the code is poorly-written because it loses type information.
The "other code" here presumably doesn't need to know the objects are
runnable, because it doesn't need to run them. There are two
possibilities: it generates the list, or it merely transforms the list
in some way.
If it generates the list, it's not supposed (in this context) to
generate a list with non-runnables. Either it's supposed to generate a
list with runnables, so should use List<Runnable>, or it's responsible
for making the list but not the individual objects, so it should use
List<T> and accept a Factory<T> (or whatever) to produce the individual
objects, and be called with a Factory<Runnable> resulting in a
List<Runnable> in this particular instance.
If it merely transforms the list, and doesn't care whether they're
runnable, it should not matter. Suppose it sorts the list by priority.
In that case, it wants a List<T extends Comparable<? super T>> or a
Comparator and a List<?>. In the latter case it can be passed a
Comparator and a List<Runnable>, will do its thing, and afterward the
calling code can use the List<Runnable>, which is now sorted. In the
former case, it can be passed a List<PriorityRunnable> where
PriorityRunnable implements Runnable (with an abstract run() method) and
implements Comparable<PriorityRunnable> and get/setPriority(), with
compareTo() using getPriority().
> Now you have the ugly problem that the MaybeRunnable doesn't have the same
> identity as the object it encapsulates; it has its own identity.
This can indeed sometimes be an issue with the decorator pattern, but in
this particular instance that pattern is wholly unnecessary; see above.
["Followup-To:" header set to comp.lang.lisp.]
On 2009-05-14, Seamus MacRae <··········@live.ca.nospam> wrote:
> Kaz Kylheku wrote:
>> On 2009-05-14, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Frank GOENNINGER wrote:
>>>> ·············@gmx.at writes:
>>>> Well, it does tell that you rely on the compiler to check the type of an
>>>> object. I do say that a pure static typing is a PITA when aiming at
>>>> reusable code. I had to do coding where I could not foresee all possible
>>>> data types being used - just "objects".
>>> That's why we Java programmers have the Object class, generics, and
>>> other goodies. For example if we want to require that some objects have
>>> a run() method, but nothing else, we can use a List<Runnable> to hold
>>> them, and they can be of many different actual types. And the compiler
>>> will alert us if we try to put something non-runnable into the list.
>>
>> Okay, so now I have code dealing with List<Runnable>. What if some other code
>> just has a List<Object>? It's known that all the objects in that list are in
>> fact runnable.
>
> Then the code is poorly-written because it loses type information.
>
> The "other code" here presumably doesn't need to know the objects are
> runnable, because it doesn't need to run them. There are two
> possibilities: it generates the list, or it merely transforms the list
> in some way.
>
> If it generates the list, it's not supposed (in this context) to
> generate a list with non-runnables. Either it's supposed to generate a
> list with runnables, so should use List<Runnable>, or it's responsible
> for making the list but not the individual objects, so it should use
> List<T> and accept a Factory<T> (or whatever) to produce the individual
> objects, and be called with a Factory<Runnable> resulting in a
> List<Runnable> in this particular instance.
>
> If it merely transforms the list, and doesn't care whether they're
> runnable, it should not matter. Suppose it sorts the list by priority.
> In that case, it wants a List<T extends Comparable<? super T>> or a
> Comparator and a List<?>. In the latter case it can be passed a
> Comparator and a List<Runnable>, will do its thing, and afterward the
> calling code can use the List<Runnable>, which is now sorted. In the
> former case, it can be passed a List<PriorityRunnable> where
> PriorityRunnable implements Runnable (with an abstract run() method) and
> implements Comparable<PriorityRunnable> and get/setPriority(), with
> compareTo() using getPriority().
At this point, you are building a nice case /against/ static typing; namely you
are erecting piles of useless crap which doesn't actually do anything, other
than check itself for consistency at compile time.
The information content in that crap far exceeds that in the actual problem
being solved, and this is somehow supposed to reassure us that all is well.
I suppose it's an argument of size. Look, we have reams of crap which is
beautifully self-consistent, so it's probably right. The actual logic of the
solution to the original problem constitutes 5% of this crap. Now what are
the odds that there is a bug in it, given that it has logical connections
to something 20 times bigger than itself, which compiles 'n everything?
Also, our defect rate is diluted 20:1. If we make a mistake in the 100 line
dynamic language program, that's one defect per hundred lines. But now,
let's add 1900 lines to make it a static program. Those lines all compile
beautifully and are /provably/ harmless, since they have no run-time semantics.
Now we have a 2000 line program with a defect rate of 1 per 2000 lines.
Our software metrics are telling us we're doing something right;
our process must be getting more mature!
Kaz Kylheku wrote:
>> If it merely transforms the list, and doesn't care whether they're
>> runnable, it should not matter. Suppose it sorts the list by priority.
>> In that case, it wants a List<T extends Comparable<? super T>> or a
>> Comparator and a List<?>. In the latter case it can be passed a
>> Comparator and a List<Runnable>, will do its thing, and afterward the
>> calling code can use the List<Runnable>, which is now sorted. In the
>> former case, it can be passed a List<PriorityRunnable> where
>> PriorityRunnable implements Runnable (with an abstract run() method) and
>> implements Comparable<PriorityRunnable> and get/setPriority(), with
>> compareTo() using getPriority().
>
> At this point, you are building a nice case /against/ static typing; namely you
> are erecting piles of useless crap which doesn't actually do anything, other
> than check itself for consistency at compile time.
Au contraire. They check everything else for consistency at compile time
too. The code that puts things in the list. The code that takes things
out. The code that runs them.
The information that "the things in the list should be runnable" has to
be expressed in the program somehow. In a dynamically-typed
implementation, it would be implicit in the code -- unless the code had
bugs, and then the intent would not be clear. Was it an error that a
non-runnable went into the list, or was it an error that something else
assumed everything taken out of the list was runnable, or was something
else wrong entirely?
The intent could be made clear by adding comments, but now the same
information is in two places: in the code and in comments, and they can
get out of synch.
Or you can use static type checking. Then the types in the code document
the intent, and the things that have to be consistent (the information
about intent, and the actual objects put in the list and actions
performed on the items taken out) are checked for consistency
automatically by the computer to boot. They can't get out of synch. And
if there's an error, the intent is clear. If a List<Object> item is
assumed Runnable assuming they're runnable is the error. If a
non-Runnable is put in a List<Runnable> putting in a non-runnable is the
error.
Problem solved.
> The information content in that crap far exceeds that in the actual problem
> being solved, and this is somehow supposed to reassure us that all is well.
True if you're making a small system. That's why dynamic languages are
convenient for quick-and-dirty one-offs.
False if you're making a large system. It may have O(log N) types in it
versus O(N) operations, and now the information in the "crap" (O(log N))
is greatly exceeded by that in the actual problem being solved (O(N)).
Java starts to look good when you're working on a big system instead of
a little one.
> Also, our defect rate is diluted 20:1. If we make a mistake in the 100 line
> dynamic language program, that's one defect per hundred lines. But now,
> let's add 1900 lines to make it a static program. Those lines all compile
> beautifully and are /provably/ harmless, since they have no run-time semantics.
> Now we have a 2000 line program with a defect rate of 1 per 2000 lines.
> Our software metrics are telling us we're doing something right;
> our process must be getting more mature!
You're forgetting that the 1900 lines will not only check themselves,
but also find type errors in the remaining 100 lines. And that those
1900 lines become only 5000 or so when the other 100 grow to 1,000,000,
tilting the numbers sharply the other way.
P.S. please don't try to hijack replies to groups I don't even read.
Thank you.
Seamus MacRae <··········@live.ca.nospam> writes:
> Kaz Kylheku wrote:
>>> If it merely transforms the list, and doesn't care whether they're
>>> runnable, it should not matter. Suppose it sorts the list by
>>> priority. In that case, it wants a List<T extends Comparable<?
>>> super T>> or a Comparator and a List<?>. In the latter case it can
>>> be passed a Comparator and a List<Runnable>, will do its thing, and
>>> afterward the calling code can use the List<Runnable>, which is now
>>> sorted. In the former case, it can be passed a
>>> List<PriorityRunnable> where PriorityRunnable implements Runnable
>>> (with an abstract run() method) and implements
>>> Comparable<PriorityRunnable> and get/setPriority(), with
>>> compareTo() using getPriority().
>> At this point, you are building a nice case /against/ static typing;
>> namely you
>> are erecting piles of useless crap which doesn't actually do anything, other
>> than check itself for consistency at compile time.
>
> Au contraire. They check everything else for consistency at compile
> time too. The code that puts things in the list. The code that takes
> things out. The code that runs them.
>
> The information that "the things in the list should be runnable" has
> to be expressed in the program somehow. In a dynamically-typed
> implementation, it would be implicit in the code -- unless the code
> had bugs, and then the intent would not be clear. Was it an error that
> a non-runnable went into the list, or was it an error that something
> else assumed everything taken out of the list was runnable, or was
> something else wrong entirely?
>
> The intent could be made clear by adding comments, but now the same
> information is in two places: in the code and in comments, and they
> can get out of synch.
>
> Or you can use static type checking. Then the types in the code
> document the intent, and the things that have to be consistent (the
> information about intent, and the actual objects put in the list and
> actions performed on the items taken out) are checked for consistency
> automatically by the computer to boot. They can't get out of
> synch. And if there's an error, the intent is clear. If a List<Object>
> item is assumed Runnable assuming they're runnable is the error. If a
> non-Runnable is put in a List<Runnable> putting in a non-runnable is
> the error.
>
> Problem solved.
There's a easier and more powerful way to solve that kind of problem.
It is to write a DSL (ie. macros) in Lisp, to generate correct code in
the first place.
Of course, you will object how to be sure the macros are correct?
I'll object how to be sure your type expressions are correct?
And unless your type system is Turing Complete, there are necessarily
specifications you cannot write.
And when your type system is Turing Complete, there are necessarily
bugs written in it, and a lot of time spend on it, because of the
syntactic complexity (eg. C++ templates!).
Lisp macros are just a much simplier and much more powerful to archive
the same results much faster.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) wrote in
···················@galatea.local:
> Lisp macros are just a much simplier and much more powerful to archive
> the same results much faster.
It's hard to make the power of CL macros clear to non-Lispers. They think
in terms of the macros of other programming languages, and have no idea
what CL macros are. From their point of view, we seem to be telling them
we want to use macros as a klugey substitute for C++ templates, or for the
Java type system, or whatever.
This kind of debate tends to go in circles till it degenerates, because the
parties aren't really communicating, because the same words mean different
things to them.
"eric-and-jane-smith" <·······@nospam.com> writes:
> ···@informatimago.com (Pascal J. Bourguignon) wrote in
> ···················@galatea.local:
>
>> Lisp macros are just a much simplier and much more powerful to archive
>> the same results much faster.
>
> It's hard to make the power of CL macros clear to non-Lispers. They think
> in terms of the macros of other programming languages, and have no idea
> what CL macros are. From their point of view, we seem to be telling them
> we want to use macros as a klugey substitute for C++ templates, or for the
> Java type system, or whatever.
>
> This kind of debate tends to go in circles till it degenerates, because the
> parties aren't really communicating, because the same words mean different
> things to them.
Ok, then let me summarize lisp macros as being hooks in the lisp compiler.
Imagine what you could do if you could modify your compiler on the fly:
- you could change your programming language, to specialize it for
your current problem,
- you could implement more sophisticated type or semantic checking,
- you could implement higher level code generation strategies
(eg. instead of just generating machine code from arithmetic
operations or message sending, you could generate programs from a
declarative description of your problem),
- etc.
--
__Pascal Bourguignon__
On May 15, 5:21 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> "eric-and-jane-smith" <·······@nospam.com> writes:
> > ····@informatimago.com (Pascal J. Bourguignon) wrote in
> >···················@galatea.local:
>
> >> Lisp macros are just a much simplier and much more powerful to archive
> >> the same results much faster.
>
> > It's hard to make the power of CL macros clear to non-Lispers. They think
> > in terms of the macros of other programming languages, and have no idea
> > what CL macros are. From their point of view, we seem to be telling them
> > we want to use macros as a klugey substitute for C++ templates, or for the
> > Java type system, or whatever.
>
> > This kind of debate tends to go in circles till it degenerates, because the
> > parties aren't really communicating, because the same words mean different
> > things to them.
>
> Ok, then let me summarize lisp macros as being hooks in the lisp compiler.
>
> Imagine what you could do if you could modify your compiler on the fly:
>
> - you could change your programming language, to specialize it for
> your current problem,
>
> - you could implement more sophisticated type or semantic checking,
>
> - you could implement higher level code generation strategies
> (eg. instead of just generating machine code from arithmetic
> operations or message sending, you could generate programs from a
> declarative description of your problem),
>
> - etc.
>
> --
> __Pascal Bourguignon__
Not only can you modify your compiler on the fly,
you can generate code and modify your program on the fly.
There are certain languages where you *can* do that,
but I doubt that they make that sort of functionality *easy*.
On May 15, 8:43 am, ··················@gmail.com wrote:
> Not only can you modify your compiler on the fly,
> you can generate code and modify your program on the fly.
>
> There are certain languages where you *can* do that,
> but I doubt that they make that sort of functionality *easy*.
Forget what I said earlier about fully-automatic assault rifles. This
lets you shoot yourself in the foot with a tactical nuclear bunker-
buster.
Your code base has one bug. Of course the compiler can't see it
(dynamic typing). So you run it. Whoops. Now your code base has fifty
bugs, because the one bug was in code that modified it!
Happy debugging. See you in 2040 or thereabouts. :)
Series Expansion <·······@gmail.com> writes:
> On May 15, 8:43��am, ··················@gmail.com wrote:
> > Not only can you modify your compiler on the fly,
> > you can generate code and modify your program on the fly.
> >
> > There are certain languages where you *can* do that,
> > but I doubt that they make that sort of functionality *easy*.
...
> Your code base has one bug. Of course the compiler can't see it
> (dynamic typing). So you run it. Whoops. Now your code base has fifty
> bugs, because the one bug was in code that modified it!
Well, there's really only one bug to find and fix. You find and fix it,
and then regenerate the code and -- amazingly enough -- fix 50 bugs all
at once and automatically!
Wow, talk about productivity wins.
Of course the alternative, without these features would be the tried and
true method of copy-paste-modify, which will put the bug into 50
different places, and you'll probably only fix 45 of them in the first
couple of rounds of debugging.
Hmmm. Perhaps I should do more Java programming. It's nice to know
that bugs are non-existent in that language.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 15, 8:43Ž am, ··················@gmail.com wrote:
>> > Not only can you modify your compiler on the fly,
>> > you can generate code and modify your program on the fly.
>> >
>> > There are certain languages where you *can* do that,
>> > but I doubt that they make that sort of functionality *easy*.
> ...
>> Your code base has one bug. Of course the compiler can't see it
>> (dynamic typing). So you run it. Whoops. Now your code base has fifty
>> bugs, because the one bug was in code that modified it!
>
> Well, there's really only one bug to find and fix. You find and fix it,
> and then regenerate the code and -- amazingly enough -- fix 50 bugs all
> at once and automatically!
>
> Wow, talk about productivity wins.
Not to mention it's easier to spot one bug that shows up in 50 places
than 50 different little bugs in 50 different reimplementations of the
same thing.
One might as well use the same argument against functions. Much better
to manually inline all your code so mistakes are of limited scope --
never mind you've just given yourself more chances to make mistakes.
On May 15, 5:28 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> ····@sevak.isi.edu (Thomas A. Russ) writes:
> > Series Expansion <·······@gmail.com> writes:
> >> On May 15, 8:43Ž am, ··················@gmail.com wrote:
> >> > Not only can you modify your compiler on the fly,
> >> > you can generate code and modify your program on the fly.
> >> > There are certain languages where you *can* do that,
> >> > but I doubt that they make that sort of functionality *easy*.
> > ...
> >> Your code base has one bug. Of course the compiler can't see it
> >> (dynamic typing). So you run it. Whoops. Now your code base has fifty
> >> bugs, because the one bug was in code that modified it!
>
> > Well, there's really only one bug to find and fix. You find and fix it,
> > and then regenerate the code
If one was wise enough to retain copies of the pre-automated-
modification code, this might work.
> Not to mention it's easier to spot one bug that shows up in 50 places
> than 50 different little bugs in 50 different reimplementations of the
> same thing.
>
> One might as well use the same argument against functions. Much better
> to manually inline all your code so mistakes are of limited scope --
> never mind you've just given yourself more chances to make mistakes.
If you think that, then you've failed to comprehend the precise nature
of my objection. Functions do not overwrite other parts of the
codebase. Automated code-editing tools do, and if you did not keep
backups and they screw up, they may do tremendous damage.
On May 15, 3:44 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 8:43Ž am, ··················@gmail.com wrote:
> > > Not only can you modify your compiler on the fly,
> > > you can generate code and modify your program on the fly.
>
> > > There are certain languages where you *can* do that,
> > > but I doubt that they make that sort of functionality *easy*.
> ...
> > Your code base has one bug. Of course the compiler can't see it
> > (dynamic typing). So you run it. Whoops. Now your code base has fifty
> > bugs, because the one bug was in code that modified it!
>
> Well, there's really only one bug to find and fix. You find and fix it,
> and then regenerate the code
That might work, if you kept a copy of the pre-automated-modification
code just in case.
> Hmmm. Perhaps I should do more Java programming. It's nice to know
> that bugs are non-existent in that language.
Most illogical.
On May 15, 2:14 pm, Series Expansion <·······@gmail.com> wrote:
> Your code base has one bug.
Good sir I take offense!
My code base is immaculate!
:-)
> Of course the compiler can't see it
> (dynamic typing). So you run it.
Compiler actually can see it, if I declare my types, and it happens to
be a type error.
However, if I am writing a function that at runtime writes and
compiles another function;
I won't know that the secondary function has an error in it until I
generate and compile it.
But this really demonstrates to me the importance of testing your code
*before* you ship it, rather than the evils of meta-programming.
But that has nothing to do with dynamic typing...(Aside from the fact
that it is very hard (most likely impossible) to do this sort of stuff
in a statically typed language).
All of this is actually orthogonal to compiler checks.
(Aside: I don't understand everyone's obsession with type errors! I
rarely make them!)
> Whoops. Now your code base has fifty
> bugs, because the one bug was in code that modified it!
No, *YOUR* code base has 50 bugs.
This is a good example of what would happen if I were using Java (or
any statically typed language; I believe) to do meta-programming.
(Also a good example of why I wouldn't do that).
--
However, *MY* code base *still* has one bug.
Because I'm generating code and evaluating it.
I fix the one bug and go on my merry way,
living my life of decadence and excess,
lucky should I live to see the year 2040!
On May 15, 6:01 pm, ··················@gmail.com wrote:
> On May 15, 2:14 pm, Series Expansion <·······@gmail.com> wrote:
>
> > Your code base has one bug.
>
> Good sir I take offense!
> My code base is immaculate!
> :-)
Sure, sure, that's what they all say. :)
> > Of course the compiler can't see it
> > (dynamic typing). So you run it.
>
> Compiler actually can see it, if I declare my types, and it happens to
> be a type error.
What are you coding in? Java? Or maybe something like OCaml, given
your probable predilection for more functional-style languages.
Obviously not Lisp; how can the compiler catch a type error in code
that has no types, just list atoms?
> However, if I am writing a function that at runtime writes and
> compiles another function;
> I won't know that the secondary function has an error in it until I
> generate and compile it.
> But this really demonstrates to me the importance of testing your code
> *before* you ship it, rather than the evils of meta-programming.
Think of static typing and the compiler's type checking as a kind of
automatic testing of one aspect of the design that inevitably has full
code coverage.
It's no substitute for doing further, less-automatic testing, but it's
part of the same basic philosophy.
> But that has nothing to do with dynamic typing...(Aside from the fact
> that it is very hard (most likely impossible) to do this sort of stuff
> in a statically typed language).
Do what sort of stuff? Accidentally wind up with a Float in a pack of
Strings? Why would you want to? :)
> All of this is actually orthogonal to compiler checks.
No, of course not; without static typing, the compiler has no type
information to use when checking anything, since as far as it knows,
any variable might hold any value of any type whatsoever.
> (Aside: I don't understand everyone's obsession with type errors! I
> rarely make them!)
Or, perhaps, you have made few of them *that you know about*. Of
course, you might know of a lot more if your compiler detected them
all.
> > Whoops. Now your code base has fifty
> > bugs, because the one bug was in code that modified it!
>
> No, *YOUR* code base has 50 bugs.
Don't try to foist your buggy, machine-generated code on me. I want no
part of it. Here -- you keep it. :)
> This is a good example of what would happen if I were using Java (or
> any statically typed language; I believe) to do meta-programming.
It's a good example of what would happen if you were to do meta-
programming, period.
At least Java meta-programming doesn't have the bane of macro-based
meta-programming: variable capture.
> I fix the one bug and go on my merry way,
> living my life of decadence and excess,
> lucky should I live to see the year 2040!
If you live to see 2040, you'll probably have been reimplemented on an
artificial, nanotechnological hardware platform. And ported to Java. :)
On May 16, 7:46 am, Series Expansion <·······@gmail.com> wrote:
> > > Of course the compiler can't see it
> > > (dynamic typing). So you run it.
>
> > Compiler actually can see it, if I declare my types, and it happens to
> > be a type error.
>
> What are you coding in? Java? Or maybe something like OCaml, given
> your probable predilection for more functional-style languages.
>
> Obviously not Lisp; how can the compiler catch a type error in code
> that has no types, just list atoms?
Go back and read what the guy said: "... if I declare my types,"
You can make type declarations in Lisp. They look like:
(declare (float x y z)
(list a b c))
Once you have them, a good compiler (i.e. any of the commonly used
implementations, including many open-source ones) will start to give
warnings when you start to write type-buggy code.
> > But that has nothing to do with dynamic typing...(Aside from the fact
> > that it is very hard (most likely impossible) to do this sort of stuff
> > in a statically typed language).
>
> Do what sort of stuff? Accidentally wind up with a Float in a pack of
> Strings? Why would you want to? :)
Do things like have a pack of THINGS, rather than a pack of strings.
Paul Graham repeats often, for good reason, that one of Lisp's great
strengths is its flexibility. You can have a heterogenous list and
Lisp won't blink. You can have a function that returns some data, or
NIL if the data is unavailable. You can bind the result of that
function to a variable without worrying about types.
> > All of this is actually orthogonal to compiler checks.
>
> No, of course not; without static typing, the compiler has no type
> information to use when checking anything, since as far as it knows,
> any variable might hold any value of any type whatsoever.
See the above re: declarations.
> > This is a good example of what would happen if I were using Java (or
> > any statically typed language; I believe) to do meta-programming.
>
> It's a good example of what would happen if you were to do meta-
> programming, period.
>
> At least Java meta-programming doesn't have the bane of macro-based
> meta-programming: variable capture.
Variable capture is a useful tool sometimes, for example in anaphoric
macros. Like normal if, when, etc, except that they bind the result of
the test to the variable IT.
Java is meta-programming for JVM bytecode. Lisp is meta-programming
for Lisp. By being a meta-language for itself, Lisp allows you to
express a huge variety of concepts. Your imagination is really the
only significant limit, second maybe to carpal tunnel -- and you
barely get any of that because macros shrink source code.
- Adlai
Adlai wrote:
> On May 16, 7:46 am, Series Expansion <·······@gmail.com> wrote:
[Some attributions are missing. Sorry.]
>>> But that has nothing to do with dynamic typing...(Aside from the fact
>>> that it is very hard (most likely impossible) to do this sort of stuff
>>> in a statically typed language).
>> Do what sort of stuff? Accidentally wind up with a Float in a pack of
>> Strings? Why would you want to? :)
>
> Do things like have a pack of THINGS, rather than a pack of strings.
You can do that in Java. List<Object>, anyone?
> Paul Graham repeats often, for good reason, that one of Lisp's great
> strengths is its flexibility. You can have a heterogenous list and
> Lisp won't blink.
Series mentioned some Java myths being perpetuated in this thread: Java
is slow, Java lacks reflection, Java isn't Turing complete. Well, this
seems to be another one: Java doesn't have heterogeneous lists.
Heck, prior to version 5 it didn't have NONheterogeneous lists.
Sheesh!
> You can have a function that returns some data, or
> NIL if the data is unavailable.
Java can do this (return an object or null), and java.util.Map.get()
does it and is in the standard library.
Lispers, please at least *learn* a bit about Java before criticizing it!
> You can bind the result of that function to a variable without
> worrying about types.
Java programmers wish for a way to bind something to a variable that
WILL generate compiler errors if it might be null, and they want that
variable to have to be non-null. So they could write:
@NotNull String s;
{
String t = map.get(key);
if (t == null) {
// Do something;
} else {
s = t;
}
}
s.length();
and the compiler would check that the assignment of t to s cannot
possibly assign null.
Java 7 might have this feature.
>> At least Java meta-programming doesn't have the bane of macro-based
>> meta-programming: variable capture.
>
> Variable capture is a useful tool sometimes, for example in anaphoric
> macros.
No normal application developer is going to, or should need to, concern
himself with "anaphoric" anything. At least not unless he works in
engineering on the starship enterprise, where not a day goes by without
metaphasic this, polaric that, and all kinds of fluxes and subspace
whosits needing to be dealt with.
> Java is meta-programming for JVM bytecode. Lisp is meta-programming
> for Lisp. By being a meta-language for itself, Lisp allows you to
> express a huge variety of concepts.
Including such doozies as "this statement is false"?
Unbounded self-referentiality reputedly drove Georg Cantor mad and led
to the reformulation of half of mathematics to avoid inconsistencies
like that.
> Your imagination is really the only significant limit, second maybe
> to carpal tunnel
In what dream world? Here in the real world we also have to worry about
code maintainability, code readability to other people, and bug hunting,
not to mention slippery requirements and user complaints of every stripe.
On May 16, 10:00 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Series mentioned some Java myths being perpetuated in this thread: Java
> is slow, Java lacks reflection, Java isn't Turing complete. Well, this
> seems to be another one: Java doesn't have heterogeneous lists.
>
> Heck, prior to version 5 it didn't have NONheterogeneous lists.
I didn't specifically criticize Java. I don't know it well enough to
criticise it specifically. I was pointing out the advantages of having
some type flexibility. I see now that Java does have some amount of
flexibility. Lisp has complete type flexibility, with the option of
adding declarations that a good compiler will use to give you some
warnings.
> No normal application developer is going to, or should need to, concern
> himself with "anaphoric" anything. At least not unless he works in
> engineering on the starship enterprise, where not a day goes by without
> metaphasic this, polaric that, and all kinds of fluxes and subspace
> whosits needing to be dealt with.
Anaphoric macros are extremely useful. There's a hidden anaphor in the
CL loop macro, which binds the value of IT onto a previously-evaluated
conditional. In other words, within a loop, you can say something like
(loop
for x in list-of-things
when (find x other-list) collect it)
That's all there is to anaphors. This example in the loop macro is the
only built-in anaphor that I know of in CL, but it's very easy to
define syntax for them using macros:[1]
(defmacro aif (test-form then-form &optional else-form)
`(let ((it ,test-form))
(if it ,then-form ,else-form)))
There you have it -- a macro that uses variable capture to accomplish
a fairly useful task. Many functions -- and not just in Lisp -- follow
the convention of returning some useful value if they "succeed", or a
false value (NIL in Lisp, maybe False in Python or 0 in C++, etc) if
they "fail". This macro saves a lot of boilerplate in the long run if
you use functions like that.
> In what dream world? Here in the real world we also have to worry about
> code maintainability, code readability to other people, and bug hunting,
> not to mention slippery requirements and user complaints of every stripe.
Lisp doesn't limit you from dealing with those. Lisp code can be very
readable -- most often, unreadable Lisp code is due to bad formatting,
rather than the syntax itself. Yes, some macros are hard for a non-
Lisper to understand, but 20 minutes with a good tutorial like PCL[2]
or Successful Lisp[3] is actually enough to understand most Lisp code.
It's very easy to maintain Lisp code and hunt bugs, both because of
the aforementioned ability to manipulate your code while it's running,
and because of the interactive nature of building code (not a feature
unique to Lisp).
And Lisp thrives on slippery requirements because of these
flexibilities. If you're just starting out on a problem, you can use
some form of linked cons cells to represent almost any data structure
for prototyping, and the interactive nature of building code makes it
very easy to test variations while you're building your system.
Java does have many advantages over other "standard" programming
languages in use today. I'm not trying to downplay Java in any way. If
I had to use one of the standard languages, I'd pick Java over most
other options. However, I (along with a few others here at c.l.l) am
just trying to point out the strength, flexibility, and, despite your
preconceptions about a language second only to FORTRAN in its age,
modernity of Common Lisp.
Let's both try and keep this a civil discussion.
- Adlai
I forgot a few notes:
[1] from page 191 of On Lisp, by Paul Graham
[2] www.gigamonkeys.com
[3] http://www.psg.com/~dlamkins/sl/
By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It has
all the functionality that you've described an IDE should have. The
ONE thing it doesn't have is popping out stuff into neat little help
bubbles, but that's cosmetic, not a functionality. It highlights
source errors, can link in to profiling utilities, has half a zillion
different ways to poke and prod your programs to assist debugging --
there is nothing 1983 about SLIME + Emacs, other than maybe the fixed-
with font in the menus.
And yes, you can use your mouse for everything you'd expect in any
other windowed program.
Emacs also has a psychotherapist, programmed in Lisp. I'm not kidding.
It's really relaxing to chat with it every now and then.
- Adlai
Adlai wrote:
> I forgot a few notes:
>
> [1] from page 191 of On Lisp, by Paul Graham
> [2] www.gigamonkeys.com
> [3] http://www.psg.com/~dlamkins/sl/
>
>
> By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It has
> all the functionality that you've described an IDE should have. The
> ONE thing it doesn't have is popping out stuff into neat little help
> bubbles, but that's cosmetic, not a functionality.
Being able to see a nicely organized workspace with visible context for
displayed informaton, instead of just one page of text at a time in one
window, is "cosmetic, not functionality"? Pardon me if I disagree.
Contrast these alternatives, for example:
There's code on the screen. You arrow to a macro, type some hotkey
newbies will keep having to go to the help or use a crib-sheet to
remember, and the screen changes to a screen showing the macro
definition. To get back, either you have to reopen the previous file and
page down to where you were, or maybe there's some hotkey that functions
like a browser's "back" button. Maybe unsaved changes were lost if the
first file was modified and not saved, and the macro definition was in a
different file; hopefully not.
There's code on the screen. You right-click on a macro and see
neatly-labeled options including "view definition". Clicking that
produces a separate window containing the definition. You can drag it to
position it so that you can view the definition and the code that's
using the macro side-by-side if you want to, or expand it into a
full-size window and make changes to the macro if you want to. The
editor will keep both files open, simultaneously, in windows you can
arrange or overlap as you see fit, or in browser tabs, or similarly. It
certainly won't discard unsaved changes without prompting you first.
The former is the typical experience with a relatively "enlightened"
terminal-mode editor, restricted as it is to a single grid of ASCII text
and keyboard input; even if you can have multiple files open at once you
will generally only see one at a time and may not even see any tab
headings or other indications that there are any others open than the
one in front of you right now. Generally the limited capabilities of the
display will limit the software's ability to provide cues and to inform
you peripherally of the general status of the system. At best, it's like
using NetBeans while peering through a keyhole, then, with your mouse
busted, and at worst like trying to juggle multiple files in WordStar 1.0.
The latter is the typical experience with a well-designed modern IDE
like NetBeans.
> It highlights
> source errors, can link in to profiling utilities, has half a zillion
> different ways to poke and prod your programs to assist debugging --
> there is nothing 1983 about SLIME + Emacs, other than maybe the fixed-
> with font in the menus.
>
> And yes, you can use your mouse for everything you'd expect in any
> other windowed program.
Now I'm confused. Which windowed program were we discussing? Not the
text editor, which predates Windows 1.0 by more than a decade. SLIME? I
thought someone said it was a script in the editor's internal scripting
language.
> Emacs also has a psychotherapist, programmed in Lisp. I'm not kidding.
> It's really relaxing to chat with it every now and then.
This is software you expect me to take seriously? And here I'd thought
putting that damn paperclip in office productivity software was asking
for it. (And was proved right.)
On May 16, 11:17 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Adlai wrote:
> > I forgot a few notes:
>
> > [1] from page 191 of On Lisp, by Paul Graham
> > [2]www.gigamonkeys.com
> > [3]http://www.psg.com/~dlamkins/sl/
>
> > By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It has
> > all the functionality that you've described an IDE should have. The
> > ONE thing it doesn't have is popping out stuff into neat little help
> > bubbles, but that's cosmetic, not a functionality.
>
> Being able to see a nicely organized workspace with visible context for
> displayed informaton, instead of just one page of text at a time in one
> window, is "cosmetic, not functionality"? Pardon me if I disagree.
I think it depends... for example, some information can just as
concisely be displayed in the status bar of the editor, as is the
information I mentioned earlier about the syntax of the current form.
> Contrast these alternatives, for example:
>
> There's code on the screen. You arrow to a macro, type some hotkey
> newbies will keep having to go to the help or use a crib-sheet to
> remember, and the screen changes to a screen showing the macro
> definition. To get back, either you have to reopen the previous file and
> page down to where you were, or maybe there's some hotkey that functions
> like a browser's "back" button. Maybe unsaved changes were lost if the
> first file was modified and not saved, and the macro definition was in a
> different file; hopefully not.
Not at all like Emacs. You're thinking about some version of Emacs
from before when I was born. I just now went to Help -> About Emacs,
and here's the version info:
This is GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02
> There's code on the screen. You right-click on a macro and see
> neatly-labeled options including "view definition". Clicking that
> produces a separate window containing the definition. You can drag it to
> position it so that you can view the definition and the code that's
> using the macro side-by-side if you want to, or expand it into a
> full-size window and make changes to the macro if you want to. The
> editor will keep both files open, simultaneously, in windows you can
> arrange or overlap as you see fit, or in browser tabs, or similarly. It
> certainly won't discard unsaved changes without prompting you first.
That's basically what programming in Emacs is like nowadays!
> The former is the typical experience with a relatively "enlightened"
> terminal-mode editor, restricted as it is to a single grid of ASCII text
> and keyboard input; even if you can have multiple files open at once you
> will generally only see one at a time and may not even see any tab
> headings or other indications that there are any others open than the
> one in front of you right now. Generally the limited capabilities of the
> display will limit the software's ability to provide cues and to inform
> you peripherally of the general status of the system. At best, it's like
> using NetBeans while peering through a keyhole, then, with your mouse
> busted, and at worst like trying to juggle multiple files in WordStar 1.0.
>
> The latter is the typical experience with a well-designed modern IDE
> like NetBeans.
>
> > It highlights
> > source errors, can link in to profiling utilities, has half a zillion
> > different ways to poke and prod your programs to assist debugging --
> > there is nothing 1983 about SLIME + Emacs, other than maybe the fixed-
> > with font in the menus.
>
> > And yes, you can use your mouse for everything you'd expect in any
> > other windowed program.
>
> Now I'm confused. Which windowed program were we discussing? Not the
> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
> thought someone said it was a script in the editor's internal scripting
> language.
YES, this is Emacs, the same old text editor from the GNU that has
gone through 22.1.1 versions to this current incarnation that I use
right now. I can use the mouse to select text, navigate menus, choose
options, etc -- just like Microsoft Word & co. Heck, search and
replace is child's play for this Emacs -- it can do all the same
search and replace stuff with RegExps too. Put that in NetBeans's pipe
and smoke it!
Look, all we're saying is, Emacs today isn't what Emacs was 30 (?)
years ago. It's the same as with IBM. If somebody who had been in a
coma for 30 years heard that I was using an IBM Thinkpad, he'd
probably envision some sort of "padded" mainframe, not a laptop.
> > Emacs also has a psychotherapist, programmed in Lisp. I'm not kidding.
> > It's really relaxing to chat with it every now and then.
>
> This is software you expect me to take seriously? And here I'd thought
> putting that damn paperclip in office productivity software was asking
> for it. (And was proved right.)
OK, the shrink is a bit of a joke, it's a clone of an early AI program
that simulates a Rogerian Psychiatrist. But aside from the shrink,
Emacs nowadays is as functional a word processor as any. SLIME adds
integration to an external Lisp compiler (Emacs Lisp is a different
dialect of Lisp, and it's basically only useful for customizing
Emacs). Everybody here is completely serious when they say that Emacs
is just as powerful as NetBeans, or any other modern IDE.
- Adlai
Seamus MacRae wrote:
>> Now I'm confused. Which windowed program were we discussing? Not the
>> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>> thought someone said it was a script in the editor's internal scripting
>> language.
Adlai wrote:
> YES, this is Emacs, the same old text editor from the GNU that has
> gone through 22.1.1 versions to this current incarnation that I use
> right now. I can use the mouse to select text, navigate menus, choose
> options, etc -- just like Microsoft Word & co. Heck, search and
> replace is child's play for this Emacs -- it can do all the same
> search and replace stuff with RegExps too. Put that in NetBeans's pipe
> and smoke it!
Well, emacs can't debug Java code, but it's still a fine editor. As for
Paul's, er, rather, Seamus's refusal to awaken from his coma, we've seen this
kind of trollishness before. Don't pay it no never mind.
> Look, all we're saying is, Emacs today isn't what Emacs was 30 (?)
> years ago. It's the same as with IBM. If somebody who had been in a
> coma for 30 years heard that I was using an IBM Thinkpad, he'd
> probably envision some sort of "padded" mainframe, not a laptop.
Seamus is apparently one of those who refuses to recognize that a program has
changed and modernized over the years. I predict that you will never get him
to argue about emacs in terms of its modern feature set; instead he'll grip
with white knuckles preconceptions about a version not seen since the
Pleistocene. I do hope I'm wrong, however, and that he will have the decency
at least to discuss the same software that you are. It could happen; I've
been wrong before.
--
Lew
Lew wrote:
> Seamus MacRae wrote:
>>> Now I'm confused. Which windowed program were we discussing? Not the
>>> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>>> thought someone said it was a script in the editor's internal scripting
>>> language.
>
> Adlai wrote:
>> YES, this is Emacs, the same old text editor from the GNU that has
>> gone through 22.1.1 versions to this current incarnation that I use
>> right now. I can use the mouse to select text, navigate menus, choose
>> options, etc -- just like Microsoft Word & co. Heck, search and
>> replace is child's play for this Emacs -- it can do all the same
>> search and replace stuff with RegExps too. Put that in NetBeans's pipe
>> and smoke it!
>
> Well, emacs can't debug Java code, but it's still a fine editor.
Fine for confusing and frustrating new users, maybe. I'm not aware that
it has any other uses that other applications don't do better, or else
as good and with a better user interface, save for text editing over
telnet or ssh.
> As for Paul's, er, rather, Seamus's refusal to awaken from his coma
This makes absolutely no sense. For one, the error with the names -- why
not just delete the error and say "As for Seamus's refusal..."?
Paul Foley and Paul Donnelly are probably both going to find your
misattribution troubling, since I'm fairly certain that neither of them
agree with me, and your slip-up up there implies that you nearly imputed
my position to one of them as they are the only two people posting to
this thread using that given name.
Moreover, you should know that a coma is not a state in which someone is
capable of composing and sending Usenet posts.
> we've seen this kind of trollishness before. Don't pay it no never
> mind.
Personal attacks are not a constructive or productive use of time or
bandwidth.
>> Look, all we're saying is, Emacs today isn't what Emacs was 30 (?)
>> years ago. It's the same as with IBM. If somebody who had been in a
>> coma for 30 years heard that I was using an IBM Thinkpad, he'd
>> probably envision some sort of "padded" mainframe, not a laptop.
>
> Seamus is apparently one of those who refuses to recognize that a
> program has changed and modernized over the years.
You can modernize a box of ASCII only so much. Adding all the fancy
ASCII-twiddling bells and whistles in the world won't cause some
threshold to be reached at which magically the grid of letters is no
longer extremely limited as a way of presenting a view of the system's
state to the user.
It's like black and white versus color -- you can use all kinds of
tricks to work around the lack of color, but it still will not be the
same, or nearly as powerful as, if you had the capability for color in
the first place.
Think of it like this. An application's basic low-level implementation
and host interface is like a television set. In the case of a text
terminal application, it's like a black and white set; in the case of a
GUI application, a color one. Adding features is like adding more
programs that can be watched on that set. But if you want to convey a
picture of a red rose including the fact that it is red, the program can
do this directly on the color set. On the black and white set, the best
it can do is say, somewhere, that the thing is red; it will look gray.
The user can certainly still glean the information that the rose is red,
so in a certain strict sense they're equally powerful. But the user has
to read or listen to some caption and think about it instead of simply
seeing it instantly. This hurts usability and productivity.
At the same time, an application's basic low-level implementation and
host interface is like a foundation. You can't make major changes to it
without completely demolishing the house, carting off the rubble, and
erecting a new building on the land. And then it's not the same
application anymore.
Thus I don't put much stock in your remarks about "modernization". Not
only doesn't it seem possible to modernize the bits that most need it
without replacing emacs with a completely different program, in which
case I'll replace it with NetBeans, but when I used it in 2006 it still
seemed about as modern as bell-bottoms and Vietnam.
> I predict that you will never get him to argue about emacs in terms
> of its modern feature set
Features are not the issue so much as the user interface through which
the user accesses these features. The user interface of emacs is limited
in its expressiveness. Worse, it has a characteristic that I despise: it
gets in between the user and his goals, so instead of thinking in the
problem domain he's thinking "how do I get this program to do X", "how
do I get it to display Y", and so forth. When I used it in 2006, as on
all previous occasions, I found my attention divided between the stuff I
was editing and thinking about what keys or commands to type. The
interface trips you up and slows you down and you never, ever get used
to it. It's like trying to use a standard shift automobile after getting
used to the convenient interface of an automatic, only magnified perhaps
a thousandfold, that and you never, ever get used to it. Whereas you do
eventually get used to a standard shift if you use one occasionally.
> version not seen since the Pleistocene.
There was no computer software until about 10,000 years into the
Holocene. Check your watch, it must have stopped.
Adlai wrote:
> On May 16, 11:17 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Adlai wrote:
>>> I forgot a few notes:
>>> [1] from page 191 of On Lisp, by Paul Graham
>>> [2]www.gigamonkeys.com
>>> [3]http://www.psg.com/~dlamkins/sl/
>>> By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It has
>>> all the functionality that you've described an IDE should have. The
>>> ONE thing it doesn't have is popping out stuff into neat little help
>>> bubbles, but that's cosmetic, not a functionality.
>> Being able to see a nicely organized workspace with visible context for
>> displayed informaton, instead of just one page of text at a time in one
>> window, is "cosmetic, not functionality"? Pardon me if I disagree.
>
> I think it depends...
Hardly ever. Even when the task being done in the application is very
simple, the user benefits from a modern interface that lets them easily
use MORE THAN ONE APPLICATION relatively seamlessly, without clunky
switching mechanics (like unix "fg" shell commands).
About the only exceptions I'd grant are a few workplace applications
that have one main screen and really really should get the user's
undivided attention at all times. The program that displays radar
information on a screen in front of an air traffic controller is the
only one that immediately comes to mind as definitely belonging to your
"it depends" exceptions.
> for example, some information can just as
> concisely be displayed in the status bar of the editor
One fairly short line of text may suffice for that, but not for, say,
displaying the full Javadocs of the method whose name you've just typed,
or dropping down a whole menu of possible completions, and lacks a way
for the user to select from among the latter, besides.
>> Contrast these alternatives, for example:
>>
>> There's code on the screen. You arrow to a macro, type some hotkey
>> newbies will keep having to go to the help or use a crib-sheet to
>> remember, and the screen changes to a screen showing the macro
>> definition. To get back, either you have to reopen the previous file and
>> page down to where you were, or maybe there's some hotkey that functions
>> like a browser's "back" button. Maybe unsaved changes were lost if the
>> first file was modified and not saved, and the macro definition was in a
>> different file; hopefully not.
>
> Not at all like Emacs. You're thinking about some version of Emacs
> from before when I was born. I just now went to Help -> About Emacs,
> and here's the version info:
You must be joking. The above is "like" every single pre-1990
application I have ever used, and pre-1990 applications do not have
"Help -> About", though they may have some sort of "about" feature
accessed in some way such as by typing control-A or typing "about" at an
internal prompt or "foo --version" at a shell prompt.
The final thing to note here is that emacs was already over a decade old
in 1990. We're lucky its primary means of interaction doesn't involve a
deck-sorter.
> This is GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02
A 2007 Model T would still not be a Mercedes-Benz. Particularly if it
were sufficiently "Model-T-like" to not be a Model T in name only.
>> There's code on the screen. You right-click on a macro and see
>> neatly-labeled options including "view definition". Clicking that
>> produces a separate window containing the definition. You can drag it to
>> position it so that you can view the definition and the code that's
>> using the macro side-by-side if you want to, or expand it into a
>> full-size window and make changes to the macro if you want to. The
>> editor will keep both files open, simultaneously, in windows you can
>> arrange or overlap as you see fit, or in browser tabs, or similarly. It
>> certainly won't discard unsaved changes without prompting you first.
>
> That's basically what programming in Emacs is like nowadays!
Perhaps I should let you guys know a little secret: I've used emacs.
Recently. Had to do some editing on a unix box I had no physical access
to, and which didn't have remote X capability, around mid-2006.
In a nutshell: Ugh. Next time I'm demanding hazard pay, I think it
raised my blood pressure dangerously high trying to work with the
flippin' thing, and at the age of fifty I need to start paying serious
attention to matters like my blood pressure.
The upshot here is, I know the above is bull. Right-click with what
pointer? Separate windows? The best emacs could do (in 2006) was to
split the screen vertically, which meant looking at both documents
through a pinhole, or split the screen horizontally, which meant looking
at each document through a gap between horizontal window blinds.
>> Now I'm confused. Which windowed program were we discussing? Not the
>> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>> thought someone said it was a script in the editor's internal scripting
>> language.
>
> YES
A script in the editor's scripting language should not be able to go
directly to the operating system to request window handles and suchlike,
yet this would be necessary for SLIME to do as you've just claimed.
The editor's scripting language capability is therefore a disaster
waiting to happen. Even Word's infamous susceptibility to macro viruses
doesn't endanger the host operating system or computer; if your emacs
scripts have unsandboxed access to the system, a hostile one could, say,
send a large volume of email spam that YOU would get in trouble for.
> I can use the mouse to select text, navigate menus, choose
> options, etc
Yes, when you decide to eschew emacs in favor of Notepad++, I'm sure you
can.
> Heck, search and replace is child's play for this Emacs
Search and replace in emacs is an exercise in hair-pulling,
pill-popping, and spending hours poring over the (extensive, but with
poor browsing UI) online help.
> it can do all the same search and replace stuff with RegExps too.
> Put that in NetBeans's pipe and smoke it!
NetBeans has search, incremental search, search and replace, and
regexps. Oh, and it has a decently usable interface on these. Oh, and it
has searches that can tell instance variables, static variables, class
names, method names, package names, and other categories of identifier
apart and even know which ones are in scope where. You can find every
instance of java.util.Date in your code without it also matching
javax.sql.Date. You can't do this in a plain old text editor, a search
for "date" will find both and a search for "java.util.date" won't find
either occurrence of java.util.Date in "Date today = new Date();" in a
file whose preamble contains "import java.util.Date;".
Oh, and it can do such smart things as renaming a class properly. If you
rename mypackage.Foo to mypackage.Bar with NetBeans, it changes:
* References to the class
* Including as just "Foo"
* Without renaming references to otherpackage.Foo
* Even references that just called it "Foo"
* and it will even rename the Foo.java file to Bar.java for you.
Renaming methods works similarly, and will recognize Foo.method():
* as "method()" in Foo or a subclass
* and as "someFoo.\nmethod()", i.e. split across lines
* even when "someFoo"'s type is declared far away
* and without hitting "Mumble.method()" or any other same-name
method.
Both will update links in the Javadocs too.
No text editor can approach this degree of integration with the target
language.
> Look, all we're saying is, Emacs today isn't what Emacs was 30 (?)
> years ago.
Once a Model T, always a Model T. No amount of cosmetic improvements or
bug-fixing will allow it to escape its fundamental nature, nor to evade
the constraints set by fundamental design choices made in its infancy
and now woven throughout the code.
Only a total rewrite could accomplish such things, and the result would
then be emacs in name only.
> It's the same as with IBM. If somebody who had been in a
> coma for 30 years heard that I was using an IBM Thinkpad, he'd
> probably envision some sort of "padded" mainframe, not a laptop.
Same company, different product, rather than same product, different
version. Your analogy does not hold.
>>> Emacs also has a psychotherapist, programmed in Lisp. I'm not kidding.
>>> It's really relaxing to chat with it every now and then.
>> This is software you expect me to take seriously? And here I'd thought
>> putting that damn paperclip in office productivity software was asking
>> for it. (And was proved right.)
>
> OK, the shrink is a bit of a joke, it's a clone of an early AI program
> that simulates a Rogerian Psychiatrist. But aside from the shrink,
> Emacs nowadays is as functional a word processor as any.
Literally impossible. It might be capable of functioning as a word
processor (WordStar managed, under the same constraints), but to be "as
functional ... as any" would require features that are physically
impossible when your user interface is just a box of text.
WYSIWYG, for one. Arguably overrated, with reference to TeX-like markup
as an alternative, but I think it can be quite useful, and like it or
not, it is a feature that emacs cannot have that, for instance, Word has.
For anything with complex formatting, WYSIWYG is far better than an
edit-compile-view cycle (TeX) or worse, an edit-print-view cycle
(WordStar). The latter consumes paper and toner, the former lets you see
what you're doing as you're doing it, and the middle road lacks both
traits. (Frankly, I would like the best of both worlds: a logical markup
language in a left hand pane and a right hand pane showing a
near-real-time WYSIWYG view, possibly supporting at least a subset of
editing commands. I know of nothing that provides such. Certainly it
would have to be a modern GUI application though.)
> SLIME adds integration to an external Lisp compiler (Emacs Lisp is a
> different dialect of Lisp, and it's basically only useful for
> customizing Emacs).
Leaving aside any quibbles about exactly how useful "customizing emacs"
really is, this especially sounds like it's just begging for trouble.
Lisp programmers using this editor are going to have to work in both
dialects, close together in time; a recipe for frequent mistakes.
(I say have to, because if for some reason you are stuck using emacs,
say because you're being forced to at gunpoint and if you reach for a
real editor you'll be shot, then you sure as heck will want to do what
you can to tame the beast, which will require working with elisp.
Without using elisp, the best you can do is fix the horrid key bindings
to adhere to some semblance of modern standards.)
> Everybody here is completely serious when they say that Emacs
> is just as powerful as NetBeans, or any other modern IDE.
I don't consider boxes of ASCII to be powerful; sorry. See above for
some more features of NetBeans that emacs will lack.
Even if you consider its capabilities powerful, those capabilities are
trapped behind an extremely un-powerful user interface that even makes
it slightly more difficult to use for plain-jane typing in some text and
saving it than Notepad is. To attempt anything really complex through
that interface is a task I shudder to contemplate.
There is a post by someone else in this thread that I also recommend you
read, which goes into a lot of detail about the benefits of graphical
user interfaces over text ones, some of which apply even when the user's
task amounts to text editing of some kind.
Another topic that came up is the visual diff in NetBeans. It's not
possible to emulate this in emacs, vi, or anything else stuck with only
the ASCII palette to paint with, and the same with a lot of other useful
features.
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Hardly ever. Even when the task being done in the application is very
> simple, the user benefits from a modern interface that ...
... doesn't blow up when they click on a .pdf link.
Let's see what else the bumbling troll walks right into.
Kaz Kylheku wrote:
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Hardly ever. Even when the task being done in the application is very
>> simple, the user benefits from a modern interface that ...
>
> ... doesn't blow up when they click on a .pdf link.
True, true. That's why an alternative to Acrobat Reader would be nice. I
haven't seen one for Windows that worked well and nicely antialiased the
text though.
> Let's see what else the bumbling troll walks right into.
This gratuitous personal attack was completely without provocation,
merit, or validity.
Seamus MacRae <··········@live.ca.nospam> writes:
> That's why an alternative to Acrobat Reader would be
> nice. I haven't seen one for Windows that worked well and nicely
> antialiased the text though.
That's not a matter if a Adobe Acrobat Reader app alternative, that's a
matter of OS choice. On my Mac text looks extremely good.
Frank GOENNINGER wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> That's why an alternative to Acrobat Reader would be
>> nice. I haven't seen one for Windows that worked well and nicely
>> antialiased the text though.
>
> That's not a matter if a Adobe Acrobat Reader app alternative, that's a
> matter of OS choice. On my Mac text looks extremely good.
OS has nothing to do with whether the app antialiases or not. And the
difference is the app. If Windows somehow didn't support antialiased
text when viewing pdfs, they'd look as ugly in Acrobat on Windows as
they do in the alternatives.
None of which, to my knowledge, have browser plug-in versions anyway.
On Wed, 20 May 2009 13:56:46 +0200, Frank GOENNINGER wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> That's why an alternative to Acrobat Reader would be nice. I haven't
>> seen one for Windows that worked well and nicely antialiased the text
>> though.
>
> That's not a matter if a Adobe Acrobat Reader app alternative, that's a
> matter of OS choice. On my Mac text looks extremely good.
...and on my Linux systems I have a choice of three PDF viewers:
- the builtin viewer in Firefox 3
- the builtin viewer in Opera 9.64
- xpdf, a standalone PDF viewer.
Look Ma, no Adobe Acrobat!
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
Martin Gregorie wrote:
> On Wed, 20 May 2009 13:56:46 +0200, Frank GOENNINGER wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>> That's why an alternative to Acrobat Reader would be nice. I haven't
>>> seen one for Windows that worked well and nicely antialiased the text
>>> though.
>> [calls me a liar]
> [calls me a liar]
Neither one of you are correct.
Seamus MacRae <··········@live.ca.nospam> writes:
> For anything with complex formatting, WYSIWYG is far better than an
> edit-compile-view cycle (TeX) or worse, an edit-print-view cycle
> (WordStar). The latter consumes paper and toner, the former lets you
> see what you're doing as you're doing it, and the middle road lacks
> both traits. (Frankly, I would like the best of both worlds: a logical
> markup language in a left hand pane and a right hand pane showing a
> near-real-time WYSIWYG view, possibly supporting at least a subset of
> editing commands. I know of nothing that provides such. Certainly it
> would have to be a modern GUI application though.)
We definitely DO NOT WANT wysiwyg. We DO NOT WANT to do anything. We
want the computer to do things like formating documents for us!
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> For anything with complex formatting, WYSIWYG is far better than an
>> edit-compile-view cycle (TeX) or worse, an edit-print-view cycle
>> (WordStar). The latter consumes paper and toner, the former lets you
>> see what you're doing as you're doing it, and the middle road lacks
>> both traits. (Frankly, I would like the best of both worlds: a logical
>> markup language in a left hand pane and a right hand pane showing a
>> near-real-time WYSIWYG view, possibly supporting at least a subset of
>> editing commands. I know of nothing that provides such. Certainly it
>> would have to be a modern GUI application though.)
>
> We definitely DO NOT WANT wysiwyg.
Speak for yourself.
> We DO NOT WANT to do anything.
Speak for yourself.
> We want the computer to do things like formating documents for us!
It sounds like you want the computer to do EVERYTHING for you. But once
the computer can to EVERYTHING, what use will it have for you? What
reason to keep humans around? We're dirty, we're smelly, we shed gunk
into electronics and fill the air with dandruff and sneeze-droplets and
other crap, and we need air full of oxygen that corrodes circuitry. They
would probably be better off without us.
Seamus MacRae wrote:
> (Frankly, I would like the best of both worlds: a logical markup
> language in a left hand pane and a right hand pane showing a
> near-real-time WYSIWYG view, possibly supporting at least a subset of
> editing commands. I know of nothing that provides such. Certainly it
> would have to be a modern GUI application though.)
Interestingly, Emacs can do this:
<http://user.uni-frankfurt.de/~kremers/emacs1.png>
That's a screenshot of a typical Emacs session for me. Notice how LaTeX
commands such as \section, \ref, \textsc or \emph are hidden, with some
font effect on the arguments to approximate the command's effect (e.g. the
section title "Transfer", the italic "all", etc.) Notice also the image,
which is actually produced by some LaTeX code, which can be made visible
and edited by moving the cursor into it:
<http://user.uni-frankfurt.de/~kremers/emacs2.png>
Then, after editing, a few key presses (or mouse clicks, if you prefer) and
the updated image is displayed.
> Leaving aside any quibbles about exactly how useful "customizing emacs"
> really is,
The LaTeX editing features here are provided by an add-on package. So yes,
customising Emacs is extremely useful. Elisp means that anyone who wants to
can add features to Emacs. I also handle my BibTeX databases from within
Emacs, for example.
Note that "customising Emacs" doesn't mean changing background colour and
default window size or stuff like that. Elisp is as powerful as any
so-called "scripting" language (python, perl, etc.) and gives one the
ability to add basically any feature imaginable to Emacs.
So please stop talking about something you obviously no absolutely nothing
about.
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Joost Kremers wrote:
> Seamus MacRae wrote:
>
>> (Frankly, I would like the best of both worlds: a logical markup
>> language in a left hand pane and a right hand pane showing a
>> near-real-time WYSIWYG view, possibly supporting at least a subset of
>> editing commands. I know of nothing that provides such. Certainly it
>> would have to be a modern GUI application though.)
>
> Interestingly, Emacs can do this
No, it cannot. A WYSIWYG view of anything fancier than plain unadorned
pages-full of monospaced Courier is going to necessarily require a
better user interface than what any terminal (emulator) can provide emacs.
> LaTeX commands such as \section, \ref, \textsc or \emph are hidden, with
> some font effect on the arguments to approximate the command's effect
> (e.g. the section title "Transfer", the italic "all", etc.)
What the hell terminal type does italics? Certainly not the ones I've
used (VT100, 200, 320, and a few more obscure ones); those mostly only
deal in normal, inverse video, and sometimes underline.
Besides, what you're describing isn't WYSIWYG, it's some sort of
half-assed thing that gets you the worst of both worlds: the formatting
codes aren't visible but you're not seeing it as it really looks either.
> Notice also the image
ASCII art just doesn't do it for me.
> Then, after editing, a few key presses (or mouse clicks, if you prefer) and
> the updated image is displayed.
Mouse clicks on what? The close button of the xterm window with this
shit in it? I know that's the only place I'd want to click.
>> Leaving aside any quibbles about exactly how useful "customizing emacs"
>> really is,
>
> The LaTeX editing features here are provided by an add-on package. So yes,
> customising Emacs is extremely useful.
You can dress up a donkey as a pink flamingo but it won't win any beauty
contests, nor will it fly.
> Elisp means that anyone who wants to can add features to Emacs.
Within the constraints imposed by the architecture of the script's host.
Severe constraints when it comes to user interface expressiveness and
design.
> I also handle my BibTeX databases from within Emacs, for example.
I'm sure you do. Those are plain old text, though, really, so this is
much more within the realm of what you can do reasonably from inside a
text editor. If you can ever get past the horrible keyboard-driven
interface.
> Note that "customising Emacs" doesn't mean changing background colour and
> default window size or stuff like that.
Of course not, you can only do that sort of customizing with a REAL
application, you know, one that does not predate glasnost and
perestroika by nearly a quarter-century.
> Elisp is as powerful as any so-called "scripting" language (python,
> perl, etc.) and gives one the ability to add basically any feature
> imaginable to Emacs.
I, apparently unlike you, can imagine such hypothetical features as
having an M-x quake mode, or a fly-through of CAD models, or graphing of
implicit functions, none of which can be done in any reasonable manner
using only a grid of letters, numbers, and punctuation, and therefore
none of which can be done in emacs, no matter how powerful elisp is.
> So please stop talking about something you obviously no absolutely nothing
> about.
Everything else was civil (if a bit odd), and then this disappointment:
a gratuitous, unprovoked, ungrammatical insult with delusions of relevance.
Seamus MacRae wrote:
> Joost Kremers wrote:
>> Seamus MacRae wrote:
>>
>>> (Frankly, I would like the best of both worlds: a logical markup
>>> language in a left hand pane and a right hand pane showing a
>>> near-real-time WYSIWYG view, possibly supporting at least a subset of
>>> editing commands. I know of nothing that provides such. Certainly it
>>> would have to be a modern GUI application though.)
>>
>> Interestingly, Emacs can do this
>
> No, it cannot. A WYSIWYG view of anything fancier than plain unadorned
> pages-full of monospaced Courier
have you even bothered to look at the screen shots? you'd have noticed that
a) it's *not* unadorned, b) it's not courier
> is going to necessarily require a
> better user interface than what any terminal (emulator) can provide emacs.
and it's *not* a terminal emulator. emacs has developed into an X
application running inside its own X window (which happens to be called
frame in emacs lingo). it, btw, also runs on windows and os x as a gui
application.
>> LaTeX commands such as \section, \ref, \textsc or \emph are hidden, with
>> some font effect on the arguments to approximate the command's effect
>> (e.g. the section title "Transfer", the italic "all", etc.)
>
> What the hell terminal type does italics?
stop being (deliberately? unintentionally) ignorant. yes, emacs still runs
on a terminal, but it also runs in X, doing all the font tricks one would
expect.
> Besides, what you're describing isn't WYSIWYG, it's some sort of
> half-assed thing that gets you the worst of both worlds: the formatting
> codes aren't visible but you're not seeing it as it really looks either.
oh? before, having both seemed to you like the best of both worlds. now
it's suddently the worst... sure, emacs doesn't give both next to each
other, but the code is there when i need it.
and sure, it's not *exactly* as it will look on paper or pdf. but that only
becomes important in the final stages, not while writing a text. who cares
how a paragraph is formatted when you're still writing it?
>> Notice also the image
>
> ASCII art just doesn't do it for me.
like i said, you obviously haven't actually looked at the screen shots.
that's not ascii art, that's a png image.
>> Then, after editing, a few key presses (or mouse clicks, if you prefer) and
>> the updated image is displayed.
>
> Mouse clicks on what?
on the relevant menu items.
>> I also handle my BibTeX databases from within Emacs, for example.
>
> I'm sure you do. Those are plain old text,
yes, but i don't deal with them as text files.
> I, apparently unlike you, can imagine such hypothetical features as
> having an M-x quake mode, or a fly-through of CAD models,
well, surprisingly, i *was* only thinking about features that would come in
handy for an IDE, such as the list of netbeans features that you claim
emacs cannot do.
> or graphing of implicit functions,
given the graph and tree structures i've seen emacs do in different
packages, i don't see why this would be principally impossible.
> none of which can be done in any reasonable manner
> using only a grid of letters, numbers, and punctuation, and therefore
> none of which can be done in emacs, no matter how powerful elisp is.
if emacs *were* still just a grid of letters, numbers and puncuation, you'd
be right. it's not, though.
i'm not saying that emacs already has the necessary graphics processing
capabilities for a quake mode, but you're free to add them, if you wish.
>> So please stop talking about something you obviously no absolutely nothing
>> about.
>
> Everything else was civil (if a bit odd), and then this disappointment:
> a gratuitous, unprovoked, ungrammatical insult with delusions of relevance.
well, you seem to think that emacs is just a text-mode application, which
it is not. you claim that emacs cannot handle a mouse, which is simply
wrong. you claim that it's a lousy IDE, even though you've never used it to
actually write code. that's what i call "not knowing a thing about it".
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Joost Kremers wrote:
> Seamus MacRae wrote:
>> Joost Kremers wrote:
>>> Seamus MacRae wrote:
>>>
>>>> (Frankly, I would like the best of both worlds: a logical markup
>>>> language in a left hand pane and a right hand pane showing a
>>>> near-real-time WYSIWYG view, possibly supporting at least a subset of
>>>> editing commands. I know of nothing that provides such. Certainly it
>>>> would have to be a modern GUI application though.)
>>> Interestingly, Emacs can do this
>> No, it cannot. A WYSIWYG view of anything fancier than plain unadorned
>> pages-full of monospaced Courier
>
> have you even bothered to look at the screen shots? you'd have noticed that
> a) it's *not* unadorned, b) it's not courier
The ability of the xterm to use a different font, or of the emulated
terminal to display inverse video or similarly, does not suffice to
enable a WYSIWYG word processor to exist within it.
>> is going to necessarily require a
>> better user interface than what any terminal (emulator) can provide emacs.
>
> and it's *not* a terminal emulator.
Actual terminals are even more constraining than their emulators.
[some purely nonsensical statements trimmed]
>>> LaTeX commands such as \section, \ref, \textsc or \emph are hidden, with
>>> some font effect on the arguments to approximate the command's effect
>>> (e.g. the section title "Transfer", the italic "all", etc.)
>> What the hell terminal type does italics?
>
> stop being (deliberately? unintentionally) ignorant. [most of rest of
> post deleted]
I have little interest in continuing this if you will not be civil and
polite.
>> Besides, what you're describing isn't WYSIWYG, it's some sort of
>> half-assed thing that gets you the worst of both worlds: the formatting
>> codes aren't visible but you're not seeing it as it really looks either.
>
> oh? before, having both seemed to you like the best of both worlds. now
> it's suddently the worst...
Having both, yes; you have neither, if, as you have stated, the
formatting codes are (partly) hidden and the "WYSIWYG" is not actually
WYSIWYG.
> sure, emacs doesn't give both next to each other
>
> and sure, it's not *exactly* as it will look on paper
In other words, it's just what I asked for, except for being nothing at
all resembling what I asked for.
>>> Notice also the image
>> ASCII art just doesn't do it for me.
>
> that's not ascii art, that's a png image.
A png image cannot appear inside an xterm. Any screenshot purporting to
display such an occurrence is therefore presumptively a digital fake.
>>> Then, after editing, a few key presses (or mouse clicks, if you prefer) and
>>> the updated image is displayed.
>> Mouse clicks on what?
>
> on the relevant menu items.
What menu items? The terminal emulator's? Those will provide only a few
limited capabilities to terminate the attached process, capture
screenshots or visible text, and possibly (though this won't be useful
running a screen-oriented editor) access a backscroll buffer, with maybe
one or two other minor doodads.
>>> I also handle my BibTeX databases from within Emacs, for example.
>> I'm sure you do. Those are plain old text,
>
> yes
>
>> I, apparently unlike you, can imagine such hypothetical features as
>> having an M-x quake mode, or a fly-through of CAD models,
>
> well, surprisingly, i *was* only thinking about features that would come in
> handy for an IDE, such as the list of netbeans features that you claim
> emacs cannot do.
The visual diff viewer falls within that set, as has already been
explained several times. It cannot be effectively emulated inside of an
xterm or any similar environment.
>> or graphing of implicit functions,
>
> given the graph and tree structures i've seen emacs do in different
> packages, i don't see why this would be principally impossible.
ASCII approximations to function graphs, using for example the
characters \|/-, will not be an acceptable-quality substitute for true
graphics.
>> none of which can be done in any reasonable manner
>> using only a grid of letters, numbers, and punctuation, and therefore
>> none of which can be done in emacs, no matter how powerful elisp is.
>
> if emacs *were* still just a grid of letters, numbers and puncuation, you'd
> be right.
Well, of course it is. It's a text editor. Even Notepad and other GUI
text editors are essentially just grids of letters, numbers, and
punctuation, only with editor-specific menus above them instead of
generic terminal-emulator menus.
> i'm not saying that emacs already has the necessary graphics processing
> capabilities for a quake mode, but you're free to add them, if you wish.
Since it has no graphics processing capabilities worthy of the name, nor
is it capable of acquiring them, this is essentially a vacuous statement.
>>> So please stop talking about something you obviously no absolutely nothing
>>> about.
>> Everything else was civil (if a bit odd), and then this disappointment:
>> a gratuitous, unprovoked, ungrammatical insult with delusions of relevance.
>
> well, you seem to think that emacs is just a text-mode application
Well of course I do. It was written in 1970 for crying out loud! There's
nothing else that it COULD be.
[trimmed another batch of insults]
The uncivil parts of your posts are a waste of my time and yours. Please
don't bother with them again, as I will merely ignore them.
From: I V
Subject: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4a0e8038$1@news.x-privat.org>
On Sat, 16 May 2009 04:17:37 -0400, Seamus MacRae wrote:
>> And yes, you can use your mouse for everything you'd expect in any
>> other windowed program.
>
> Now I'm confused. Which windowed program were we discussing? Not the
> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
I'm not exactly sure when the first windowed version of Emacs was
developed, but GNU Emacs had a windowed version in 1987:
http://www.gnu.org/bulletins/bull2.txt
Emacs has been a windowed program for over 20 years.
I V <·······@gmail.com> writes:
> On Sat, 16 May 2009 04:17:37 -0400, Seamus MacRae wrote:
> >> And yes, you can use your mouse for everything you'd expect in any
> >> other windowed program.
> >
> > Now I'm confused. Which windowed program were we discussing? Not the
> > text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>
> I'm not exactly sure when the first windowed version of Emacs was
> developed, but GNU Emacs had a windowed version in 1987:
>
> http://www.gnu.org/bulletins/bull2.txt
>
> Emacs has been a windowed program for over 20 years.
Actually, it's really closing in on 30 years.
The zmacs variant was a windowed program since sometime around 1980.
This was used in the Lisp machine, which was also one of the first
single-user workstation designs. It was also one of the early uses of
bit-mapped (as opposed to character or vector) displays.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> I V <·······@gmail.com> writes:
>
>> On Sat, 16 May 2009 04:17:37 -0400, Seamus MacRae wrote:
>>>> And yes, you can use your mouse for everything you'd expect in any
>>>> other windowed program.
>>> Now I'm confused. Which windowed program were we discussing? Not the
>>> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>> I'm not exactly sure when the first windowed version of Emacs was
>> developed, but GNU Emacs had a windowed version in 1987:
>>
>> http://www.gnu.org/bulletins/bull2.txt
>>
>> Emacs has been a windowed program for over 20 years.
>
> Actually, it's really closing in on 30 years.
>
> The zmacs variant was a windowed program since sometime around 1980.
> This was used in the Lisp machine, which was also one of the first
> single-user workstation designs. It was also one of the early uses of
> bit-mapped (as opposed to character or vector) displays.
BOR-ing!
--
Lew
Thomas A. Russ wrote:
> I V <·······@gmail.com> writes:
>
>> On Sat, 16 May 2009 04:17:37 -0400, Seamus MacRae wrote:
>>>> And yes, you can use your mouse for everything you'd expect in any
>>>> other windowed program.
>>> Now I'm confused. Which windowed program were we discussing? Not the
>>> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>> I'm not exactly sure when the first windowed version of Emacs was
>> developed, but GNU Emacs had a windowed version in 1987:
>>
>> http://www.gnu.org/bulletins/bull2.txt
>>
>> Emacs has been a windowed program for over 20 years.
>
> Actually, it's really closing in on 30 years.
>
> The zmacs variant was a windowed program since sometime around 1980.
Once more, and with feeling: the ability to divide the text display into
separate side-by-side or vertically-stacked chunks viewing separate
documents is to real windows as the Wright Brothers' first biplane is to
a Boeing 747.
The emacs documentation calls those panes "windows", and we call that
biplane an "aeroplane", but really, they're almost nothing alike, except
that the one does let you see two things at once and the other does fly.
> This was used in the Lisp machine, which was also one of the first
> single-user workstation designs. It was also one of the early uses of
> bit-mapped (as opposed to character or vector) displays.
This is rather ironic, seeing as a bit-mapped display was wasted on
pretty much all of the computer programs that existed in those days, the
best of which were like emacs, with full-screen editing capability at
least, and the majority of which were more like ed or ex or gdb.
Perhaps they ran some experimental new programs on those that actually
used the display to its full potential, but the real revolution that was
yet to come was in having everyday tools (such as text editors) use it.
Hindsight though is always 20/20. Back then they probably thought it was
useful for visualizing function graphs and geometric shapes, and little
else. Photo-sharing, doodling, desktop publishing, DeviantArt, and such
mundanities as using graphics to ease the user's interaction with
multiple concurrent jobs, none could be easily anticipated.
Well, except maybe at Xerox Parc, where they apparently had a primitive
but recognizable GUI and a mouse several decades ago, but their
ahead-of-its-time idea never took off until Apple shamelessly copied
them and loosed the Macintosh upon the world (after the earlier, much
less successful Lisa).
I V wrote:
> On Sat, 16 May 2009 04:17:37 -0400, Seamus MacRae wrote:
>>> And yes, you can use your mouse for everything you'd expect in any
>>> other windowed program.
>> Now I'm confused. Which windowed program were we discussing? Not the
>> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>
> I'm not exactly sure when the first windowed version of Emacs
No, no, no! I want REAL windows, not those split-screen views that the
emacs documentation oh-so-helpfully mislabeles as "windows" and that I
found to be more trouble than they were worth.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> I V wrote:
>>> On Sat, 16 May 2009 04:17:37 -0400, Seamus MacRae wrote:
>>>>> And yes, you can use your mouse for everything you'd expect in any
>>>>> other windowed program.
>>>> Now I'm confused. Which windowed program were we discussing? Not the
>>>> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>>> I'm not exactly sure when the first windowed version of Emacs
>> No, no, no! I want REAL windows, not those split-screen views that the
>> emacs documentation oh-so-helpfully mislabeles as "windows" and that I
>> found to be more trouble than they were worth.
>
> Emacs calls those "frames"
Why would it call them anything? It's stuck in one (the xterm) or none
at all (actual terminal, or console with no X running) and even when
it's in an xterm it doesn't have any way to KNOW it is or interact with
it...
> Is the important thing that you have them, or that they're called by a
> particular name?
The important thing is that I have a real, modern user interface, not
just a box of ASCII. Putting the borders and title-bar of an xterm
around a box of ASCII just makes it a wrapped and beribboned box of
ASCII. Hey, I think maybe I'll give one of those to my mother-in-law for
Christmas next year. It will be amusing if it makes her throw up.
> [You can even have multiple frames on different displays, in different
> countries if you want...]
The ability to run multiple xterms concurrently had occurred to me, yes.
Why would I want to though? Twice as much of a bletcherous thing is
more, rather than less, bletcherous. One xterm at a shell prompt is the
most I'd normally ever desire.
Besides, it's not as if I'd magically get any real-GUI goodness out of
it, like being able to cut in one window and paste in a different one.
The X clipboard and the various emacs instances' clipboards would all
know nothing of one another.
Seamus MacRae <··········@live.ca.nospam> writes:
> Paul Foley (http://public.xdi.org/=pf) wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>> I V wrote:
>>>> On Sat, 16 May 2009 04:17:37 -0400, Seamus MacRae wrote:
>>>>>> And yes, you can use your mouse for everything you'd expect in any
>>>>>> other windowed program.
>>>>> Now I'm confused. Which windowed program were we discussing? Not the
>>>>> text editor, which predates Windows 1.0 by more than a decade. SLIME? I
>>>> I'm not exactly sure when the first windowed version of Emacs
>>> No, no, no! I want REAL windows, not those split-screen views that the
>>> emacs documentation oh-so-helpfully mislabeles as "windows" and that I
>>> found to be more trouble than they were worth.
>>
>> Emacs calls those "frames"
>
> Why would it call them anything? It's stuck in one (the xterm) or none
> at all (actual terminal, or console with no X running) and even when
> it's in an xterm it doesn't have any way to KNOW it is or interact
> with it...
>
>> Is the important thing that you have them, or that they're called by a
>> particular name?
>
> The important thing is that I have a real, modern user interface, not
> just a box of ASCII. Putting the borders and title-bar of an xterm
> around a box of ASCII just makes it a wrapped and beribboned box of
> ASCII. Hey, I think maybe I'll give one of those to my mother-in-law
> for Christmas next year. It will be amusing if it makes her throw up.
>
>> [You can even have multiple frames on different displays, in different
>> countries if you want...]
>
> The ability to run multiple xterms concurrently had occurred to me,
> yes. Why would I want to though? Twice as much of a bletcherous thing
> is more, rather than less, bletcherous. One xterm at a shell prompt is
> the most I'd normally ever desire.
>
> Besides, it's not as if I'd magically get any real-GUI goodness out of
> it, like being able to cut in one window and paste in a different
> one. The X clipboard and the various emacs instances' clipboards would
> all know nothing of one another.
You must be aware that emacs can run in windowed mode under both X-windows and
MS windows (and others I am not familiar with). You seem to be talking
here though about non-windowed (or tty) mode.
In windowed mode you can open any number of frames, each of which is
*not* an xterm around an ascii box, rather it is a real window with a
status bar, menu, etc. You can cut and paste between them and do
anything you would expect.
·······@sagepub.com wrote:
>>> [You can even have multiple frames on different displays, in different
>>> countries if you want...]
>> The ability to run multiple xterms concurrently had occurred to me,
>> yes. Why would I want to though? Twice as much of a bletcherous thing
>> is more, rather than less, bletcherous. One xterm at a shell prompt is
>> the most I'd normally ever desire.
>>
>> Besides, it's not as if I'd magically get any real-GUI goodness out of
>> it, like being able to cut in one window and paste in a different
>> one. The X clipboard and the various emacs instances' clipboards would
>> all know nothing of one another.
> You must be aware that emacs can run in windowed mode under both X-windows and
> MS windows (and others I am not familiar with).
Yes, trivially; any console app can be run "in windowed mode" by
displaying it in a windowed terminal emulator instead of a full-screen
one or a real terminal.
> You seem to be talking here though about non-windowed (or tty) mode.
The mode of all old unix command-line tools, yes.
Seamus MacRae wrote:
> ·······@sagepub.com wrote:
>>>> [You can even have multiple frames on different displays, in different
>>>> countries if you want...]
>>> The ability to run multiple xterms concurrently had occurred to me,
>>> yes. Why would I want to though? Twice as much of a bletcherous thing
>>> is more, rather than less, bletcherous. One xterm at a shell prompt is
>>> the most I'd normally ever desire.
>>>
>>> Besides, it's not as if I'd magically get any real-GUI goodness out of
>>> it, like being able to cut in one window and paste in a different
>>> one. The X clipboard and the various emacs instances' clipboards would
>>> all know nothing of one another.
>> You must be aware that emacs can run in windowed mode under both
>> X-windows and MS windows (and others I am not familiar with).
>
> Yes, trivially; any console app can be run "in windowed mode" by
> displaying it in a windowed terminal emulator instead of a full-screen
> one or a real terminal.
But in this case it is in real windowed mode.
May I suggest that you install Linux and emacs, so you can try it.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> ·······@sagepub.com wrote:
>>>>> [You can even have multiple frames on different displays, in different
>>>>> countries if you want...]
>>>> The ability to run multiple xterms concurrently had occurred to me,
>>>> yes. Why would I want to though? Twice as much of a bletcherous thing
>>>> is more, rather than less, bletcherous. One xterm at a shell prompt is
>>>> the most I'd normally ever desire.
>>>>
>>>> Besides, it's not as if I'd magically get any real-GUI goodness out of
>>>> it, like being able to cut in one window and paste in a different
>>>> one. The X clipboard and the various emacs instances' clipboards would
>>>> all know nothing of one another.
>>> You must be aware that emacs can run in windowed mode under both
>>> X-windows and MS windows (and others I am not familiar with).
>>
>> Yes, trivially; any console app can be run "in windowed mode" by
>> displaying it in a windowed terminal emulator instead of a full-screen
>> one or a real terminal.
>
> But
But nothing. Any console app can be run "in windowed mode" by displaying
it in a windowed terminal emulator instead of a full-screen one or a
real terminal.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Seamus MacRae wrote:
>>> ·······@sagepub.com wrote:
>>>>>> [You can even have multiple frames on different displays, in
>>>>>> different
>>>>>> countries if you want...]
>>>>> The ability to run multiple xterms concurrently had occurred to me,
>>>>> yes. Why would I want to though? Twice as much of a bletcherous thing
>>>>> is more, rather than less, bletcherous. One xterm at a shell prompt is
>>>>> the most I'd normally ever desire.
>>>>>
>>>>> Besides, it's not as if I'd magically get any real-GUI goodness out of
>>>>> it, like being able to cut in one window and paste in a different
>>>>> one. The X clipboard and the various emacs instances' clipboards would
>>>>> all know nothing of one another.
>>>> You must be aware that emacs can run in windowed mode under both
>>>> X-windows and MS windows (and others I am not familiar with).
>>>
>>> Yes, trivially; any console app can be run "in windowed mode" by
>>> displaying it in a windowed terminal emulator instead of a
>>> full-screen one or a real terminal.
>>
>> But
>
> But nothing. Any console app can be run "in windowed mode" by displaying
> it in a windowed terminal emulator instead of a full-screen one or a
> real terminal.
X is a full-blown windowing system. Emacs communicates directly with X,
not via another X application like xterm. Emacs can *also* be run as a
console app, which is useful if you don't have an X server able to
communicate with a remote system which you have accessed with ssh, say,
but the normal case for emacs is to be run as an X application.Even
better: emacs can be a GTK application.
What will it take to get through your mind-blocks?
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Seamus MacRae wrote:
>>>> ·······@sagepub.com wrote:
>>>>>>> [You can even have multiple frames on different displays, in
>>>>>>> different
>>>>>>> countries if you want...]
>>>>>> The ability to run multiple xterms concurrently had occurred to me,
>>>>>> yes. Why would I want to though? Twice as much of a bletcherous thing
>>>>>> is more, rather than less, bletcherous. One xterm at a shell
>>>>>> prompt is
>>>>>> the most I'd normally ever desire.
>>>>>>
>>>>>> Besides, it's not as if I'd magically get any real-GUI goodness
>>>>>> out of
>>>>>> it, like being able to cut in one window and paste in a different
>>>>>> one. The X clipboard and the various emacs instances' clipboards
>>>>>> would
>>>>>> all know nothing of one another.
>>>>> You must be aware that emacs can run in windowed mode under both
>>>>> X-windows and MS windows (and others I am not familiar with).
>>>>
>>>> Yes, trivially; any console app can be run "in windowed mode" by
>>>> displaying it in a windowed terminal emulator instead of a
>>>> full-screen one or a real terminal.
>>>
>>> But
>>
>> But nothing. Any console app can be run "in windowed mode" by
>> displaying it in a windowed terminal emulator instead of a full-screen
>> one or a real terminal.
>
> X is a full-blown windowing system.
A well-known and irrelevant fact.
> Emacs communicates directly with X
Not possible. If it had been designed to do so, then it would follow
that a) it did not predate X, b) it could not be used remotely over a
terminal, and c) it used the X clipboard. However, a) it does predate X,
b) it can be used remotely over a terminal, and c) it has its own
internal clipboard. On the other hand, if it had not been designed to do
so, it could not do so now without being completely rewritten, and the
result of such a rewrite would not be emacs.
> What will it take to get through your mind-blocks?
Politeness is necessary, though not sufficient. Correctness is likewise
necessary, though not sufficient. Or, at the very least, plausibility.
Seamus MacRae wrote:
> Lars Enderin wrote:
>> Emacs communicates directly with X
>
> Not possible. If it had been designed to do so, then it would follow
> that a) it did not predate X, b) it could not be used remotely over a
> terminal, and c) it used the X clipboard. However, a) it does predate X,
> b) it can be used remotely over a terminal, and c) it has its own
> internal clipboard. On the other hand, if it had not been designed to do
> so, it could not do so now without being completely rewritten, and the
> result of such a rewrite would not be emacs.
Everybody but you describes the current (GNU) Emacs. I don't know why
you are fixated on an ancient version. Of course it's completely
rewritten since RMS's first version in 1976, so what?
Emacs is completely integrated in whatever windowing system it runs
under. Its clipboard works fine with other applications.
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Lars Enderin wrote:
>
>>> Emacs communicates directly with X
>>
>> Not possible. If it had been designed to do so, then it would follow
>> that a) it did not predate X, b) it could not be used remotely over a
>> terminal, and c) it used the X clipboard. However, a) it does predate
>> X, b) it can be used remotely over a terminal, and c) it has its own
>> internal clipboard. On the other hand, if it had not been designed to
>> do so, it could not do so now without being completely rewritten, and
>> the result of such a rewrite would not be emacs.
>
> Everybody but you describes the current (GNU) Emacs.
Whereas I, above, described a generic application in an agnostic manner.
"It" could be any software for which it was true that a) it predated X,
b) it had been observed to be used remotely over a terminal, and c) it
had its own internal clipboard, and the above would still hold.
> Of course it's completely rewritten since RMS's first version in 1976,
> so what?
If this is true, then what you are describing is not emacs. (Are you
also forgetting that GOSMACS was the first Unix emacs, and is definitely
not named for RMS?)
Seamus MacRae wrote:
> Lars Enderin wrote:
>> Seamus MacRae wrote:
>>> Lars Enderin wrote:
>>
>>>> Emacs communicates directly with X
>>>
>>> Not possible. If it had been designed to do so, then it would follow
>>> that a) it did not predate X, b) it could not be used remotely over a
>>> terminal, and c) it used the X clipboard. However, a) it does predate
>>> X, b) it can be used remotely over a terminal, and c) it has its own
>>> internal clipboard. On the other hand, if it had not been designed to
>>> do so, it could not do so now without being completely rewritten, and
>>> the result of such a rewrite would not be emacs.
>>
>> Everybody but you describes the current (GNU) Emacs.
>
> Whereas I, above, described a generic application in an agnostic manner.
> "It" could be any software for which it was true that a) it predated X,
> b) it had been observed to be used remotely over a terminal, and c) it
> had its own internal clipboard, and the above would still hold.
Irrelevant. The current emacs is GNU Emacs or XEmacs. The rest is history.
>> Of course it's completely rewritten since RMS's first version in 1976,
>> so what?
>
> If this is true, then what you are describing is not emacs. (Are you
> also forgetting that GOSMACS was the first Unix emacs, and is definitely
> not named for RMS?)
Emacs has been upgraded since the 70's. It's still called emacs.
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Lars Enderin wrote:
>>> Seamus MacRae wrote:
>>>> Lars Enderin wrote:
>>>
>>>>> Emacs communicates directly with X
>>>>
>>>> Not possible. If it had been designed to do so, then it would follow
>>>> that a) it did not predate X, b) it could not be used remotely over
>>>> a terminal, and c) it used the X clipboard. However, a) it does
>>>> predate X, b) it can be used remotely over a terminal, and c) it has
>>>> its own internal clipboard. On the other hand, if it had not been
>>>> designed to do so, it could not do so now without being completely
>>>> rewritten, and the result of such a rewrite would not be emacs.
>>>
>>> Everybody but you describes the current (GNU) Emacs.
>>
>> Whereas I, above, described a generic application in an agnostic
>> manner. "It" could be any software for which it was true that a) it
>> predated X, b) it had been observed to be used remotely over a
>> terminal, and c) it had its own internal clipboard, and the above
>> would still hold.
>
> Irrelevant.
Not irrelevant, because so broadly applicable.
>>> Of course it's completely rewritten since RMS's first version in 1976,
>>> so what?
>>
>> If this is true, then what you are describing is not emacs. (Are you
>> also forgetting that GOSMACS was the first Unix emacs, and is
>> definitely not named for RMS?)
>
> Emacs has been upgraded since the 70's.
You earlier claimed a complete rewrite, and a port to a whole new
platform. Which was it, a mere upgrade or a complete rewrite?
·······@sagepub.com writes:
> Seamus MacRae <··········@live.ca.nospam> writes:
> > [...]
> You must be aware that emacs can run in windowed mode under both X-windows and
> MS windows (and others I am not familiar with). You seem to be talking
> here though about non-windowed (or tty) mode.
>
> In windowed mode you can open any number of frames, each of which is
> *not* an xterm around an ascii box, rather it is a real window with a
> status bar, menu, etc. You can cut and paste between them and do
> anything you would expect.
This has already been pointed out several times in this thread,
there's no point in repeating. You can train a neural network by
repeating, but then you can measure something has been learned (as
soon as the first time). In Seamus' case, no learning occured,
therefore none will ever.
So, just please stop answering his posts.
--
__Pascal Bourguignon__
On May 22, 6:21 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> ·······@sagepub.com writes:
> > Seamus MacRae <··········@live.ca.nospam> writes:
> > > [...]
> > You must be aware that emacs can run in windowed mode under both X-windows and
> > MS windows (and others I am not familiar with). You seem to be talking
> > here though about non-windowed (or tty) mode.
>
> > In windowed mode you can open any number of frames, each of which is
> > *not* an xterm around an ascii box, rather it is a real window with a
> > status bar, menu, etc. You can cut and paste between them and do
> > anything you would expect.
>
> This has already been pointed out several times in this thread,
> there's no point in repeating. You can train a neural network by
> repeating, but then you can measure something has been learned (as
> soon as the first time). In Seamus' case, no learning occured,
> therefore none will ever.
I don't think Seamus reads this group, so this looks like more
namecalling behind one's back. Shame on you!
Seamus MacRae writes:
> Adlai wrote:
> > It highlights source errors, can link in to profiling utilities,
> > has half a zillion different ways to poke and prod your programs
> > to assist debugging -- there is nothing 1983 about SLIME + Emacs,
> > other than maybe the fixed- with font in the menus. And yes, you
> > can use your mouse for everything you'd expect in any other
> > windowed program.
>
> Now I'm confused. Which windowed program were we discussing? Not the
> text editor, which predates Windows 1.0 by more than a decade.
> SLIME? I thought someone said it was a script in the editor's
> internal scripting language.
Emacs Lisp is a full-scale programming language. Most of Emacs is
written in it.
Googling for Emacs and Slime, the first hit I got was this page:
<http://common-lisp.net/project/slime/>. The page is short and to the
point, and it begins with a description and feature highlights.
There is a screenshot of a window that seems to match Adlai's
description, more or less. A link to a long QuickTime movie is dead,
but a link to a shorter demo works, apparently it is in Flash:
<http://www.unixuser.org/~euske/vnc2swf/slime.html> The link to the
manual works. The link to the mailing list works, and development
seems to be active.
(I don't mean this as a flame, and I don't see how this can be
construed as such. If it happens, it happens, and so be it.)
Jussi Piitulainen <········@ling.helsinki.fi> writes:
> Googling for Emacs and Slime, the first hit I got was this page:
> <http://common-lisp.net/project/slime/>. The page is short and to the
> point, and it begins with a description and feature highlights.
>
> There is a screenshot of a window that seems to match Adlai's
> description, more or less. A link to a long QuickTime movie is dead,
http://www.archive.org/download/UsingtheSLIMELispInteractionModeforEmacs/slime.mov
That's *the* Slime movie. Really recommended !
For a really entertaining way of seeing Lisp's power you should take the
few minutes to watch these video:
http://lispcast.blip.tv/posts?view=archive&nsfw=dc
Start with Episode 1 and watch full screen. Watch them! Really. I mean:
WATCH THEM !
Frank
On May 17, 1:17 pm, Frank GOENNINGER <······@googlemail.com> wrote:
> Jussi Piitulainen <········@ling.helsinki.fi> writes:
> > Googling for Emacs and Slime, the first hit I got was this page:
> > <http://common-lisp.net/project/slime/>. The page is short and to the
> > point, and it begins with a description and feature highlights.
>
> > There is a screenshot of a window that seems to match Adlai's
> > description, more or less.
I'm sorry. I need to run to the store to get some Imodium before I
look at any screenshots of ASCII "windows". So if you'll please be
patient ...
Jussi Piitulainen wrote:
> Seamus MacRae writes:
>> Adlai wrote:
>>> It highlights source errors, can link in to profiling utilities,
>>> has half a zillion different ways to poke and prod your programs
>>> to assist debugging -- there is nothing 1983 about SLIME + Emacs,
>>> other than maybe the fixed- with font in the menus. And yes, you
>>> can use your mouse for everything you'd expect in any other
>>> windowed program.
>> Now I'm confused. Which windowed program were we discussing? Not the
>> text editor, which predates Windows 1.0 by more than a decade.
>> SLIME? I thought someone said it was a script in the editor's
>> internal scripting language.
>
> Emacs Lisp is a full-scale programming language. Most of Emacs is
> written in it.
It is still an internal scripting language, however, which means one of
two things are true. Either the editor lets it send arbitrary commands
to the host operating system and use arbitrary APIs of the host
operating system, in which case anything analogous to the "Concept
virus" that afflicted Word users years ago will be devastating, or the
editor does not, in which case it is limited in its expressiveness to
what the editor groks, which would mean a curses (or ncurses, not a lot
of difference) interface in this case.
Which greatly limits the ability of SLIME to present a reasonable user
interface, in turn.
> There is a screenshot of a window that seems to match Adlai's
> description, more or less.
An emacs "window", or an xterm window? (Not that either is likely to
impress me much.)
> The link to the mailing list works, and development
> seems to be active.
That's perhaps the saddest thing I've read today. All those
contributors, laboring on a product that's already trapped in a
technological cul-de-sac. It's like a dinosaur carefully incubating her
eggs while, in the sky, a certain comet looms larger and larger.
> (I don't mean this as a flame, and I don't see how this can be
> construed as such. If it happens, it happens, and so be it.)
This disclaimer strikes me as odd, since your post was clearly not a
flame. This thread has plenty of flames in it, most of them by Lew and a
few by Series Explosion or whatever it was, but your post is nothing
like those.
Seamus MacRae <··········@live.ca.nospam> writes:
> Adlai wrote:
>> I forgot a few notes:
>> [1] from page 191 of On Lisp, by Paul Graham
>> [2] www.gigamonkeys.com
>> [3] http://www.psg.com/~dlamkins/sl/
>> By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It
>> has
>> all the functionality that you've described an IDE should have. The
>> ONE thing it doesn't have is popping out stuff into neat little help
>> bubbles, but that's cosmetic, not a functionality.
>
> Being able to see a nicely organized workspace with visible context
> for displayed informaton, instead of just one page of text at a time
> in one window, is "cosmetic, not functionality"? Pardon me if I
> disagree.
No pardon for the ignorant!
Here is a typical emacs screenshot: http://collison.ie/code/slime-repl-pics.png
It's as graphic an application as any other.
> This is software you expect me to take seriously? And here I'd thought
> putting that damn paperclip in office productivity software was asking
> for it. (And was proved right.)
What difference between a paperclip and a bubble?
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Adlai wrote:
>>> I forgot a few notes:
>>> [1] from page 191 of On Lisp, by Paul Graham
>>> [2] www.gigamonkeys.com
>>> [3] http://www.psg.com/~dlamkins/sl/
>>> By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It
>>> has
>>> all the functionality that you've described an IDE should have. The
>>> ONE thing it doesn't have is popping out stuff into neat little help
>>> bubbles, but that's cosmetic, not a functionality.
>> Being able to see a nicely organized workspace with visible context
>> for displayed informaton, instead of just one page of text at a time
>> in one window, is "cosmetic, not functionality"? Pardon me if I
>> disagree.
>
> No pardon for the ignorant!
Now *this* is a flame.
> Here is a typical emacs screenshot: http://collison.ie/code/slime-repl-pics.png
> It's as graphic an application as any other.
That's a REPL in a Lisp system of some sort, not emacs. Emacs is a
terminal window displaying a rectangular array of letters, numbers, and
punctuation, looking something like (pardon my rusty memory)
lorem ipsum dolor est whatever-the-fuck-the-rest-was blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
--16:24-----------------------------------(Fundamental)-75%--
M-x: doctor
inside the xterm's window borders.
>> This is software you expect me to take seriously? And here I'd thought
>> putting that damn paperclip in office productivity software was asking
>> for it. (And was proved right.)
>
> What difference between a paperclip and a bubble?
Relevance?
We were comparing a talking paperclip and M-x doctor. The former at
least *tried* to help users actually use the application and remember
its key-bindings. M-x doctor just lets you vent your frustration. :)
Perhaps you were thinking of balloon help, which only pops up when users
hover on something they want more information about, or in some other
circumstances (like new mail arriving), at least if it's well designed.
No cutesy animations, no psychoanalysis, just straight up useful
information. I'm too used to having the Javadocs for a method I'm
calling available at a glance to ever go back to some primitive editor
that requires me to switch tasks to a web browser, or even type some
hard-to-remember key combination to view the Javadocs within the editor
and another to close them and return to my source code. NetBeans can be
set up (and my copy has been set up) to show them in a pane in the lower
left part of the screen for whatever I'm doing, and I don't have to do
more than move my eyes to see the first part. I only have to actually do
something with the user interface to see more than the first several
lines, and a lot of times, the summary in the first few lines tells me
whatever I needed to know.
Please don't continue to argue with me about which tool better suits my
workflow. I've used both, and the answer is NetBeans.
Seamus MacRae <··········@live.ca.nospam> writes:
> Pascal J. Bourguignon wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>> Adlai wrote:
>>>> I forgot a few notes:
>>>> [1] from page 191 of On Lisp, by Paul Graham
>>>> [2] www.gigamonkeys.com
>>>> [3] http://www.psg.com/~dlamkins/sl/
>>>> By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It
>>>> has
>>>> all the functionality that you've described an IDE should have. The
>>>> ONE thing it doesn't have is popping out stuff into neat little help
>>>> bubbles, but that's cosmetic, not a functionality.
>>> Being able to see a nicely organized workspace with visible context
>>> for displayed informaton, instead of just one page of text at a time
>>> in one window, is "cosmetic, not functionality"? Pardon me if I
>>> disagree.
>> No pardon for the ignorant!
>
> Now *this* is a flame.
>
>> Here is a typical emacs screenshot: http://collison.ie/code/slime-repl-pics.png
>> It's as graphic an application as any other.
>
> That's a REPL in a Lisp system of some sort, not emacs.
No pardon for the liars, either.
The innoncent bystanders will have noted the typical emacs status bar
at the bottom of the screen-shot.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Pascal J. Bourguignon wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>
>>>> Adlai wrote:
>>>>> I forgot a few notes:
>>>>> [1] from page 191 of On Lisp, by Paul Graham
>>>>> [2] www.gigamonkeys.com
>>>>> [3] http://www.psg.com/~dlamkins/sl/
>>>>> By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It
>>>>> has
>>>>> all the functionality that you've described an IDE should have. The
>>>>> ONE thing it doesn't have is popping out stuff into neat little help
>>>>> bubbles, but that's cosmetic, not a functionality.
>>>> Being able to see a nicely organized workspace with visible context
>>>> for displayed informaton, instead of just one page of text at a time
>>>> in one window, is "cosmetic, not functionality"? Pardon me if I
>>>> disagree.
>>> No pardon for the ignorant!
>> Now *this* is a flame.
>>
>>> Here is a typical emacs screenshot: http://collison.ie/code/slime-repl-pics.png
>>> It's as graphic an application as any other.
>> That's a REPL in a Lisp system of some sort, not emacs.
>
> No pardon for the liars, either.
More flaming, and vicious, too!
There is no point in this nonsense. Let's either debate civilly or move on.
> The innoncent bystanders will have noted the typical emacs status bar
> at the bottom of the screen-shot.
Peeking out from a mostly-covered xterm, or else photoshopped, no doubt.
Adlai wrote:
> I forgot a few notes:
>
> [1] from page 191 of On Lisp, by Paul Graham
> [2] www.gigamonkeys.com
> [3] http://www.psg.com/~dlamkins/sl/
>
>
> By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE.
But can you debug Java code in it?
--
Lew
On 16 maio, 13:40, Lew <·····@lewscanon.com> wrote:
> Adlai wrote:
> > I forgot a few notes:
>
> > [1] from page 191 of On Lisp, by Paul Graham
> > [2]www.gigamonkeys.com
> > [3]http://www.psg.com/~dlamkins/sl/
>
> > By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE.
>
> But can you debug Java code in it?
You bet it can. I don't now how because I don't program in java, but
Emacs has support for many languages, including Java.
>
> --
> Lew
From: Lew
Subject: Using emacs to debug Java programs (Was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <gun4e8$2bh$1@news.albasani.net>
Lew wrote:
>> But can you debug Java code in [emacs]?
gugamilare wrote:
> You bet it can. I don't now how because I don't program in java [sic], but
> Emacs has support for many languages, including Java.
Can anyone point me to any documentation as to how? I've been a big fan of
emacs for a lot of years, and its inability to debug Java has been the only
shortcoming I've encountered with it to date.
I've looked for instructions before, but had no luck. I miss the days when I
could do gcc compiles from emacs and debug via its gdb interface. I gather
from what you're telling me that the emacs gurus have sussed out how to tie
emacs into the JVM, a remarkable achievement indeed. This is great; I can
start using emacs for my Java development once I get this information.
>> --
>> Lew
Please do not quote sigs.
--
Lew
Oops. Teehee - someone quoted this sig.
From: Pascal J. Bourguignon
Subject: Re: Using emacs to debug Java programs
Date:
Message-ID: <87iqk07q60.fsf@galatea.local>
Lew <·····@lewscanon.com> writes:
> I've looked for instructions before, but had no luck. I miss the days
> when I could do gcc compiles from emacs and debug via its gdb
> interface. I gather from what you're telling me that the emacs gurus
> have sussed out how to tie emacs into the JVM, a remarkable
> achievement indeed. This is great; I can start using emacs for my
> Java development once I get this information.
http://jdee.sourceforge.net/
--
__Pascal Bourguignon__
Adlai wrote:
> On May 16, 10:00 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> No normal application developer is going to, or should need to, concern
>> himself with "anaphoric" anything. At least not unless he works in
>> engineering on the starship enterprise, where not a day goes by without
>> metaphasic this, polaric that, and all kinds of fluxes and subspace
>> whosits needing to be dealt with.
>
> Anaphoric macros are extremely useful. There's a hidden anaphor in the
> CL loop macro, which binds the value of IT onto a previously-evaluated
> conditional. In other words, within a loop, you can say something like
>
> (loop
> for x in list-of-things
> when (find x other-list) collect it)
>
> That's all there is to anaphors. This example in the loop macro is the
> only built-in anaphor that I know of in CL, but it's very easy to
> define syntax for them using macros:[1]
>
> (defmacro aif (test-form then-form &optional else-form)
> `(let ((it ,test-form))
> (if it ,then-form ,else-form)))
>
> There you have it -- a macro that uses variable capture to accomplish
> a fairly useful task. Many functions -- and not just in Lisp -- follow
> the convention of returning some useful value if they "succeed", or a
> false value (NIL in Lisp, maybe False in Python or 0 in C++, etc) if
> they "fail". This macro saves a lot of boilerplate in the long run if
> you use functions like that.
It sounds like it's probably got performance, thread-safety, and even
reentrancy problems, big-time. If this creates a local "it" in each
scope, there may be a performance problem with the extra pointer
assignment in loops where it's usually not used but that might be it,
and the compiler might even be smart enough to optimize it away where
it's unused. On the other hand if "it" is a global variable and you try
to use this in anything more complex than some toy project, you're screwed.
>> In what dream world? Here in the real world we also have to worry about
>> code maintainability, code readability to other people, and bug hunting,
>> not to mention slippery requirements and user complaints of every stripe.
>
> Lisp doesn't limit you from dealing with those. Lisp code can be very
> readable -- most often, unreadable Lisp code is due to bad formatting,
> rather than the syntax itself. Yes, some macros are hard for a non-
> Lisper to understand, but 20 minutes with a good tutorial like PCL[2]
> or Successful Lisp[3] is actually enough to understand most Lisp code.
Forgive me if I take that all with a grain of salt.
> Java does have many advantages over other "standard" programming
> languages in use today. I'm not trying to downplay Java in any way. If
> I had to use one of the standard languages, I'd pick Java over most
> other options. However, I (along with a few others here at c.l.l) am
> just trying to point out the strength, flexibility, and, despite your
> preconceptions about a language second only to FORTRAN in its age,
> modernity of Common Lisp.
Modernity ... that's cute, all things considered. The last time I
looked, the language still assumes that not even CGA graphics have been
invented yet. And so do the typical development tools. :)
> Let's both try and keep this a civil discussion.
That would be nice.
On May 16, 11:05 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Adlai wrote:
> > On May 16, 10:00 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> No normal application developer is going to, or should need to, concern
> >> himself with "anaphoric" anything. At least not unless he works in
> >> engineering on the starship enterprise, where not a day goes by without
> >> metaphasic this, polaric that, and all kinds of fluxes and subspace
> >> whosits needing to be dealt with.
>
> > Anaphoric macros are extremely useful. There's a hidden anaphor in the
> > CL loop macro, which binds the value of IT onto a previously-evaluated
> > conditional. In other words, within a loop, you can say something like
>
> > (loop
> > for x in list-of-things
> > when (find x other-list) collect it)
>
> > That's all there is to anaphors. This example in the loop macro is the
> > only built-in anaphor that I know of in CL, but it's very easy to
> > define syntax for them using macros:[1]
>
> > (defmacro aif (test-form then-form &optional else-form)
> > `(let ((it ,test-form))
> > (if it ,then-form ,else-form)))
>
> > There you have it -- a macro that uses variable capture to accomplish
> > a fairly useful task. Many functions -- and not just in Lisp -- follow
> > the convention of returning some useful value if they "succeed", or a
> > false value (NIL in Lisp, maybe False in Python or 0 in C++, etc) if
> > they "fail". This macro saves a lot of boilerplate in the long run if
> > you use functions like that.
>
> It sounds like it's probably got performance, thread-safety, and even
> reentrancy problems, big-time. If this creates a local "it" in each
> scope, there may be a performance problem with the extra pointer
> assignment in loops where it's usually not used but that might be it,
> and the compiler might even be smart enough to optimize it away where
> it's unused. On the other hand if "it" is a global variable and you try
> to use this in anything more complex than some toy project, you're screwed.
Enter lexical scoping. If you look in the example code I presented
from On Lisp, the variable IT is bound within a LET form. This means
that IT has that meaning, within the lexical (read: word/language
dependant) scope of the LET form. It's actually quite similar to the
scope of local variables within a method in Java (IIRC).
Thus, different iterations of the macro within a loop would be blind
to eachother, and although I'm no concurrent programming whiz, I'd be
quite surprised if concurrent scopes collide with eachother -- any
Lisper with threading expertise know about this one?
> >> In what dream world? Here in the real world we also have to worry about
> >> code maintainability, code readability to other people, and bug hunting,
> >> not to mention slippery requirements and user complaints of every stripe.
>
> > Lisp doesn't limit you from dealing with those. Lisp code can be very
> > readable -- most often, unreadable Lisp code is due to bad formatting,
> > rather than the syntax itself. Yes, some macros are hard for a non-
> > Lisper to understand, but 20 minutes with a good tutorial like PCL[2]
> > or Successful Lisp[3] is actually enough to understand most Lisp code.
>
> Forgive me if I take that all with a grain of salt.
Well, ideally, you would actually try it out for yourself -- read
Peter Seibel's chapter on macros, and see for yourself their
transparancy. Macro code is just like any language; after a bit of
familiarity with the syntax, you just have to piece your way through
and you'll be able to figure it out.
Now obviously what I've said will be wrong if you try to understand,
right off the bat, how some complex macro works. However, many macros
are not very complex, and you wouldn't write a macro more complicated
than you could understand, the same way that you wouldn't write a Java
program more complicated than you could understand. You would build up
from simpler exercises, through practical projects, and by the time
you reached the more complicated levels, you would have the experience
to mentally parse them.
> > Java does have many advantages over other "standard" programming
> > languages in use today. I'm not trying to downplay Java in any way. If
> > I had to use one of the standard languages, I'd pick Java over most
> > other options. However, I (along with a few others here at c.l.l) am
> > just trying to point out the strength, flexibility, and, despite your
> > preconceptions about a language second only to FORTRAN in its age,
> > modernity of Common Lisp.
>
> Modernity ... that's cute, all things considered. The last time I
> looked, the language still assumes that not even CGA graphics have been
> invented yet. And so do the typical development tools. :)
Just because something isn't in the ANSI CL standard doesn't mean it's
in use by the CL community. Some of the commercial implementations
have their own graphics libraries, and there are several cross-
platform graphics libraries as well. Just google common lisp graphics
to see a sample of these.
- Adlai
Seamus MacRae wrote:
>> Modernity ... that's cute, all things considered. The last time I
>> looked, the language still assumes that not even CGA graphics have been
>> invented yet. And so do the typical development tools. :)
Adlai wrote:
> Just because something isn't in the ANSI CL standard doesn't mean it's
> in use by the CL community. Some of the commercial implementations
> have their own graphics libraries, and there are several cross-
> platform graphics libraries as well. Just google common lisp graphics
> to see a sample of these.
"Seamus"'s point is especially weak considering he's been a proponent of Java
in this thread, a language which in and of itself doesn't "assume" any
graphics at all, but depends entirely on an API library to provide graphics
features. Sure, that library is included with the developer's kit for the
language, but it's not part of the Java language standard itself.
Seems like "Seamus" is the one being "cute, all things considered".
--
Lew
Lew wrote:
> Seamus MacRae wrote:
>>> Modernity ... that's cute, all things considered. The last time I
>>> looked, the language still assumes that not even CGA graphics have been
>>> invented yet. And so do the typical development tools. :)
>
> Adlai wrote:
>> Just because something isn't in the ANSI CL standard doesn't mean it's
>> in use by the CL community. Some of the commercial implementations
>> have their own graphics libraries, and there are several cross-
>> platform graphics libraries as well. Just google common lisp graphics
>> to see a sample of these.
>
> "Seamus"'s point is especially weak
I beg to differ. And I consider calling me "Seamus" instead of just
Seamus to be rude.
> considering he's been a proponent of Java in this thread, a language
> which in and of itself doesn't "assume" any graphics at all, but
> depends entirely on an API library to provide graphics features.
C, Common Lisp, and Java all do; the difference is that Java includes
graphics features in its *standard* library, unlike the other two. This
makes it much more attractive for developers of desktop applications and
other software requiring graphics than Common Lisp. The only reason C
beats Java there, market share wise, is that the lion's share of the
desktop OS market is Windows, Microsoft provides a Windows-specific C
library for Windows GUI and graphics that is a defacto standard among
Windows-only-application developers, and C is perceived as being faster
than Java and actually does consume less memory than Java (at least for
smaller apps -- a Windows-GUI C "Hello, World" dialog box popper-upper
has a process size measured in KB; a Java one takes 64 megs -- and, more
generally, any garbage collected system works best with at least some
internally-unused but allocated-to-it memory, typically 25-33%).
> Seems like "Seamus" is the one being "cute, all things considered".
I disagree.
Adlai wrote:
> On May 16, 11:05 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> It sounds like it's probably got performance, thread-safety, and even
>> reentrancy problems, big-time. If this creates a local "it" in each
>> scope, there may be a performance problem with the extra pointer
>> assignment in loops where it's usually not used but that might be it,
>> and the compiler might even be smart enough to optimize it away where
>> it's unused. On the other hand if "it" is a global variable and you try
>> to use this in anything more complex than some toy project, you're screwed.
>
> Enter lexical scoping. If you look in the example code I presented
> from On Lisp, the variable IT is bound within a LET form. This means
> that IT has that meaning, within the lexical (read: word/language
> dependant) scope of the LET form. It's actually quite similar to the
> scope of local variables within a method in Java (IIRC).
Let's see, that makes one whole paragraph of 59 words to say "it's a
local variable".
That leaves the performance concern.
> Thus, different iterations of the macro within a loop would be blind
> to eachother, and although I'm no concurrent programming whiz, I'd be
> quite surprised if concurrent scopes collide with eachother -- any
> Lisper with threading expertise know about this one?
I should certainly hope that local variables in different threads don't
collide. My remarks about thread-safety were relative to the alternative
of it being a global variable.
>> Modernity ... that's cute, all things considered. The last time I
>> looked, the language still assumes that not even CGA graphics have been
>> invented yet. And so do the typical development tools. :)
>
> Just because something isn't in the ANSI CL standard doesn't mean it's
> in use by the CL community. Some of the commercial implementations
> have their own graphics libraries, and there are several cross-
> platform graphics libraries as well. Just google common lisp graphics
> to see a sample of these.
The same state of affairs as obtains with C. I have several problems
with that state of affairs:
1. So far as I know, ANSI standards are not freely available -- a
frankly ludicrous state of affairs; all standards, especially ones
ratified by a national institute of any kind, should be public
knowledge and therefore public domain. The irony is all the bigger
when you note that the JLS is freely available (though not, so far
as I know, public domain) even though Java is the brainchild of,
and the standard is maintained by, a private, profit-motivated
business! This seems backward to what you'd expect, but maybe the
profit motive of Sun leads to their doing the smart thing and making
freely available what is cheap to provide, so as to grow their user
base and drive sales of what they can make *real* money on.
2. The lack of an official graphics library, combined with presence of
many third-party libraries of varying degrees of portability and
compatibility, makes using graphics difficult in portable code, and
graphics-using code from different sources prone to not be combinable
(at least, not easily).
3. Some of those libraries being proprietary adds a whole new headache
dimension to the code-interoperability equation, this time legal and
licensing crap and the inevitable associated red tape and monetary
costs.
Adlai wrote:
> just trying to point out the strength, flexibility, and, despite your
> preconceptions about a language second only to FORTRAN in its age,
> modernity of Common Lisp.
LISP was "originally specified in 1958". [1] ALGOL 58 was specified in 1958.
[2] It may be that LISP is third, not second, in age among third-generation
languages.
Common Lisp didn't appear until 1984. [3] Claiming that it's "second only to
FORTRAN in its age" is disingenuous.
Lisp today resembles LISP of 1958 about as the C-ish languages and Java of
today resemble ALGOL of 1958 and as Fortran today resembles the FORTRAN of
1957. The modernity to which you refer is the result of evolution and
significant changes to the language.
[1] <http://en.wikipedia.org/wiki/Lisp_programming_language>
[2] <http://en.wikipedia.org/wiki/ALGOL_58>
[3] <http://en.wikipedia.org/wiki/Lisp_programming_language#History>
--
Lew
Lew <·····@lewscanon.com> writes:
> Adlai wrote:
>> just trying to point out the strength, flexibility, and, despite your
>> preconceptions about a language second only to FORTRAN in its age,
>> modernity of Common Lisp.
>
> LISP was "originally specified in 1958". [1] ALGOL 58 was specified in
> 1958. [2] It may be that LISP is third, not second, in age among
> third-generation languages.
>
> Common Lisp didn't appear until 1984. [3] Claiming that it's "second
> only to FORTRAN in its age" is disingenuous.
Not if it has been designed with ascendent compatibility and it's
still able to run programs that ran on LISP.
http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html
Works on LISP started in 1958, but the first paper "specifying" it was
AFAIK AIM-8, dated March 1959.
> Lisp today resembles LISP of 1958 about as the C-ish languages and
> Java of today resemble ALGOL of 1958 and as Fortran today resembles
> the FORTRAN of 1957.
No. You can basically run the programs written in AIM-8 LISP in
Common Lisp. You need very little "glue".
The semantics are different in details, but a "normal" lisp program,
ie. a program that doesn't mess with implementation details will
mostly run the same in Common Lisp as in the first LISPs.
After all, you cannot have it both way, complain about CAR, CDR, CONS,
COND and LAMBDA, and imagine that programs using these old operators
don't work anymore.
> The modernity to which you refer is the result
> of evolution and significant changes to the language.
>
> [1] <http://en.wikipedia.org/wiki/Lisp_programming_language>
> [2] <http://en.wikipedia.org/wiki/ALGOL_58>
> [3] <http://en.wikipedia.org/wiki/Lisp_programming_language#History>
There are indeed some significant changes in the internal semantics,
eg. the introduction of lexical closures.
But otherwise Lisp grew mostly by adding layers and staying compatible
with the previous iterations. Common Lisp in particular was designed
to be compatible as much as possible with all the lisps that existed
at that time.
For example, one significant late addition, the CLOS, was implemented
at first as a library implemented in CL, and strongly inspired from
the various older object systems.
This is an important characteristic of Lisp, because it means that
Lisp programmers (not Lisp designers) may augment and morph the
language themselves. If a new programming paradigm appears it can be
implemented as a library by anybody and once a concensus appears, it
may be standardized (but we don't lose much time in standarizing
anyways, because it's enough to have this Common Lisp core
standardized, all the rest being add-ons).
Which doesn't prevent implementers to modify their implementations to
take into account these new features that are implemented as libraries
at first, if they can justify the cost by increased performance.
Nowadays, CLOS taken into account by the compiler and produce efficient
code.
--
__Pascal Bourguignon__
On 16 May, 08:00, Seamus MacRae <··········@live.ca.nospam> wrote:
> Adlai wrote:
>
> > Variable capture is a useful tool sometimes, for example in anaphoric
> > macros.
>
> No normal application developer is going to, or should need to, concern
> himself with "anaphoric" anything. At least not unless he works in
> engineering on the starship enterprise, where not a day goes by without
> metaphasic this, polaric that, and all kinds of fluxes and subspace
> whosits needing to be dealt with.
"Mr. Spock is a Lisp hacker". Yes , I like this.
> Including such doozies as "this statement is false"?
An interesting thing to ponder.
> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
> to the reformulation of half of mathematics to avoid inconsistencies
> like that.
Nahhh , certainly not half of mathematics , just some techical
details in set theory.
--
Who's your mama?
Seamus MacRae wrote:
>> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
>> to the reformulation of half of mathematics to avoid inconsistencies
>> like that.
"Seamus" has his facts wrong.
It didn't drive Georg Cantor mad, and there is no such repute. He was
depressed by the hostility of certain critics and likely suffered from bipolar
disorder; it was the seemingly paradoxical nature of his own theories that
engendered the harsh criticisms from some of his contemporaries.
<http://en.wikipedia.org/wiki/Georg_cantor>
Cantor himself knew that the paradoxes of set theory, including the one for
which he is the eponym, are "not actually contradictory but merely indicative
of a mistaken intuition".
<http://en.wikipedia.org/wiki/Cantor's_paradox>
The "reformation" of mathematics didn't in any way avoid "inconsistencies like
that"; it formalized the statements and the conditions under which they could
or could not be (dis)proven. That reformation was itself in large part
furthered by Cantor's own work.
Spiros Bousbouras wrote:
> Nahhh , certainly not half of mathematics , just some techical
> details in set theory.
"Seamus" needs to research his facts.
--
Lew
Lew wrote:
> Seamus MacRae wrote:
>>> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
>>> to the reformulation of half of mathematics to avoid inconsistencies
>>> like that.
>
> "Seamus" has his facts wrong.
I see no call for this rudeness. Behave yourself or you'll wind up mired
in my kill filter like a fly caught in a pitcher plant.
> It didn't drive Georg Cantor mad, and there is no such repute.
Lies.
And it did not take me long to find a citation to support what I wrote.
http://mathforum.org/library/drmath/view/52393.html
"It's worth realizing that the rigorous mathematical definitions of
things like "the real numbers between 0 and 1" weren't well-developed
until roughly 1900, and so it was very hard to also talk about things
like "this infinite set is bigger than that one" until about that same
time. (As a side note, it may be for the best that they're hard to
identify; Georg Cantor, who's responsible for much of the formal set
theory that underlies these questions, went mad late in life and died in
an asylum, as have some other people who have looked at them!)"
> The "reformation" of mathematics didn't in any way avoid
> "inconsistencies like that";
Sure it did. They replaced a definition of set that allowed for any "x,
such that y" condition to define a set with a constructive definition
that starts with an empty set and works its way upwards, providing only
certain ways to build sets from existing sets.
This is well known, at least among those who have taken the optional
bits of high school math.
Bertrand Russell was the one whose "this statement is false" style
paradox kick-started things, though. Cantor worked later on trying to
fix things to avoid such paradoxes, and some more obscure ones (allowing
a "set of all sets" required a certain transfinite number be unequal to
itself, for instance).
> Spiros Bousbouras wrote:
>> Nahhh , certainly not half of mathematics , just some techical
>> details in set theory.
>
> "Seamus" needs to research his facts.
I have. On the other hand, you need to take some lessons in politeness!
[ Crossposting to sci.math and setting follow-ups for sci.math ]
On 20 May, 07:28, Seamus MacRae <··········@live.ca.nospam> wrote:
> Lew wrote:
> >SeamusMacRae wrote:
> >>> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
> >>> to the reformulation of half of mathematics to avoid inconsistencies
> >>> like that.
>
> > "Seamus" has his facts wrong.
>
> I see no call for this rudeness. Behave yourself or you'll wind up mired
> in my kill filter like a fly caught in a pitcher plant.
>
> > It didn't drive Georg Cantor mad, and there is no such repute.
>
> Lies.
>
> And it did not take me long to find a citation to support what I wrote.
>
> http://mathforum.org/library/drmath/view/52393.html
>
> "It's worth realizing that the rigorous mathematical definitions of
> things like "the real numbers between 0 and 1" weren't well-developed
> until roughly 1900, and so it was very hard to also talk about things
> like "this infinite set is bigger than that one" until about that same
> time. (As a side note, it may be for the best that they're hard to
> identify; Georg Cantor, who's responsible for much of the formal set
> theory that underlies these questions, went mad late in life and died in
> an asylum, as have some other people who have looked at them!)"
Your quote in no way supports your claim that pondering
self-referentiality drove Cantor mad.
[...]
--
Who's your mama?
Spiros Bousbouras wrote:
> [ Crossposting to sci.math and setting follow-ups for sci.math ]
>
> On 20 May, 07:28, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Lew wrote:
>>> SeamusMacRae wrote:
>>>>> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
>>>>> to the reformulation of half of mathematics to avoid inconsistencies
>>>>> like that.
>>> "Seamus" has his facts wrong.
>> I see no call for this rudeness. Behave yourself or you'll wind up mired
>> in my kill filter like a fly caught in a pitcher plant.
>>
>>> It didn't drive Georg Cantor mad, and there is no such repute.
>> Lies.
>>
>> And it did not take me long to find a citation to support what I wrote.
>>
>> http://mathforum.org/library/drmath/view/52393.html
>>
>> "It's worth realizing that the rigorous mathematical definitions of
>> things like "the real numbers between 0 and 1" weren't well-developed
>> until roughly 1900, and so it was very hard to also talk about things
>> like "this infinite set is bigger than that one" until about that same
>> time. (As a side note, it may be for the best that they're hard to
>> identify; Georg Cantor, who's responsible for much of the formal set
>> theory that underlies these questions, went mad late in life and died in
>> an asylum, as have some other people who have looked at them!)"
>
> Your quote in no way supports your claim that pondering
> self-referentiality drove Cantor mad.
I made no such claim. I said "Unbounded self-referentiality *reputedly*
drove Georg Cantor mad" (emphasis added). I have now substantiated the
claim that it *reputedly* drove him mad. Whether that reputation was
deserved or not is an entirely separate matter.
Spiros Bousbouras wrote:
> On 16 May, 08:00, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Adlai wrote:
>>
>>> Variable capture is a useful tool sometimes, for example in anaphoric
>>> macros.
>> No normal application developer is going to, or should need to, concern
>> himself with "anaphoric" anything. At least not unless he works in
>> engineering on the starship enterprise, where not a day goes by without
>> metaphasic this, polaric that, and all kinds of fluxes and subspace
>> whosits needing to be dealt with.
>
> "Mr. Spock is a Lisp hacker". Yes , I like this.
Mr. Spock does not work in engineering. He works on the bridge.
>> Including such doozies as "this statement is false"?
>
> An interesting thing to ponder.
Ponder it too much and suffer Georg Cantor's fate you will.
>> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
>> to the reformulation of half of mathematics to avoid inconsistencies
>> like that.
>
> Nahhh , certainly not half of mathematics , just some techical
> details in set theory.
They basically rebuilt the entire foundation. That ripples into
everything. A lot of other theorems had to be checked for assuming or
relying on something called the "axiom of choice", for instance. Some of
them could still be proven without it. Not others.
[ Crossposting to sci.math and setting follow-ups for sci.math ]
On 20 May, 07:21, Seamus MacRae <··········@live.ca.nospam> wrote:
> Spiros Bousbouras wrote:
> > On 16 May, 08:00,SeamusMacRae <··········@live.ca.nospam> wrote:
>
> >> Including such doozies as "this statement is false"?
>
> > An interesting thing to ponder.
>
> Ponder it too much and suffer Georg Cantor's fate you will.
I doubt it.
> >> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
> >> to the reformulation of half of mathematics to avoid inconsistencies
> >> like that.
>
> > Nahhh , certainly not half of mathematics , just some techical
> > details in set theory.
>
> They basically rebuilt the entire foundation.
No, it only affected Frege's effort for a foundation. Others
took into account Russell's paradox when writing their attempts
at a foundation but they didn't have to rebuild anything. And of
course foundations is only a small part of mathematics so your
claim about "half of mathematics" is completely false, it's not
even half of foundations.
> That ripples into everything.
It didn't affect already established mathematics and there was
a lot of that.
> A lot of other theorems had to be checked for assuming or
> relying on something called the "axiom of choice", for instance. Some of
> them could still be proven without it. Not others.
First, axiom of choice has nothing to do with self-
referentiality. Second, the first theorem to make use of the
axiom of choice was Zermelo's well-ordering principle, so no
existing theorems had to be checked for reliance on the axiom of
choice.
--
Who's your mama?
Spiros Bousbouras wrote:
> On 20 May, 07:21, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Spiros Bousbouras wrote:
>>> On 16 May, 08:00,SeamusMacRae <··········@live.ca.nospam> wrote:
>>>> Including such doozies as "this statement is false"?
>>> An interesting thing to ponder.
>> Ponder it too much and suffer Georg Cantor's fate you will.
>
> I doubt it.
Beware. Fear, anger, aggression -- the Dark Side are they, and you have
shown signs of two of the three frequently over the last few days.
>>>> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
>>>> to the reformulation of half of mathematics to avoid inconsistencies
>>>> like that.
>>> Nahhh , certainly not half of mathematics , just some techical
>>> details in set theory.
>> They basically rebuilt the entire foundation.
>
> No
They basically rebuilt the foundation.
> And of course foundations is only a small part of mathematics
When a foundation is changed, everything constructed above it is
potentially affected, and at least needs some checking.
> [calls me a liar]
I weary of your frequent ad hominem arguments. Please confine your
statements to ones about the actual subject matter under debate and
leave your personal opinion of your opponent out of it.
>> That ripples into everything.
>
> It didn't
It always does.
>> A lot of other theorems had to be checked for assuming or
>> relying on something called the "axiom of choice", for instance. Some of
>> them could still be proven without it. Not others.
>
> First, axiom of choice has nothing to do with self-
> referentiality.
It does have something to do with the reformulation of set theory. When
anything described by "x such that y" was a set, statements dependent on
the axiom of choice were true. Now their dependency on the axiom of
choice, which is independent from and not one of the axioms of ZF set
theory, is a matter of interest.
Yes -- that's right. I know quite a lot more about this than you
probably thought I did when you decided to try attacking me. Next time,
think twice before picking a fight online, you never know who will turn
out to be the equivalent of the Hurricane that you thought would be a
featherweight wimp.
Some other idiot tossing off elsewhere on the net recently was similarly
shocked when I turned out to actually know a thing or two about nuclear
physics.
> Second, the first theorem to make use of the
> axiom of choice was Zermelo's well-ordering principle, so no
> existing theorems had to be checked for reliance on the axiom of
> choice.
It was the first theorem to do so because before that people blithely
assumed that you could always do that sort of thing and the sets in
question would have all the expected elements in them. Then the ZF
axioms replaced "anything, more or less, goes" and this turned out not
to be a theorem of those axioms or even provable (or disprovable!) from
them. Then you had to explicitly state it as an extra axiom or
assumption. So then people started to call it "the axiom of choice" and
make use of it.
Now I suggest that you drop it. There is nothing you can gain by
continuing to flame me, nor by attempting to ignite new flamewars in
formerly uninvolved newsgroups.
Spiros Bousbouras wrote:
> [ Crossposting to sci.math and setting follow-ups for sci.math ]
Back again in an attempt to be nice to sci.math !
> On 20 May, 07:21, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Spiros Bousbouras wrote:
>>> On 16 May, 08:00,SeamusMacRae <··········@live.ca.nospam> wrote:
>>>> Including such doozies as "this statement is false"?
>>> An interesting thing to ponder.
>> Ponder it too much and suffer Georg Cantor's fate you will.
>
> I doubt it.
>
>>>> Unbounded self-referentiality reputedly drove Georg Cantor mad and led
>>>> to the reformulation of half of mathematics to avoid inconsistencies
>>>> like that.
>>> Nahhh , certainly not half of mathematics , just some techical
>>> details in set theory.
>> They basically rebuilt the entire foundation.
>
> No, it only affected Frege's effort for a foundation. Others
> took into account Russell's paradox when writing their attempts
> at a foundation but they didn't have to rebuild anything. And of
> course foundations is only a small part of mathematics so your
> claim about "half of mathematics" is completely false, it's not
> even half of foundations.
>
>> That ripples into everything.
>
> It didn't affect already established mathematics and there was
> a lot of that.
>
>> A lot of other theorems had to be checked for assuming or
>> relying on something called the "axiom of choice", for instance. Some of
>> them could still be proven without it. Not others.
>
> First, axiom of choice has nothing to do with self-
> referentiality. Second, the first theorem to make use of the
> axiom of choice was Zermelo's well-ordering principle, so no
> existing theorems had to be checked for reliance on the axiom of
> choice.
He does not know anything about LISP and he does not know anything
about math.
And worse: he is not interested in learning.
Nothing wrong in trying to explain stuff - just realize that the
impact is most likely zero.
Arne
Arne Vajh�j wrote:
> Back again in an attempt to be nice to sci.math !
I shall be curious to see if your attempt succeeds.
>>> A lot of other theorems had to be checked for assuming or
>>> relying on something called the "axiom of choice", for instance. Some of
>>> them could still be proven without it. Not others.
>>
>> First, axiom of choice has nothing to do with self-
>> referentiality. Second, the first theorem to make use of the
>> axiom of choice was Zermelo's well-ordering principle, so no
>> existing theorems had to be checked for reliance on the axiom of
>> choice.
>
> He does not know anything about LISP and he does not know anything
> about math.
Your attempt failed. It was neither nice nor in sci.math.
Furthermore, your two assertions, above, are incorrect. As I have
demonstrated I know some things about each of those subjects that you
apparently were surprised I knew.
> And worse: he is not interested in learning.
This, also, is incorrect. What I am not interested in is what you, or
anyone else with a similar tendency towards excessive and unwarranted
rudeness, has to say on either subject, particularly when what is said
frequently contradicts, reason, expert testimony, recorded history, or
even the evidence of my own eyes.
> Nothing wrong in trying to explain stuff - just realize that the
> impact is most likely zero.
Explaining stuff in a rude, condescending, and insulting manner is
unlikely to get results, yes. People tend to tune out messages that
personally attack or insult them, since accepting the content of such a
message would mean accepting a negative claim about themselves.
Furthermore, explaining stuff in a manner that contradicts reason or
evidence will not generally net you any new believers. Save that for
congregations among the faithful, not for proselytizing.
On 16 maio, 04:00, Seamus MacRae <··········@live.ca.nospam> wrote:
> Adlai wrote:
> > On May 16, 7:46 am, Series Expansion <·······@gmail.com> wrote:
>
> [Some attributions are missing. Sorry.]
>
> >>> But that has nothing to do with dynamic typing...(Aside from the fact
> >>> that it is very hard (most likely impossible) to do this sort of stuff
> >>> in a statically typed language).
> >> Do what sort of stuff? Accidentally wind up with a Float in a pack of
> >> Strings? Why would you want to? :)
>
> > Do things like have a pack of THINGS, rather than a pack of strings.
>
> You can do that in Java. List<Object>, anyone?
>
> > Paul Graham repeats often, for good reason, that one of Lisp's great
> > strengths is its flexibility. You can have a heterogenous list and
> > Lisp won't blink.
>
> Series mentioned some Java myths being perpetuated in this thread: Java
> is slow, Java lacks reflection, Java isn't Turing complete. Well, this
> seems to be another one: Java doesn't have heterogeneous lists.
>
> Heck, prior to version 5 it didn't have NONheterogeneous lists.
>
> Sheesh!
Are you stupid or what? He didn't even mention the word Java. He is
saying what neat features Lisp has. This discussion is about LISP.
This discussion is NOT about Java's lack of something.
gugamilare wrote:
> On 16 maio, 04:00, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Adlai wrote:
>>> On May 16, 7:46 am, Series Expansion <·······@gmail.com> wrote:
>> [Some attributions are missing. Sorry.]
>>
>>>>> But that has nothing to do with dynamic typing...(Aside from the fact
>>>>> that it is very hard (most likely impossible) to do this sort of stuff
>>>>> in a statically typed language).
>>>> Do what sort of stuff? Accidentally wind up with a Float in a pack of
>>>> Strings? Why would you want to? :)
>>> Do things like have a pack of THINGS, rather than a pack of strings.
>> You can do that in Java. List<Object>, anyone?
>>
>>> Paul Graham repeats often, for good reason, that one of Lisp's great
>>> strengths is its flexibility. You can have a heterogenous list and
>>> Lisp won't blink.
>> Series mentioned some Java myths being perpetuated in this thread: Java
>> is slow, Java lacks reflection, Java isn't Turing complete. Well, this
>> seems to be another one: Java doesn't have heterogeneous lists.
>>
>> Heck, prior to version 5 it didn't have NONheterogeneous lists.
>>
>> Sheesh!
>
> Are you stupid or what?
Or what.
> He didn't even mention the word Java. He is saying what neat features
> Lisp has.
He was implying that they were "features Lisp has and Java lacks". I'm
pointing out that not only were heterogeneous lists in both from the
outset, but that only Java (and only recent Java) has NONheterogeneous
lists.
The original context of Adlai's remarks was:
>>> But that has nothing to do with dynamic typing...(Aside from the fact
>>> that it is very hard (most likely impossible) to do this sort of stuff
>>> in a statically typed language).
>>
>> Do what sort of stuff? Accidentally wind up with a Float in a pack of
>> Strings? Why would you want to? :)
>
> Do things like have a pack of THINGS, rather than a pack of strings.
> Paul Graham repeats often, for good reason, that one of Lisp's great
> strengths is its flexibility. You can have a heterogenous list and
> Lisp won't blink. You can have a function that returns some data, or
> NIL if the data is unavailable. You can bind the result of that
> function to a variable without worrying about types.
Even though the word "Java" itself is indeed not mentioned, "wind up
with a Float in a pack of Strings", given the general context of this
whole discussion, clearly refers to Java.
> This discussion is about LISP.
This discussion is about both. The above quotation, and the Newsgroups:
line, furnish ample evidence that it's about both.
Seamus MacRae <··········@live.ca.nospam> writes:
> Adlai wrote:
> > You can have a function that returns some data, or
> > NIL if the data is unavailable.
>
> Java can do this (return an object or null), and java.util.Map.get()
> does it and is in the standard library.
Um, how does this work if you want the Java method to return a literal
such as int or double? I guess you are then forced to wrap the return
type in the corresponding Integer or Double, so that you have a safe
null value you can return?
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Adlai wrote:
>>> You can have a function that returns some data, or
>>> NIL if the data is unavailable.
>> Java can do this (return an object or null), and java.util.Map.get()
>> does it and is in the standard library.
>
> Um, how does this work if you want the Java method to return a literal
> such as int or double? I guess you are then forced to wrap the return
> type in the corresponding Integer or Double, so that you have a safe
> null value you can return?
Yep.
Arne
From: I V
Subject: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4a120b62@news.x-privat.org>
On Mon, 18 May 2009 21:10:09 -0400, Arne Vajhøj wrote:
>> Um, how does this work if you want the Java method to return a literal
>> such as int or double? I guess you are then forced to wrap the return
>> type in the corresponding Integer or Double, so that you have a safe
>> null value you can return?
>
> Yep.
Surprisingly (to me, anyway), the compiler doesn't object, or even warn,
if one then assigns this (possibly null) Integer to a (certainly not
null) int, leading to the not-entirely-obvious possibility of a
NullPointerException at runtime.
I've only recently started using Java again after quite a while, and so
this autoboxing mularky is new to me. Autounboxing looks to me like a
mistake; an operation that could fail at runtime ought to require an
explicit cast or method call.
I V wrote:
> On Mon, 18 May 2009 21:10:09 -0400, Arne Vajhøj wrote:
>>> Um, how does this work if you want the Java method to return a literal
>>> such as int or double? I guess you are then forced to wrap the return
>>> type in the corresponding Integer or Double, so that you have a safe
>>> null value you can return?
>> Yep.
>
> Surprisingly (to me, anyway), the compiler doesn't object, or even warn,
> if one then assigns this (possibly null) Integer to a (certainly not
> null) int, leading to the not-entirely-obvious possibility of a
> NullPointerException at runtime.
>
> I've only recently started using Java again after quite a while, and so
> this autoboxing mularky is new to me. Autounboxing looks to me like a
> mistake; an operation that could fail at runtime ought to require an
> explicit cast or method call.
The "we want to type less" mob won that fight.
Arne
(F/U set to clj.programmer)
Arne Vajhøj wrote:
> I V wrote:
>> On Mon, 18 May 2009 21:10:09 -0400, Arne Vajhøj wrote:
>>>> Um, how does this work if you want the Java method to return a literal
>>>> such as int or double? I guess you are then forced to wrap the return
>>>> type in the corresponding Integer or Double, so that you have a safe
>>>> null value you can return?
>>> Yep.
>>
>> Surprisingly (to me, anyway), the compiler doesn't object, or even
>> warn, if one then assigns this (possibly null) Integer to a (certainly
>> not null) int, leading to the not-entirely-obvious possibility of a
>> NullPointerException at runtime.
>>
>> I've only recently started using Java again after quite a while, and
>> so this autoboxing mularky is new to me. Autounboxing looks to me like
>> a mistake; an operation that could fail at runtime ought to require an
>> explicit cast or method call.
>
> The "we want to type less" mob won that fight.
Fortunately, the "we want code that's reliable" elite still have the option to
write explicit unboxing or to use the wrapper class utterly.
It is foolishness in Java to mix primitives and objects, such as int and
Integer, without care for the side effects of the mixture. Generally, it is
foolishness to use object references at all in Java without being aware that
dereferencing a 'null' value is not wise. It's not like anyone forces you to
use auto(un)boxing, or that the semantics of 'null' are poorly documented.
--
Lew
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Adlai wrote:
>>> You can have a function that returns some data, or
>>> NIL if the data is unavailable.
>> Java can do this (return an object or null), and java.util.Map.get()
>> does it and is in the standard library.
>
> Um, how does this work if you want the Java method to return a literal
> such as int or double? I guess you are then forced to wrap the return
> type in the corresponding Integer or Double, so that you have a safe
> null value you can return?
Not since version 5.
But this is rarely done. The most usual reason to wrap primitives is to
put them in collections, not to have "a number or null" types. Null is
usually an unwanted complication and we'd rather have "a number or throw
an exception". One exception is with a map of numbers; map lookup
failure is common enough that using a sentinel value is generally
preferred to using try-catch.
Seamus MacRae wrote:
> Thomas A. Russ wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>> Adlai wrote:
>>>> You can have a function that returns some data, or
>>>> NIL if the data is unavailable.
>>> Java can do this (return an object or null), and java.util.Map.get()
>>> does it and is in the standard library.
>>
>> Um, how does this work if you want the Java method to return a literal
>> such as int or double? I guess you are then forced to wrap the return
>> type in the corresponding Integer or Double, so that you have a safe
>> null value you can return?
>
> Not since version 5.
Also in version 5 and 6.
null is not a valid value for int or double - it requires
Integer or Double.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Thomas A. Russ wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> Adlai wrote:
>>>>> You can have a function that returns some data, or
>>>>> NIL if the data is unavailable.
>>>> Java can do this (return an object or null), and java.util.Map.get()
>>>> does it and is in the standard library.
>>>
>>> Um, how does this work if you want the Java method to return a literal
>>> such as int or double? I guess you are then forced to wrap the return
>>> type in the corresponding Integer or Double, so that you have a safe
>>> null value you can return?
>>
>> Not since version 5.
>
> Also in version 5 and 6.
>
> null is not a valid value for int or double - it requires
> Integer or Double.
And again someone jumps at an apparent opening in order to attack me
without actually reading carefully first.
Bad luck, Arne.
My remark:
>> Not since version 5.
was in response to:
>>>> Um, how does this work if you want the Java method to return a literal
>>>> such as int or double? I guess you are then forced to wrap the return
>>>> type in the corresponding Integer or Double, so that you have a safe
>>>> null value you can return?
as is evident in the quoted material at the start of this post. And it
is quite true that, since version five, to return a literal int or
double you are not forced to wrap the return type. You can have, say,
boolean fooAvailable;
int foo;
...
public Integer getFoo () {
if (fooAvailable) return foo;
return null;
}
and the compiler will be happy to do the wrapping for you. So you are no
longer forced to wrap anything -- sometimes the compiler does it for you.
You do still need to declare the return type as Integer or Double. But
the type of the expression in the "return" statement may now be int or
double.
In particular, if you want to return a literal, which was the particular
case at issue here, you can.
Pre-Java 5:
public Integer returnOneOrNull () {
if (foo) return Integer.valueOf(1);
return null;
}
Java 5 and later:
public Integer returnOneOrNull () {
if (foo) return 1; // An int literal is returned.
return null;
}
Nice try. Next time you want to pick a fight with someone, read more
carefully and choose your target more carefully, or better yet, think
better of it and just go on about your business.
Have a nice day.
On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
> And again someone jumps at an apparent opening in order to attack me
> without actually reading carefully first.
Yes, someone jumps at an opening to attack you. You. Do you think about why
/you/? I suspect you do think about this. I also suspect I know the conclusion
you come to when you think about this. You are thinking ``people are jumping
at opportunities to attack me, because I'm so much fucking better informed
and smarter than everyone else, that they all hate me! Everything that drips
out of my keyboard puts everyone in his proper place, and that's the
one thing they all can't stand. That is why random strangers attack me
left and right, and are soon replaced by other random strangers, and so
on.''
Am I close?
Say, here is a question. If smart people are attacked like this on Usenet, why
aren't the likes of Bjarne Stroustrup or Kent Pitman surrounded by biting
pirranhas?
Ah right; it's because they have made names for themselves, and so people
know better. What separates you from, say, Bill Joy and James Gosling is that
you're unknown.
Yep, that's it.
You're brilliant and well-informed, but unknown, and so people hate you
and attack you.
Yes, you /could/ simply descend down to their level. You could turn down your
brilliance a few megawatts, and start posting a bit of misinformed drivel here
and there.
If only you were wrong more often, the attacking would stop.
People don't ever attack misinformed morons (like themselves). Such people are
their friends. The clueless twits carry an an anti-flame waiver. They belong to
the same club and extend clueless twit courtesy toward each other.
You /could/ be like that, and avoid the flamage, but it's against your
professional integrity as a super-intelligent computer scientist.
Kaz Kylheku wrote:
> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>> And again someone jumps at an apparent opening in order to attack me
>> without actually reading carefully first.
>
> Yes, someone jumps at an opening to attack you. You. Do you think about why
> /you/?
Because I've argued against their cherished faith-based beliefs.
> You're brilliant and well-informed, but unknown, and so people hate you
> and attack you.
No, I'm fairly ordinary.
You have developed an elaborate chain of inferences from a hypothesis
that was wrong. Smarter would have been to simply ask me, rather than
make a (wrong) guess and then spend ages writing a whole bunch of stuff
that turned out to be pure nonsense.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Seamus MacRae wrote:
>>> Thomas A. Russ wrote:
>>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>> Adlai wrote:
>>>>>> You can have a function that returns some data, or
>>>>>> NIL if the data is unavailable.
>>>>> Java can do this (return an object or null), and java.util.Map.get()
>>>>> does it and is in the standard library.
>>>>
>>>> Um, how does this work if you want the Java method to return a literal
>>>> such as int or double? I guess you are then forced to wrap the return
>>>> type in the corresponding Integer or Double, so that you have a safe
>>>> null value you can return?
>>>
>>> Not since version 5.
>>
>> Also in version 5 and 6.
>>
>> null is not a valid value for int or double - it requires
>> Integer or Double.
>
> And again someone jumps at an apparent opening in order to attack me
> without actually reading carefully first.
>
> Bad luck, Arne.
>
> My remark:
>
>>> Not since version 5.
>
> was in response to:
>
>>>>> Um, how does this work if you want the Java method to return a literal
>>>>> such as int or double? I guess you are then forced to wrap the return
>>>>> type in the corresponding Integer or Double, so that you have a safe
>>>>> null value you can return?
>
> as is evident in the quoted material at the start of this post. And it
> is quite true that, since version five, to return a literal int or
> double you are not forced to wrap the return type. You can have, say,
>
> boolean fooAvailable;
> int foo;
>
> ...
>
> public Integer getFoo () {
> if (fooAvailable) return foo;
> return null;
> }
>
> and the compiler will be happy to do the wrapping for you. So you are no
> longer forced to wrap anything -- sometimes the compiler does it for you.
>
> You do still need to declare the return type as Integer or Double. But
> the type of the expression in the "return" statement may now be int or
> double.
>
> In particular, if you want to return a literal, which was the particular
> case at issue here, you can.
>
> Pre-Java 5:
>
> public Integer returnOneOrNull () {
> if (foo) return Integer.valueOf(1);
> return null;
> }
>
> Java 5 and later:
>
> public Integer returnOneOrNull () {
> if (foo) return 1; // An int literal is returned.
> return null;
> }
>
> Nice try. Next time you want to pick a fight with someone, read more
> carefully and choose your target more carefully, or better yet, think
> better of it and just go on about your business.
I think you should read more carefull yourself.
The above just proved that you have not even understood what
is being discussed.
The point is that it needs to be:
Integer returnOneOrNull()
not:
int returnOneOrNull()
to be able to return null.
Before 1.5 and after.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Seamus MacRae wrote:
>>>> Thomas A. Russ wrote:
>>>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>>> Um, how does this work if you want the Java method to return a
>>>>>> literal
>>>>>> such as int or double? I guess you are then forced to wrap the
>>>>>> return
>>>>>> type in the corresponding Integer or Double
>> Pre-Java 5:
>>
>> public Integer returnOneOrNull () {
>> if (foo) return Integer.valueOf(1);
>> return null;
>> }
>>
>> Java 5 and later:
>>
>> public Integer returnOneOrNull () {
>> if (foo) return 1; // An int literal is returned.
>> return null;
>> }
>>
>> Nice try. Next time you want to pick a fight with someone, read more
>> carefully and choose your target more carefully, or better yet, think
>> better of it and just go on about your business.
>
> I think you should read more carefull yourself.
I think you should shut up before you sink any deeper. You're in
quicksand. Or hadn't you noticed?
> The above just proved that you have not even understood what
> is being discussed.
It proved nothing of the sort. Perhaps if you'd focus on Java instead of
insults you would avoid these kinds of embarrassments, Arne.
> The point is that it needs to be:
> Integer returnOneOrNull()
> not:
> int returnOneOrNull()
> to be able to return null.
That is irrelevant. The person asked how does it work if they want to
"return a literal". Formerly you had to wrap it, for instance new
Integer(3) or Double.valueOf(42.0). Now you can just "return 3;" or
"return 42.0;".
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Seamus MacRae wrote:
>>> Arne Vajh�j wrote:
>>>> Seamus MacRae wrote:
>>>>> Thomas A. Russ wrote:
>>>>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>>>> Adlai wrote:
>>>>>>>> You can have a function that returns some data, or
>>>>>>>> NIL if the data is unavailable.
>>>>>>>> Java can do this (return an object or null), and java.util.Map.get()
>>>>>>>> does it and is in the standard library.
>>>>>>> Um, how does this work if you want the Java method to return a
>>>>>>> literal
>>>>>>> such as int or double? I guess you are then forced to wrap the
>>>>>>> return
>>>>>>> type in the corresponding Integer or Double
>>> Pre-Java 5:
>>>
>>> public Integer returnOneOrNull () {
>>> if (foo) return Integer.valueOf(1);
>>> return null;
>>> }
>>>
>>> Java 5 and later:
>>>
>>> public Integer returnOneOrNull () {
>>> if (foo) return 1; // An int literal is returned.
>>> return null;
>>> }
>>>
>>> Nice try. Next time you want to pick a fight with someone, read more
>>> carefully and choose your target more carefully, or better yet, think
>>> better of it and just go on about your business.
>>
>> I think you should read more carefull yourself.
>
> I think you should shut up before you sink any deeper. You're in
> quicksand. Or hadn't you noticed?
>
>> The above just proved that you have not even understood what
>> is being discussed.
>
> It proved nothing of the sort. Perhaps if you'd focus on Java instead of
> insults you would avoid these kinds of embarrassments, Arne.
>
>> The point is that it needs to be:
>> Integer returnOneOrNull()
>> not:
>> int returnOneOrNull()
>> to be able to return null.
>
> That is irrelevant. The person asked how does it work if they want to
> "return a literal". Formerly you had to wrap it, for instance new
> Integer(3) or Double.valueOf(42.0). Now you can just "return 3;" or
> "return 42.0;".
No.
They were discussing whether they needed to wrap to be able to
return null.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Seamus MacRae wrote:
>>>> Arne Vajh�j wrote:
>>>>> Seamus MacRae wrote:
>>>>>> Thomas A. Russ wrote:
>>>>>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>>>>> Um, how does this work if you want the Java method to return a
I did not. The attributions have gotten mixed up somehow in the history
of this part of this thread. Thomas actually wrote it.
>>>>>>>> literal
>>>>>>>> such as int or double? I guess you are then forced to wrap the
>>>>>>>> return
>>>>>>>> type in the corresponding Integer or Double
>>> The point is that it needs to be:
>>> Integer returnOneOrNull()
>>> not:
>>> int returnOneOrNull()
>>> to be able to return null.
>>
>> That is irrelevant. The person asked how does it work if they want to
>> "return a literal". Formerly you had to wrap it, for instance new
>> Integer(3) or Double.valueOf(42.0). Now you can just "return 3;" or
>> "return 42.0;".
>
> No.
Yes. You can indeed "return 42.0;" now.
Or if you are objecting to "the person asked how does it work if they
want to return a literal", I will repost the appropriate quotation for you:
>>>>>>> Um, how does this work if you want the Java method to return a
>>>>>>> literal such as int or double? I guess you are then forced to
>>>>>>> wrap the return type in the corresponding Integer or Double
Now please drop this.
> They were discussing whether they needed to wrap to be able to
> return null.
They do not:
public Integer foobar (boolean baz) {
if (baz) return 42; // Look, ma, an unwrapped literal!
return null; // Look, ma, I'm able to return null!
}
The compiler can do the wrapping for them. As I originally stated.
On May 16, 1:05 am, Adlai <·········@gmail.com> wrote:
> On May 16, 7:46 am, Series Expansion <·······@gmail.com> wrote:
> > Obviously not Lisp; how can the compiler catch a type error in code
> > that has no types, just list atoms?
>
> Go back and read what the guy said
How rude.
> You can make type declarations in Lisp. They look like:
> (declare (float x y z)
> (list a b c))
Let me guess: using macros to try to graft on some sort of poor-man's
type-checking?
That seems to cement the case for static vs. dynamic typing -- users
of dynamic languages end up finding ways to emulate static typing!
> > Do what sort of stuff? Accidentally wind up with a Float in a pack of
> > Strings? Why would you want to? :)
>
> Do things like have a pack of THINGS, rather than a pack of strings.
Java's List<?> doesn't float your boat? Why?
> You can have a heterogenous list and
> Lisp won't blink. You can have a function that returns some data, or
> NIL if the data is unavailable. You can bind the result of that
> function to a variable without worrying about types.
Sounds an awful lot like:
import java.util.*;
...
private Map<Object,String> nameMap = new HashMap<Object,String>();
...
public List<String> getNameList (List<?> list) {
List<String> result = new LinkedList<String>();
for (Object o : list) {
String s = nameMap.get(o);
if (s != null) result.add(s);
}
return result;
}
Lists of anything, methods that return some data or null, a variable
that can hold some data or null -- anything missing?
> > > All of this is actually orthogonal to compiler checks.
>
> > No, of course not; without static typing, the compiler has no type
> > information to use when checking anything, since as far as it knows,
> > any variable might hold any value of any type whatsoever.
>
> See the above
See above re: faking it.
> > > This is a good example of what would happen if I were using Java (or
> > > any statically typed language; I believe) to do meta-programming.
>
> > It's a good example of what would happen if you were to do meta-
> > programming, period.
>
> > At least Java meta-programming doesn't have the bane of macro-based
> > meta-programming: variable capture.
>
> Variable capture is a useful tool sometimes, for example in anaphoric
> macros.
Someone call the doctor -- Adlai has anaphoric macros!
Er -- what are anaphoric macros?
Useful tool? Even if so, variable capture is clearly a dual-edged
sword. Lisp macros? Dual-edged Swiss-army knife, maybe.
> Like normal if, when, etc, except that they bind the result of
> the test to the variable IT.
Global variables for fun and profit! I bet you guys get ...
*interesting* scaling problems with large projects. :)
On 16 maio, 16:20, Series Expansion <·······@gmail.com> wrote:
> On May 16, 1:05 am, Adlai <·········@gmail.com> wrote:
>
> > On May 16, 7:46 am, Series Expansion <·······@gmail.com> wrote:
> > > Obviously not Lisp; how can the compiler catch a type error in code
> > > that has no types, just list atoms?
>
> > Go back and read what the guy said
>
> How rude.
>
> > You can make type declarations in Lisp. They look like:
> > (declare (float x y z)
> > (list a b c))
>
> Let me guess: using macros to try to graft on some sort of poor-man's
> type-checking?
Not poor-man's, but very precise and powerful type-derivation and type-
checking. Not having to worry about variable types is a bless. Having
a compiler that detects the type of the variable by your code is also
a bless. Having the option to tune optimization by declaring types
(specially where the compiler gives you the hints) is also a bless.
>
> That seems to cement the case for static vs. dynamic typing -- users
> of dynamic languages end up finding ways to emulate static typing!
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.
We only "emulate" static typing in the places that need speed, the so
called bottlenecks.
> > Variable capture is a useful tool sometimes, for example in anaphoric
> > macros.
>
> Someone call the doctor -- Adlai has anaphoric macros!
>
> Er -- what are anaphoric macros?
>
> Useful tool? Even if so, variable capture is clearly a dual-edged
> sword. Lisp macros? Dual-edged Swiss-army knife, maybe.
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.
>
> > Like normal if, when, etc, except that they bind the result of
> > the test to the variable IT.
>
> Global variables for fun and profit! I bet you guys get ...
> *interesting* scaling problems with large projects. :)
The binding is local to the use of the if form, not global.
On May 16, 3:42 pm, gugamilare <··········@gmail.com> wrote:
> On 16 maio, 16:20, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 1:05 am, Adlai <·········@gmail.com> wrote:
> > > You can make type declarations in Lisp. They look like:
> > > (declare (float x y z)
> > > (list a b c))
>
> > Let me guess: using macros to try to graft on some sort of poor-man's
> > type-checking?
>
> 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.
> > That seems to cement the case for static vs. dynamic typing -- users
> > of dynamic languages end up finding ways to emulate static typing!
>
> 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.
> > > Variable capture is a useful tool sometimes, for example in anaphoric
> > > macros.
>
> > Someone call the doctor -- Adlai has anaphoric macros!
>
> > Er -- what are anaphoric macros?
>
> > Useful tool? Even if so, variable capture is clearly a dual-edged
> > sword. Lisp macros? Dual-edged Swiss-army knife, maybe.
>
> 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.
> > > Like normal if, when, etc, except that they bind the result of
> > > the test to the variable IT.
>
> > Global variables for fun and profit! I bet you guys get ...
> > *interesting* scaling problems with large projects. :)
>
> 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.)
Series Expansion <·······@gmail.com> writes:
> On May 16, 3:42�pm, gugamilare <··········@gmail.com> wrote:
>> On 16 maio, 16:20, Series Expansion <·······@gmail.com> wrote:
>> > On May 16, 1:05�am, Adlai <·········@gmail.com> wrote:
>> > > You can make type declarations in Lisp. They look like:
>> > > (declare (float x y z)
>> > > � � � � �(list �a b c))
>>
>> > Let me guess: using macros to try to graft on some sort of poor-man's
>> > type-checking?
>>
>> 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.
I can't wait when Haskell and type inference will be discussed here :-)
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 16, 3:42 pm, gugamilare <··········@gmail.com> wrote:
>>> On 16 maio, 16:20, Series Expansion <·······@gmail.com> wrote:
>>>> On May 16, 1:05 am, Adlai <·········@gmail.com> wrote:
>>>>> You can make type declarations in Lisp. They look like:
>>>>> (declare (float x y z)
>>>>> (list a b c))
>>>> Let me guess: using macros to try to graft on some sort of poor-man's
>>>> type-checking?
>>> 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.
>
> I can't wait when Haskell and type inference will be discussed here :-)
Please don't feed the troll.
--
Lew
On May 17, 12:32 pm, Lew <·····@lewscanon.com> wrote:
> Pascal J. Bourguignon wrote:
> > Series Expansion <·······@gmail.com> writes:
>
> >> On May 16, 3:42 pm, gugamilare <··········@gmail.com> wrote:
> >>> On 16 maio, 16:20, Series Expansion <·······@gmail.com> wrote:
> >>>> On May 16, 1:05 am, Adlai <·········@gmail.com> wrote:
> >>>>> You can make type declarations in Lisp. They look like:
> >>>>> (declare (float x y z)
> >>>>> (list a b c))
> >>>> Let me guess: using macros to try to graft on some sort of poor-man's
> >>>> type-checking?
> >>> 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.
>
> > I can't wait when Haskell and type inference will be discussed here :-)
>
> Please don't feed the troll.
Fascinating. Another unprovoked, illogical instance of name-calling
and not even directed at the person who'd posted.
It is a mystery how this is supposed to convince anyone to favor
either Lisp *or* Java.
On May 17, 12:32 pm, Lew <·····@lewscanon.com> wrote:
> Pascal J. Bourguignon wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> 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.
>
> > I can't wait when Haskell and type inference will be discussed here :-)
>
> Please don't feed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Pascal.
(Reposted after original was silently redirected to hide my response
from comp.lang.java.programmer. "Lew", your perfidy knows no bounds.)
Series Expansion <·······@gmail.com> writes:
> On May 16, 3:42��pm, gugamilare <··········@gmail.com> wrote:
> > On 16 maio, 16:20, Series Expansion <·······@gmail.com> wrote:
> > > On May 16, 1:05��am, Adlai <·········@gmail.com> wrote:
> > > > You can make type declarations in Lisp. They look like:
> > > > (declare (float x y z)
> > > > �� �� �� �� ��(list ��a b c))
> >
> > > Let me guess: using macros to try to graft on some sort of poor-man's
> > > type-checking?
> >
> > 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.
Hmmm. It seems to be in the language spec:
http://www.lispworks.com/documentation/HyperSpec/Body/s_declar.htm
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 16, 3:42Ž pm, gugamilare <··········@gmail.com> wrote:
>>> On 16 maio, 16:20, Series Expansion <·······@gmail.com> wrote:
>>>> On May 16, 1:05Ž am, Adlai <·········@gmail.com> wrote:
>>>>> You can make type declarations in Lisp. They look like:
>>>>> (declare (float x y z)
>>>>> Ž Ž Ž Ž Ž (list Ž a b c))
>>>> Let me guess: using macros to try to graft on some sort of poor-man's
>>>> type-checking?
>>> 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.
>
> Hmmm. It seems to be in the language spec:
>
>
> http://www.lispworks.com/documentation/HyperSpec/Body/s_declar.htm
Nothing to do with Java.
--
Lew
On May 18, 12:46 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 16, 3:42Ž pm, gugamilare <··········@gmail.com> wrote:
> > > On 16 maio, 16:20, Series Expansion <·······@gmail.com> wrote:
> > > > On May 16, 1:05Ž am, Adlai <·········@gmail.com> wrote:
> > > > > You can make type declarations in Lisp. They look like:
> > > > > (declare (float x y z)
> > > > > Ž Ž Ž Ž Ž (list Ž a b c))
>
> > > > Let me guess: using macros to try to graft on some sort of poor-man's
> > > > type-checking?
>
> > > 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.
>
> [calls me a liar]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
On May 15, 5:21 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> "eric-and-jane-smith" <·······@nospam.com> writes:
> > ····@informatimago.com (Pascal J. Bourguignon) wrote in
> >···················@galatea.local:
>
> >> Lisp macros are just a much simplier and much more powerful to archive
> >> the same results much faster.
>
> > It's hard to make the power of CL macros clear to non-Lispers. They think
> > in terms of the macros of other programming languages, and have no idea
> > what CL macros are. From their point of view, we seem to be telling them
> > we want to use macros as a klugey substitute for C++ templates, or for the
> > Java type system, or whatever.
>
> > This kind of debate tends to go in circles till it degenerates, because the
> > parties aren't really communicating, because the same words mean different
> > things to them.
>
> Ok, then let me summarize lisp macros as being hooks in the lisp compiler.
>
> Imagine what you could do if you could modify your compiler on the fly:
- you could blow things up in completely new and exotic ways
- you could generate bugs it would take a crack team of comp.sci
Ph.D.s to track down
- you could find previous/other programs no longer compiling, or
worse, compiling but no longer working correctly once recompiled
The potential here is for foot-bullets express-delivered by a fully-
automatic assault rifle instead of the revolver Java gives you, C's
shotgun, or C++'s, semiauto pistol.
It's not a surprise that it's heavily used in comp.sci research but
you don't see many desktop applications written in Lisp, then.
It has its niche. But I see problems with its ability to achieve
widespread use for more ordinary and common-place applications.
On 15 maio, 15:12, Series Expansion <·······@gmail.com> wrote:
> On May 15, 5:21 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Ok, then let me summarize lisp macros as being hooks in the lisp compiler.
>
> > Imagine what you could do if you could modify your compiler on the fly:
>
> - you could blow things up in completely new and exotic ways
>
> - you could generate bugs it would take a crack team of comp.sci
> Ph.D.s to track down
>
> - you could find previous/other programs no longer compiling, or
> worse, compiling but no longer working correctly once recompiled
>
> The potential here is for foot-bullets express-delivered by a fully-
> automatic assault rifle instead of the revolver Java gives you, C's
> shotgun, or C++'s, semiauto pistol.
>
> It's not a surprise that it's heavily used in comp.sci research but
> you don't see many desktop applications written in Lisp, then.
>
> It has its niche. But I see problems with its ability to achieve
> widespread use for more ordinary and common-place applications.
It does not work like that at all, it is very different from that
actually. Macros don't CHANGE your code, they GENERATE code. They
can't CREATE bugs on your code. They themselves can be buggy, exactly
like any other function, but they won't kill your code like that. And
they don't introduce bugs in the compiler either - it is just plain
simple list manipulation. You could write macros using only if, cons,
car and cdr, and maybe some arithmetic functions to compute some
number. Of course this is not the best way to do it, but, behind the
scenes, it is what is being done.
It would be comparable to some function in Java that generates text
that is going to be evaluated by the compiler as the real code instead
of the macro call. Someone said that Seed7 templates are just a
function that is run during compile time. Well, that is the very
definition of Lisp macros.
There are systems written in CL that survive (or survived) for years
running WHILE being developed / debugged / used, so you CANNOT say
that CL have this huge security hole, or that it is that simple to
blow everything up.
If you don't want to learn Lisp to really know what macros are, fine,
but don't start flaming about things that you don't understand. I did
not say that Java is a bad language.
On May 15, 2:44 pm, gugamilare <··········@gmail.com> wrote:
> On 15 maio, 15:12, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 15, 5:21 am, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> > > Ok, then let me summarize lisp macros as being hooks in the lisp compiler.
>
> > > Imagine what you could do if you could modify your compiler on the fly:
>
> > - you could blow things up in completely new and exotic ways
>
> > - you could generate bugs it would take a crack team of comp.sci
> > Ph.D.s to track down
>
> > - you could find previous/other programs no longer compiling, or
> > worse, compiling but no longer working correctly once recompiled
>
> > The potential here is for foot-bullets express-delivered by a fully-
> > automatic assault rifle instead of the revolver Java gives you, C's
> > shotgun, or C++'s, semiauto pistol.
>
> > It's not a surprise that it's heavily used in comp.sci research but
> > you don't see many desktop applications written in Lisp, then.
>
> > It has its niche. But I see problems with its ability to achieve
> > widespread use for more ordinary and common-place applications.
>
> It does not work like that at all, it is very different from that
> actually. Macros don't CHANGE your code, they GENERATE code.
Code with bugs, potentially, if the macro OR its inputs has bugs.
> It would be comparable to some function in Java that generates text
> that is going to be evaluated by the compiler as the real code instead
> of the macro call. Someone said that Seed7 templates are just a
> function that is run during compile time. Well, that is the very
> definition of Lisp macros.
Templates are a notorious source of headaches in languages that
support them.
They are a source of power too; I don't claim otherwise. But with that
power tends to come a greater complexity to bug-hunting. The more
tightly coupled some pieces of code are (say, a macro and its inputs)
the harder it is to narrow a bug down to exactly one of those pieces.
> There are systems written in CL that survive (or survived) for years
> running WHILE being developed / debugged / used, so you CANNOT say
> that CL have this huge security hole, or that it is that simple to
> blow everything up.
Who said anything about security holes? And there's another issue --
modifying a running system.
1. If you goof, the whole thing might come down like a house of cards.
You can actually do that in Java now with the debugging interface
-- change something to null that shouldn't be, while the program
is running, and watch the dominos go over one by one.
So, if you have a mission-critical system (say, your web site)
and change something and goof, you're off the air and one of
your customers is inexplicably billed for $1,048,576.00 instead
of $19.99 for their order of the it-slices-it-dices-of-the-week.
Versus editing source files, then compiling them to a binary
(NOT overwriting the running, production one), then running the
new binary on a test machine and debugging it until it works,
then quietly replacing the old binary with the new-but-tested one.
Now your customers won't get subjected to your betas, alphas, and
pre-alphas without notice or consent. No JEE programmer worth his
salt would be caught dead changing their production system while
it was running for obvious reasons.
2. If you change the code on the fly, where do the changes go? Will
they survive a restart of the program, a reboot of the box, a
power failre? How does any of this integrate with revision
control? Oh, wait, see point 1: there probably cannot even be
any revision control, and Lord knows where the source files go,
if there even are any.
> If you don't want to learn Lisp to really know what macros are, fine,
> but don't start flaming about things that you don't understand. I did
> not say that Java is a bad language.
Flaming? Flaming?? Flaming is when a bunch of invaders from
comp.lang.lisp pop up in comp.lang.java.programmer and call some
nicely formatted Java code someone posted a "pile of vomit", which is
something I distinctly recall seeing upthread just a little ways. It
wasn't my code, so I let it pass, but I did notice it.
On 15 maio, 16:29, Series Expansion <·······@gmail.com> wrote:
> On May 15, 2:44 pm, gugamilare <··········@gmail.com> wrote:
>
>
>
> > On 15 maio, 15:12, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 15, 5:21 am, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
>
> > > > Ok, then let me summarize lisp macros as being hooks in the lisp compiler.
>
> > > > Imagine what you could do if you could modify your compiler on the fly:
>
> > > - you could blow things up in completely new and exotic ways
>
> > > - you could generate bugs it would take a crack team of comp.sci
> > > Ph.D.s to track down
>
> > > - you could find previous/other programs no longer compiling, or
> > > worse, compiling but no longer working correctly once recompiled
>
> > > The potential here is for foot-bullets express-delivered by a fully-
> > > automatic assault rifle instead of the revolver Java gives you, C's
> > > shotgun, or C++'s, semiauto pistol.
>
> > > It's not a surprise that it's heavily used in comp.sci research but
> > > you don't see many desktop applications written in Lisp, then.
>
> > > It has its niche. But I see problems with its ability to achieve
> > > widespread use for more ordinary and common-place applications.
>
> > It does not work like that at all, it is very different from that
> > actually. Macros don't CHANGE your code, they GENERATE code.
>
> Code with bugs, potentially, if the macro OR its inputs has bugs.
Just like a function can have bugs. Or do you write bugless functions?
Tell me the secret then.
By using macros the bug will be in one single place, so you can easily
change it. If you write the same code a hundred times and realize that
it is wrong, you will have to change the one hundred places where you
wrote that same thing. This is clearly not the case if you use a macro
- there is only one place that you need to change. Of course you can't
make things perfectly, but they do most of the times get a lot better
if you use macros.
>
> > It would be comparable to some function in Java that generates text
> > that is going to be evaluated by the compiler as the real code instead
> > of the macro call. Someone said that Seed7 templates are just a
> > function that is run during compile time. Well, that is the very
> > definition of Lisp macros.
>
> Templates are a notorious source of headaches in languages that
> support them.
Macros are not a source of headaches in CL because they are most times
as simple as a normal function. And you can always expand the code
directly from the source (by hitting a small sequence of keystrokes)
if you thing it has a bug somewhere.
>
> They are a source of power too; I don't claim otherwise. But with that
> power tends to come a greater complexity to bug-hunting. The more
> tightly coupled some pieces of code are (say, a macro and its inputs)
> the harder it is to narrow a bug down to exactly one of those pieces.
I really don't think this is the case with CL macros.
>
> > There are systems written in CL that survive (or survived) for years
> > running WHILE being developed / debugged / used, so you CANNOT say
> > that CL have this huge security hole, or that it is that simple to
> > blow everything up.
>
> Who said anything about security holes? And there's another issue --
> modifying a running system.
>
> 1. If you goof, the whole thing might come down like a house of cards.
> You can actually do that in Java now with the debugging interface
> -- change something to null that shouldn't be, while the program
> is running, and watch the dominos go over one by one.
> So, if you have a mission-critical system (say, your web site)
> and change something and goof, you're off the air and one of
> your customers is inexplicably billed for $1,048,576.00 instead
> of $19.99 for their order of the it-slices-it-dices-of-the-week.
> Versus editing source files, then compiling them to a binary
> (NOT overwriting the running, production one), then running the
> new binary on a test machine and debugging it until it works,
> then quietly replacing the old binary with the new-but-tested one.
> Now your customers won't get subjected to your betas, alphas, and
> pre-alphas without notice or consent. No JEE programmer worth his
> salt would be caught dead changing their production system while
> it was running for obvious reasons.
Listen, I didn't design the system, so I don't know about how things
worked. This is just an example of how stable and modifiable a CL
system can be.
> 2. If you change the code on the fly, where do the changes go? Will
> they survive a restart of the program, a reboot of the box, a
> power failre? How does any of this integrate with revision
> control? Oh, wait, see point 1: there probably cannot even be
> any revision control, and Lord knows where the source files go,
> if there even are any.
How about saving your changes in a file before you load them??? And
using a persistent database as well. This is the programmer's problem.
>
> > If you don't want to learn Lisp to really know what macros are, fine,
> > but don't start flaming about things that you don't understand. I did
> > not say that Java is a bad language.
>
> Flaming? Flaming?? Flaming is when a bunch of invaders from
> comp.lang.lisp pop up in comp.lang.java.programmer and call some
> nicely formatted Java code someone posted a "pile of vomit", which is
> something I distinctly recall seeing upthread just a little ways. It
> wasn't my code, so I let it pass, but I did notice it.
It surely wasn't me who did that, so don't throw it on my face.
On May 15, 3:52 pm, gugamilare <··········@gmail.com> wrote:
> > Code with bugs, potentially, if the macro OR its inputs has bugs.
>
> Just like a function can have bugs. Or do you write bugless functions?
> Tell me the secret then.
Did you miss the bit about tight coupling making it harder to find the
bugs?
> By using macros the bug will be in one single place, so you can easily
> change it. If you write the same code a hundred times and realize that
> it is wrong, you will have to change the one hundred places where you
> wrote that same thing.
If your editor doesn't support search and replace, I suggest you
search for a new one to replace it. :)
> > > It would be comparable to some function in Java that generates text
> > > that is going to be evaluated by the compiler as the real code instead
> > > of the macro call. Someone said that Seed7 templates are just a
> > > function that is run during compile time. Well, that is the very
> > > definition of Lisp macros.
>
> > Templates are a notorious source of headaches in languages that
> > support them.
>
> Macros are not a source of headaches in CL because they are most times
> as simple as a normal function. And you can always expand the code
> directly from the source (by hitting a small sequence of keystrokes)
> if you thing it has a bug somewhere.
And now you've replaced a bit of your code with the expanded version.
Later you'll change the macro for whatever reason, but at this one
spot the change won't be applied since the macro call was replaced
with its expansion in your editor at that spot. That copy now gets out
of synch with the rest of the code.
Of course, a proper IDE should let you right click on the macro call
and get a menu with options like "go to definition", "view
documentation", and "see expansion in a pop-over window WITHOUT
altering the code in your source file". For that you need something
obviously way more sophisticated than what you're describing, which
("small sequence of keystrokes") sounds suspiciously like emacs.
My Java IDE (NetBeans) has features like these (for class and function
identifiers, rather than macros). I can jump to the code for the
function or class, or view the documentation for it if it has any, and
a bunch of other things too. Even bulk-rename without affecting same-
name ones in different scopes (same-name classes in different
packages, same-name methods in different classes, etc.).
Having a fancier user-interface than a box of letters can come in
handy that way sometimes. Though I'm sad to hear than in your case,
your relatively crude development tools actually encourage you to do
things that will eventually result on parts of your code getting out
of synch with one another.
The irony being that that was basically the criticism you leveled at
Java and its frequent need for boilerplate code: if I make 100 copies
and later need to change something I have to track them all down. You
may actually have it worse:
1. You write a macro.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2. At one point, something goes wrong so you hit a "small sequence of
keystrokes" to do an in-place replacement of a call to that macro
with its expansion.
3. You fix the bug in the macro, whatever it was, but don't change
that other code back into a macro call.
4. Later, you make a change to the macro.
5. Because you didn't copy-paste that code all over the place, you
think you DON'T have to go track down copies and make sure
they're all in synch. As a result, the expanded copy produced
in step 2 doesn't end up reflecting the change.
6. Now you've got code that's getting out of synch with other code.
Congratulations, gugamilare, it's a bug!
> > They are a source of power too; I don't claim otherwise. But with that
> > power tends to come a greater complexity to bug-hunting. The more
> > tightly coupled some pieces of code are (say, a macro and its inputs)
> > the harder it is to narrow a bug down to exactly one of those pieces.
>
> I really don't think this is the case with CL macros.
I don't see how it can fail to be. Obviously the code at the macro
call site intimately depends on the macro's innards -- for example, if
one input to the macro is an expression with side-effects, the number
of times the side-effects happen and the order in which side-effects
of different inputs happen will depend heavily on the exact macro
code. So certainly code that calls the macro will break if the macro
implementation (not just its signature) changes. The reverse is also
true: if the macro takes the inputs apart with car and cdr to
transform them in some way, its correctness will depend on the inputs
having the correct structure.
So, the macro definition and every call site of the macro will be
tightly coupled.
A Java method or C function definition is more loosely coupled. Since
it's just values of some sort passed as parameters, rather than code,
the order of side-effects of the arguments is well-defined: each
happens once, in left-to-right-order, at the call site and just before
the call itself. With pass-by-value (Java primitives and non-pointer C
parameters) the function also won't alter the passed-in data. With
pass-by-reference (Java objects with mutable state, pointers, C++
references) the function can alter the passed-in data but its
implementation still won't influence side effects and order of
evaluation of the argument expressions.
Macros may be able to do powerful things, but with that power comes
the greater potential for problems. (Others have mentioned variable
capture, so I won't go into detail about that here.)
> > Who said anything about security holes? And there's another issue --
> > modifying a running system.
>
> > 1. If you goof, the whole thing might come down like a house of cards.
> > You can actually do that in Java now with the debugging interface
> > -- change something to null that shouldn't be, while the program
> > is running, and watch the dominos go over one by one.
> > So, if you have a mission-critical system (say, your web site)
> > and change something and goof, you're off the air and one of
> > your customers is inexplicably billed for $1,048,576.00 instead
> > of $19.99 for their order of the it-slices-it-dices-of-the-week.
> > Versus editing source files, then compiling them to a binary
> > (NOT overwriting the running, production one), then running the
> > new binary on a test machine and debugging it until it works,
> > then quietly replacing the old binary with the new-but-tested one.
> > Now your customers won't get subjected to your betas, alphas, and
> > pre-alphas without notice or consent. No JEE programmer worth his
> > salt would be caught dead changing their production system while
> > it was running for obvious reasons.
>
> Listen, I didn't design the system, so I don't know about how things
> worked. This is just an example of how stable and modifiable a CL
> system can be.
A made-up example. You haven't named a real, running mission-critical
system that is routinely modified on the fly while in production use
and has no back-ups.
Show me one of those, and I'll show you a headline from the future:
"Over sixty thousand customers in the dark after catastrophic computer
failure at power distribution center", "Over three hundred million
awarded in class-action suit over defective products caused by process
control computer error", "One person dead after ill-timed heart attack
during last night's six-hour 911 outage", "E-commerce giant courting
bankruptcy after catastrophic three-week Web site downtime", or
something along those lines.
> > 2. If you change the code on the fly, where do the changes go? Will
> > they survive a restart of the program, a reboot of the box, a
> > power failre? How does any of this integrate with revision
> > control? Oh, wait, see point 1: there probably cannot even be
> > any revision control, and Lord knows where the source files go,
> > if there even are any.
>
> How about saving your changes in a file before you load them???
These were changes being made to the copy of the program running in
RAM using the debugging tools, remember? Not to the source code on
disk.
> And using a persistent database as well. This is the programmer's problem.
Problems like those are why I prefer NetBeans to Eclipse. Having the
code base reside solely in a database in the guts of the IDE leads to
headaches with migration, headaches with versioning-system
integration, migraine headaches with using a versioning system
externally INSTEAD of integratedly, and potential loss of data that
you can't even get at with normal tools and maybe can't even easily
find to back up.
Series Expansion <·······@gmail.com> writes:
> And now you've replaced a bit of your code with the expanded version.
> Later you'll change the macro for whatever reason, but at this one
> spot the change won't be applied since the macro call was replaced
> with its expansion in your editor at that spot. That copy now gets out
> of synch with the rest of the code.
>
> Of course, a proper IDE should let you right click on the macro call
> and get a menu with options like "go to definition", "view
> documentation", and "see expansion in a pop-over window WITHOUT
> altering the code in your source file". For that you need something
> obviously way more sophisticated than what you're describing, which
> ("small sequence of keystrokes") sounds suspiciously like emacs.
My Lisp IDE can do all this. In combination with my Lisp implementation
of choice, it also shows undefined functions, undefined variables, and
even type errors etc. _at compilation time_. In the debugger I can jump
to the exact _expression_ (not just line) corresponding to a frame in
the backtrace. I can evaluate or inspect arbitrary things in the context
of a frame, and I can also restart the computation from a frame shown in
the debugger after I fixed the bug and reloaded the new function
definition interactively.
Yes, it's Emacs.
-T.
On May 15, 6:17 pm, "Tobias C. Rittweiler" <····@freebits.de.invalid>
wrote:
> Series Expansion <·······@gmail.com> writes:
> > And now you've replaced a bit of your code with the expanded version.
> > Later you'll change the macro for whatever reason, but at this one
> > spot the change won't be applied since the macro call was replaced
> > with its expansion in your editor at that spot. That copy now gets out
> > of synch with the rest of the code.
>
> > Of course, a proper IDE should let you right click on the macro call
> > and get a menu with options like "go to definition", "view
> > documentation", and "see expansion in a pop-over window WITHOUT
> > altering the code in your source file". For that you need something
> > obviously way more sophisticated than what you're describing, which
> > ("small sequence of keystrokes") sounds suspiciously like emacs.
>
> My Lisp IDE can do all this.
It sure beats the text editors most of the other lispies here are
apparently using, then.
> In combination with my Lisp implementation of choice, it also shows
> undefined functions, undefined variables, and even type errors
What? No! That simply isn't possible. How can it show type errors?
Function parameters and suchlike have no types in Lisp. I suppose it
could try some sort of type inference, but then we'd have a statically-
typed funcional language a bit like OCaml, not Lisp anymore.
> Yes, it's Emacs.
You just described a bunch of features that require a GUI to present
usably. I hope you realize that.
On May 16, 7:49 am, Series Expansion <·······@gmail.com> wrote:
> On May 15, 6:17 pm, "Tobias C. Rittweiler" <····@freebits.de.invalid>
> wrote:
>
> > Series Expansion <·······@gmail.com> writes:
> > > And now you've replaced a bit of your code with the expanded version.
> > > Later you'll change the macro for whatever reason, but at this one
> > > spot the change won't be applied since the macro call was replaced
> > > with its expansion in your editor at that spot. That copy now gets out
> > > of synch with the rest of the code.
>
> > > Of course, a proper IDE should let you right click on the macro call
> > > and get a menu with options like "go to definition", "view
> > > documentation", and "see expansion in a pop-over window WITHOUT
> > > altering the code in your source file". For that you need something
> > > obviously way more sophisticated than what you're describing, which
> > > ("small sequence of keystrokes") sounds suspiciously like emacs.
>
> > My Lisp IDE can do all this.
>
> It sure beats the text editors most of the other lispies here are
> apparently using, then.
>
> > In combination with my Lisp implementation of choice, it also shows
> > undefined functions, undefined variables, and even type errors
>
> What? No! That simply isn't possible. How can it show type errors?
> Function parameters and suchlike have no types in Lisp. I suppose it
> could try some sort of type inference, but then we'd have a statically-
> typed funcional language a bit like OCaml, not Lisp anymore.
>
> > Yes, it's Emacs.
>
> You just described a bunch of features that require a GUI to present
> usably. I hope you realize that.
Series, PLEASE read my first post in this thread, in reply to Seamus
MacRae. I describe the difference between the Emacs you're thinking of
and the Emacs that we use today.
On May 16, 1:07 am, Adlai <·········@gmail.com> wrote:
> On May 16, 7:49 am, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 15, 6:17 pm, "Tobias C. Rittweiler" <····@freebits.de.invalid>
> > wrote:
>
> > > Series Expansion <·······@gmail.com> writes:
> > > > And now you've replaced a bit of your code with the expanded version.
> > > > Later you'll change the macro for whatever reason, but at this one
> > > > spot the change won't be applied since the macro call was replaced
> > > > with its expansion in your editor at that spot. That copy now gets out
> > > > of synch with the rest of the code.
>
> > > > Of course, a proper IDE should let you right click on the macro call
> > > > and get a menu with options like "go to definition", "view
> > > > documentation", and "see expansion in a pop-over window WITHOUT
> > > > altering the code in your source file". For that you need something
> > > > obviously way more sophisticated than what you're describing, which
> > > > ("small sequence of keystrokes") sounds suspiciously like emacs.
>
> > > My Lisp IDE can do all this.
>
> > It sure beats the text editors most of the other lispies here are
> > apparently using, then.
>
> > > In combination with my Lisp implementation of choice, it also shows
> > > undefined functions, undefined variables, and even type errors
>
> > What? No! That simply isn't possible. How can it show type errors?
> > Function parameters and suchlike have no types in Lisp. I suppose it
> > could try some sort of type inference, but then we'd have a statically-
> > typed funcional language a bit like OCaml, not Lisp anymore.
>
> > > Yes, it's Emacs.
>
> > You just described a bunch of features that require a GUI to present
> > usably. I hope you realize that.
>
> Series, PLEASE read my first post in this thread
The first post in this thread was some guy whining that he couldn't
get a job. You'll forgive me if I fail to see how that's relevant to
the Great Lisp vs. Java Debate of 2009.
On 16 maio, 16:21, Series Expansion <·······@gmail.com> wrote:
> The first post in this thread was some guy whining that he couldn't
> get a job. You'll forgive me if I fail to see how that's relevant to
> the Great Lisp vs. Java Debate of 2009.
What the hell of a good point you have (ironic). Should I look for
unemployed Java programmers? I bet there are some.
This is not Lisp vs. Java debate. We are not attacking Java at all,
because we are not the trolls here. This is more a "Java programmers
that don't understand and never programmed in Lisp before rudely,
pointlessly and with very weak arguments attacking Lisp" debate. Give
me one reference to someone here saying that Java is a bad language,
and I am done talking. Maybe someone pointed out one or two
deficiencies of Java, but this is not untrue for Lisp as well - Lisp
is not perfect, you know, but it IS a great language, and you will
only understand that if you learn it. You Javaers are the ones
treating us like if we are a bunch of amateurs who don't know how to
program.
We over here are just showing why you are wrong, but this is a
difficult task since for every argument we make, you bring the very
same feature to the world of Java - where things are very different
from the world of Lisp - and argument in your world why this feature
is a bad thing. I agree, these features would be bad in the JAVA
language, but they are not an issue in the CL language, and you MUST
learn CL (or at least a simpler Lisp dialect like scheme) to
understand why. Java and CL are very, very, very different languages.
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. 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.
Series Expansion wrote:
>> The first post in this thread was some guy whining that he couldn't
>> get a job. You'll forgive me if I fail to see how that's relevant to
>> the Great Lisp vs. Java Debate of 2009.
gugamilare wrote:
> This is not Lisp vs. Java debate. We are not attacking Java at all,
> because we are not the trolls here. This is more a "Java programmers
> that don't understand and never programmed in Lisp before rudely,
> pointlessly and with very weak arguments attacking Lisp" debate. Give
"Series" does not represent the typical Java programmer.
> You Javaers are the ones
> treating us like if we are a bunch of amateurs who don't know how to
> program.
Now that is a very unfair generalization. Don't tar Java programmers with the
"Series Expansion" brush. I'm a Java programmer myself, but that doesn't mean
I agree with or endorse his behavior.
In fact, I don't. I assess that "Series" is a brat.
From time to time even entirely within the comp.lang.java.programmer
newsgroup we get posts from people who profess to be Java programmers but only
use the forum to exercise their nasty little egos. Does that never happen
entirely within the comp.lang.lisp group? Is everyone who posts their fair
and balanced?
Clearly, "Series Expansion" is not.
--
Lew
On 16 maio, 18:21, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> >> The first post in this thread was some guy whining that he couldn't
> >> get a job. You'll forgive me if I fail to see how that's relevant to
> >> the Great Lisp vs. Java Debate of 2009.
> gugamilare wrote:
> > This is not Lisp vs. Java debate. We are not attacking Java at all,
> > because we are not the trolls here. This is more a "Java programmers
> > that don't understand and never programmed in Lisp before rudely,
> > pointlessly and with very weak arguments attacking Lisp" debate. Give
>
> "Series" does not represent the typical Java programmer.
That is why I should have said "some" Java programmers.
>
> > You Javaers are the ones
> > treating us like if we are a bunch of amateurs who don't know how to
> > program.
>
> Now that is a very unfair generalization. Don't tar Java programmers with the
> "Series Expansion" brush. I'm a Java programmer myself, but that doesn't mean
> I agree with or endorse his behavior.
Sorry, I didn't mean to generalize, I know that are people of every
kind and everywhere that can have actual conversations, and I bet that
most people who hang out at comp.lang.java doesn't agree with what
Series Expansion and others are doing (or trying to do) here. When I
said "Javaers" I should have said "attackers of the Lisp language".
On May 16, 5:59 pm, gugamilare <··········@gmail.com> wrote:
> On 16 maio, 18:21, Lew <·····@lewscanon.com> wrote:
> > gugamilare wrote:
> > > This is not Lisp vs. Java debate. We are not attacking Java at all,
> > > because we are not the trolls here. This is more a "Java programmers
> > > that don't understand and never programmed in Lisp before rudely,
> > > pointlessly and with very weak arguments attacking Lisp" debate. Give
>
> > "Series" does not represent the typical Java programmer.
>
> That is why I should have said "some" Java programmers.
Actually, it is "Lew" that does not represent the typical Java
programmer. The typical Java programmer uses reason rather than a
froth of personal insults when he attempts to persuade others during
an argument about technical matters.
At least, I hope that's true.
> > Now that is a very unfair generalization. Don't tar Java programmers with the
> > "Series Expansion" brush. I'm a Java programmer myself, but that doesn't mean
> > I agree with or endorse his behavior.
It is quite clear that "Lew" indeed does not agree with or endorse the
behavior of actually arguing about a technical matter by making
technical, rather than personal, arguments.
> Sorry, I didn't mean to generalize, I know that are people of every
> kind and everywhere that can have actual conversations, and I bet that
> most people who hang out at comp.lang.java doesn't agree with what
> Series Expansion and others are doing (or trying to do) here.
I hope not. If comp.lang.java.programmer is now dominated by a
majority, or even a vocal enough minority, who believe that technical
debates should be resolved by outshouting and flaming the opposition
(using for instance the methods so vividly demonstrated by "Lew")
rather than by using logical arguments about the technical merits of
the alternatives proposed, then comp.lang.java.programmer has, to use
the vernacular, "jumped the shark".
> When I said "Javaers" I should have said "attackers of the Lisp
> language".
This is most unproductive use of language. If you continue to view
those of us who warn of the dangers of macros and advocate the
benefits of compile-time type checking "attackers of the Lisp
language", and some on our side continue to view those of you who
erroneously believe that Java is still the slow, difficult, and weak
language that was version 1.0 as "attackers of the Java language",
then little can be accomplished here besides futile and unproductive
flamage.
Perhaps it would be more useful to replace the word "attackers" with
"critics". I came to this debate curious about Lisp, rather than
inherently hostile to it, but found myself somewhat alarmed by things
that I realized would inevitably cause serious problems in any
realistic large-scale software-development effort. My criticism in
this area was offered with the hope that it might lead to
improvements, but unfortunately it has only led to flaming, much of it
directed at me. At the same time, if those from
comp.lang.java.programmer angered by the "attackers of the Java
language" could see past their anger, they might respond by correcting
certain outdated or simply erroneous beliefs about Java rather than
flaming those who hold them. This would lead to a much more productive
debate than we have witnessed here thus far.
On May 17, 11:33 pm, Series Expansion <·······@gmail.com> wrote:
> Perhaps it would be more useful to replace the word "attackers" with
> "critics". I came to this debate curious about Lisp, rather than
> inherently hostile to it, but found myself somewhat alarmed by things
> that I realized would inevitably cause serious problems in any
> realistic large-scale software-development effort.
Then why don't you try to learn about Lisp? If I told you that both
Lisp and Java had classes and a package system, that would by no means
justify the conclusion that they're the same. It's the differences
between Lisp's OO and Java's OO (and similar corresponding differences
in other programming features) that make the differences between the
languages.
Thus, to understand Lisp macros, packages, and CLOS, you should look
into how they're different from C macros, Java packages, and "noun-
based" object systems.
> My criticism in this area was offered with the hope that it might lead to
> improvements, but unfortunately it has only led to flaming, much of it
> directed at me.
I hope you understand why. You really have ignored many arguments and
links put forth by people, regardless of verbal slips they may have
had. You haven't even said something along the lines of "I read xyz,
but I'm still confused about how generic functions frobnobdicate their
quuxmagogs... clarifications plz?"
> At the same time, if those from
> comp.lang.java.programmer angered by the "attackers of the Java
> language" could see past their anger, they might respond by correcting
> certain outdated or simply erroneous beliefs about Java rather than
> flaming those who hold them. This would lead to a much more productive
> debate than we have witnessed here thus far.
There have been very few erroneous beliefs about Java posted here.
In fact, the only one I can think of is MINE, where I implied
(although didn't explicitly say) that I believed you couldn't have a
heterogenous list in Java. I stand corrected now.
Many of what you've interpreted as erroneous beliefs about Java were
in fact statements about the process of coding in a language that
doesn't have xyz Lisp feature, most often Lisp macros.
Specifically, the comments in response to "Java is turing-complete, so
it can do anything Lisp can" were not to contest that FACT. They were
to point out that between two turing-complete languages, one can still
have more power. It takes much less time to write a working Lisp
program (benchmarks are quite clear here), and yes, I'm talking about
full developement, including debugging. Here's a comparison:
programming in C is turing-complete, and so is writing by hand a state
diagram for a turing machine that does the same things as that C
program. But wouldn't you rather just write in C? To bastardize
Orwell: "All [languages] are [Turing-complete], but some [languages]
are more [Turing-complete] than others."
Adlai wrote:
> Specifically, the comments in response to "Java is turing-complete, so
> it can do anything Lisp can" were not to contest that FACT. They were
> to point out that between two turing-complete languages, one can still
> have more power. It takes much less time to write a working Lisp
> program (benchmarks are quite clear here), and yes, I'm talking about
> full developement, including debugging. Here's a comparison:
> programming in C is turing-complete, and so is writing by hand a state
> diagram for a turing machine that does the same things as that C
> program. But wouldn't you rather just write in C? To bastardize
> Orwell: "All [languages] are [Turing-complete], but some [languages]
> are more [Turing-complete] than others."
It is likely that answering "Series" is not going to be fruitful.
--
Lew
On May 17, 5:09 pm, Lew <·····@lewscanon.com> wrote:
> Adlai wrote:
> > Specifically, the comments in response to "Java is turing-complete, so
> > it can do anything Lisp can" were not to contest that FACT. They were
> > to point out that between two turing-complete languages, one can still
> > have more power. It takes much less time to write a working Lisp
> > program (benchmarks are quite clear here), and yes, I'm talking about
> > full developement, including debugging. Here's a comparison:
> > programming in C is turing-complete, and so is writing by hand a state
> > diagram for a turing machine that does the same things as that C
> > program. But wouldn't you rather just write in C? To bastardize
> > Orwell: "All [languages] are [Turing-complete], but some [languages]
> > are more [Turing-complete] than others."
>
> It is likely that answering "Series" is not going to be fruitful.
It is quite certain that posting personal attacks is not going to be
fruitful.
As for what Adlai wrote, it is not going to be fruitful but the reason
for this is the lack of supporting evidence or citations for the
assertions that it makes.
Adlai wrote:
> Specifically, the comments in response to "Java is turing-complete, so
> it can do anything Lisp can" were not to contest that FACT. They were
> to point out that between two turing-complete languages, one can still
> have more power. It takes much less time to write a working Lisp
> program (benchmarks are quite clear here), and yes, I'm talking about
> full developement, including debugging. Here's a comparison:
> programming in C is turing-complete, and so is writing by hand a state
> diagram for a turing machine that does the same things as that C
> program. But wouldn't you rather just write in C? To bastardize
> Orwell: "All [languages] are [Turing-complete], but some [languages]
> are more [Turing-complete] than others."
Even this:
http://en.wikipedia.org/wiki/Brainfuck
is Turing complete.
Arne
On May 17, 4:50 pm, Adlai <·········@gmail.com> wrote:
> On May 17, 11:33 pm, Series Expansion <·······@gmail.com> wrote:
> > Perhaps it would be more useful to replace the word "attackers" with
> > "critics". I came to this debate curious about Lisp, rather than
> > inherently hostile to it, but found myself somewhat alarmed by things
> > that I realized would inevitably cause serious problems in any
> > realistic large-scale software-development effort.
>
> Then why don't you try to learn about Lisp?
I have learned enough to have raised several objections that you have
failed to adequately address.
> If I told you that both Lisp and Java had classes and a package system,
> that would by no means justify the conclusion that they're the same.
This statement, though true, is irrelevant.
> Thus, to understand Lisp macros, packages, and CLOS, you should look
> into how they're different from C macros, Java packages, and "noun-
> based" object systems.
I do not need to. In the case of macros, it sufficed for me to look
into one particular similarity: that a macro invocation is replaced
with some code, inside which placeholders are replaced with copies of
the call's arguments, and then the result of the substitution is
compiled.
My concerns regarding macro use derive entirely from this one fact,
which you have not denied is true of Lisp macros.
Since my concerns do not hinge upon the macros in question having any
particular other feature than that one, and Lisp macros have that one,
my concerns are applicable to Lisp macros.
To address my concerns logically, you must actually address the
concerns themselves. Saying that "Lisp macros are different"
repeatedly does not constitute a logical argument, particularly when,
with respect to the salient feature described above, Lisp macros are
not different.
> > My criticism in this area was offered with the hope that it might lead to
> > improvements, but unfortunately it has only led to flaming, much of it
> > directed at me.
>
> I hope you understand why.
I do not. My expertise lies in areas other than group psychology.
> You really have ignored many arguments and links put forth by people
I have done so when they were irrelevant, which occurred often. If you
wish me to pay more attention to something, you should endeavor to
make it relevant and then I shall in all likelihood do so. Meanwhile,
responding with posts that are even less relevant, such as ones full
of insults, shall tend have the opposite effect.
> You haven't even said something along the lines of "I read xyz,
> but I'm still confused about how generic functions frobnobdicate their
> quuxmagogs... clarifications plz?"
Generic functions are irrelevant to the matter at hand, namely,
macros. Therefore it is unsurprising that I have not said much about
them.
> > At the same time, if those from
> > comp.lang.java.programmer angered by the "attackers of the Java
> > language" could see past their anger, they might respond by correcting
> > certain outdated or simply erroneous beliefs about Java rather than
> > flaming those who hold them. This would lead to a much more productive
> > debate than we have witnessed here thus far.
>
> There have been very few erroneous beliefs about Java posted here.
I counted at least six. However, there were numerous repetitions of at
least some of them.
> In fact, the only one I can think of is MINE, where I implied
> (although didn't explicitly say) that I believed you couldn't have a
> heterogenous list in Java. I stand corrected now.
That was one of the six, and it occurred a few additional times,
though perhaps not from you. The others, as I recall, were:
1. assertions that Java is slow;
2. assertions that Java programmers are, on average, incompetent;
3. assertions that Java is bloated;
4. assertions that Java code looks like vomitus; and
5. assertions that Java lacks ways to bypass type-checking in
contexts other than heterogeneous lists.
Of these, only the third is remotely plausible. The large size of the
standard library is an asset, not a liability. The verbosity of the
code is occasionally unfortunate, but more often contributes to that
code being self-documenting. Finally, Java's propensity to consume a
lot of memory at runtime causes scaling problems at the low end of
application size, but is an unavoidable requirement of a garbage-
collected system in order to be time-efficient, and this tradeoff is
therefore equally applicable to Lisp.
> Many of what you've interpreted as erroneous beliefs about Java were
> in fact statements about the process of coding in a language that
> doesn't have xyz Lisp feature, most often Lisp macros.
Those statements were proven to be incorrect.
> Specifically, the comments in response to "Java is turing-complete, so
> it can do anything Lisp can" were not to contest that FACT.
As I recall, it was the Lisp side that initially raised the issue of
Turing-completeness, with an insinuation that either Java was not, or
Lisp systems contained an oracle.
> They were to point out that between two turing-complete languages,
> one can still have more power.
Power is not the sole measure of a language. Indeed, it often trades
off with readability and modularity. Both of the latter are important,
but especially so the larger the development team, as has been pointed
out by Seamus MacRae. Moreover, modularity makes fault isolation far
easier to perform, and reduces the defect rate to begin with. Well-
specified interfaces between components such as classes will act as
shock-absorbers, greatly reducing the tendency for changes in one part
of the code-base to have unintended consequences in others. For this
to occur, encapsulation is a must, and power and encapsulation are in
direct opposition.
The conflict between power and readability arises somewhat
differently, although well-specified interfaces between well-defined
components can improve readability. More significantly, having a large
number of different language constructs serving essentially the same
purpose increases the amount of entropy in the source code without a
corresponding increase in the amount of meaningful program semantics,
as the particular choice of alternative constructs at each site begins
to require several bits of information to specify. This extraneous
entropy represents noise, and readability always suffers as the noise-
to-signal ratio rises.
A recent post by Seamus MacRae remarks upon this in another way, with
an unflattering comparison to perl, whose numerous concise ways of
doing things results in code that resembles the consequences of a
catastrophic keyboard failure and requires extreme expertise to
interpret. The end result of excessive proliferation of language
constructs thus tends to be unmaintainable code.
> It takes much less time to write a working Lisp program
This is an excellent example of an assertion unsupported by evidence,
of which you have made so many over the past few days.
Furthermore, it places all of its emphasis upon the initial creation
of the program, and none whatsoever upon the subsequent maintenance of
that code, or upon its reusability or integrability with other code in
the future.
> (benchmarks are quite clear here)
This, of course, does not constitute a credible citation. You would
not get away with this at Wikipedia.
On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
> On May 17, 4:50 pm, Adlai <·········@gmail.com> wrote:
>
> > On May 17, 11:33 pm, Series Expansion <·······@gmail.com> wrote:
> > > Perhaps it would be more useful to replace the word "attackers" with
> > > "critics". I came to this debate curious about Lisp, rather than
> > > inherently hostile to it, but found myself somewhat alarmed by things
> > > that I realized would inevitably cause serious problems in any
> > > realistic large-scale software-development effort.
>
> > Then why don't you try to learn about Lisp?
>
> I have learned enough to have raised several objections that you have
> failed to adequately address.
>
> I do not need to. In the case of macros, it sufficed for me to look
> into one particular similarity: that a macro invocation is replaced
> with some code, inside which placeholders are replaced with copies of
> the call's arguments, and then the result of the substitution is
> compiled.
>
> My concerns regarding macro use derive entirely from this one fact,
> which you have not denied is true of Lisp macros.
>
> Since my concerns do not hinge upon the macros in question having any
> particular other feature than that one, and Lisp macros have that one,
> my concerns are applicable to Lisp macros.
>
> To address my concerns logically, you must actually address the
> concerns themselves. Saying that "Lisp macros are different"
> repeatedly does not constitute a logical argument, particularly when,
> with respect to the salient feature described above, Lisp macros are
> not different.
You've completely ignored GENSYMS. Lisp macros execute code which
instructs how to produce the expansion code, and thus are able to
avoid variable capture, multiple evaluation, and all the other
problems you mentioned.
> > You really have ignored many arguments and links put forth by people
>
> I have done so when they were irrelevant, which occurred often. If you
> wish me to pay more attention to something, you should endeavor to
> make it relevant and then I shall in all likelihood do so. Meanwhile,
> responding with posts that are even less relevant, such as ones full
> of insults, shall tend have the opposite effect.
As far as I can tell, you're replying to every single post. It would
be a better use of everybody's time if you just ignored the irrelevant
posts, and only answered the relevant ones.
Also, it does seem to me that you haven't put much effort into
understanding the Lisp package system or CLOS. These are very
different in Lisp from how they are in other languages, so it helps to
have a familiarity with them before you denounce them. The package
system, for one thing, as has been said before, is just a package of
SYMBOLS. That's all. Packages don't store code within them, just names
of stuff.
>
> > You haven't even said something along the lines of "I read xyz,
> > but I'm still confused about how generic functions frobnobdicate their
> > quuxmagogs... clarifications plz?"
>
> Generic functions are irrelevant to the matter at hand, namely,
> macros. Therefore it is unsurprising that I have not said much about
> them.
>
People have mentioned gensym, which is completely relevant to macros,
and if I recall correctly, you're only replied once, saying that
gensyms are impossible -- yet they're all over "On Lisp":
http://paulgraham.com/onlisptext.html
> That was one of the six [false beliefs about Java], and it occurred a few additional times,
> though perhaps not from you. The others, as I recall, were: [...]
Since I see that you dislike it when I try to apologise for other
people's potential miscommunications, I won't do so.
> > It takes much less time to write a working Lisp program
>
> This is an excellent example of an assertion unsupported by evidence,
> of which you have made so many over the past few days.
I cite a page on Peter Norvig's site: http://www.norvig.com/java-lisp.html
He talks about a study done in a few different languages. One of the
results was that Lisp code for the test program was produced within
hours, while many of the submissions in other languages took days.
- Adlai
On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
> On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
> > To address my concerns logically, you must actually address the
> > concerns themselves. Saying that "Lisp macros are different"
> > repeatedly does not constitute a logical argument, particularly when,
> > with respect to the salient feature described above, Lisp macros are
> > not different.
>
> You've completely ignored GENSYMS.
I have not. What you described affected the storage allocation of an
object referenced by a variable. This has no impact on collisions
among the names of variables when the compiler parses the code that
has been transformed previously by the macro.
> Lisp macros execute code which instructs how to produce the
> expansion code
True.
> and thus are able to avoid variable
> capture, multiple evaluation, and all the other
> problems you mentioned.
False. That the macros can execute code does not help much here. A
macro's output is some function of the macro's arguments, but no
function of its arguments can compute a safe variable name. Suppose to
the contrary that it could; that, with particular arguments, the macro
decided on "foo" as an internal variable name to use. Now place a call
to that macro in a function that has a local variable named "foo" and
use the same exact arguments in the call, and you will have a variable
collision. The same could be done for any arguments and any variable
name computed as "safe" given those arguments.
Thus we have arrived at a contradiction. Your hypothesis that a macro
exists that can do as you have described has been disproven.
> > > You really have ignored many arguments and links put forth by people
>
> > I have done so when they were irrelevant, which occurred often. If you
> > wish me to pay more attention to something, you should endeavor to
> > make it relevant and then I shall in all likelihood do so. Meanwhile,
> > responding with posts that are even less relevant, such as ones full
> > of insults, shall tend have the opposite effect.
>
> As far as I can tell, you're replying to every single post.
It is what I have read, not what I have replied to, that you were
complaining about.
> It would be a better use of everybody's time if you just ignored the
> irrelevant posts, and only answered the relevant ones.
The problem with that is that insulting posts, while irrelevant to
Lisp macros, are not irrelevant to me personally.
> Also, it does seem to me that you haven't put much effort into
> understanding the Lisp package system or CLOS.
I have put precisely as much effort into doing so as you have put into
describing them, since I have read what you have written about them.
If you have not done a very good job of explaining them in terms a lay
person would understand, then that is hardly a basis for concluding
something negative about me.
> The package system, for one thing, as has been said before, is just a
> package of SYMBOLS. That's all. Packages don't store code within them,
> just names of stuff.
Nobody asserted that they stored actual code. But they organize it,
indirectly by organizing the names of parts of the code. Furthermore,
it was indicated elsewhere that they distinguish names of functions,
names of classes, names of variables, and the like from one another,
in that a class and a variable, say, can have the same name and be in
the same package.
> > > You haven't even said something along the lines of "I read xyz,
> > > but I'm still confused about how generic functions frobnobdicate their
> > > quuxmagogs... clarifications plz?"
>
> > Generic functions are irrelevant to the matter at hand, namely,
> > macros. Therefore it is unsurprising that I have not said much about
> > them.
>
> People have mentioned gensym, which is completely relevant to macros,
But, as I have demonstrated, it is irrelevant to the capture problem.
Unless of course you have misdescribed them, in which case they might
be relevant without that having been made apparent to me.
> and if I recall correctly, you're only replied once, saying that
> gensyms are impossible
Not impossible, irrelevant. I have explained why a macro cannot
compute from its arguments alone a guaranteed-safe variable name. You
responded by describing something apparently to do with run-time
memory allocation. That is not a debate -- it is a farce.
> > > It takes much less time to write a working Lisp program
>
> > This is an excellent example of an assertion unsupported by evidence,
> > of which you have made so many over the past few days.
>
> I cite a page on Peter Norvig's site:http://www.norvig.com/java-lisp.html
> He talks about a study done in a few different languages. One of the
> results was that Lisp code for the test program was produced within
> hours, while many of the submissions in other languages took days.
What was the nature of the test program? This kind of thing can very
easily be biased, even inadvertently, by the selection of a test
program suited to a particular language's strengths. For example, the
wget source code is lengthy and an equivalent tool can be implemented
in Java in a handful of lines of code, because the Java standard
library includes HTTP transport and URL handling. This does not prove
Java superior to C. Nor does the relative ease with which one could
code an OS kernel in C compared to Java prove C superior. A string-
manipulation and pattern-matching heavy test program would produce the
ranking perl, ruby, Java, C. Device drivers, C and C++ ahead of
anything else. Heavy math work, possibly C, C++, or Java, or a special-
purpose language like that contained in Mathematica, ahead of most.
Anecdotes prove nothing and studies that could easily have been
(unintentionally or otherwise) biased prove little more. A broad study
with a large sample size and a large variety of "test
programs" (actually, sets of requirements, with freedom of
implementation) would be needed before one could possess data
conclusive enough to pronounce one language faster or otherwise
superior to another, except for specific categories of programming
problem or specific problem domains.
On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
>
> > On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
[snip]
> > You've completely ignored GENSYMS.
>
> I have not. What you described affected the storage allocation of an
> object referenced by a variable. This has no impact on collisions
> among the names of variables when the compiler parses the code that
> has been transformed previously by the macro.
GENSYM generates a symbol that is not interned in any package; in
fact, any such symbol could not be re-referenced by simply reading
it's name, because each time a symbol name beginning with the
characters #: is read in (for example, the symbols #:cl and #:foo were
used earlier in this discussion), the reader creates a new symbol.
Thus, you have to have the original reference to these symbols from
their creation to access them.
> Thus we have arrived at a contradiction. Your hypothesis that a macro
> exists that can do as you have described has been disproven.
Addressed by the first paragraph in this post.
>
> > > > You really have ignored many arguments and links put forth by people
>
> > > I have done so when they were irrelevant, which occurred often. If you
> > > wish me to pay more attention to something, you should endeavor to
> > > make it relevant and then I shall in all likelihood do so.
I've tried to explain here again, why GENSYM creates symbols that
enable capture-free macros.
> > Also, it does seem to me that you haven't put much effort into
> > understanding the Lisp package system or CLOS.
>
> I have put precisely as much effort into doing so as you have put into
> describing them, since I have read what you have written about them.
> If you have not done a very good job of explaining them in terms a lay
> person would understand, then that is hardly a basis for concluding
> something negative about me.
I've tried to explain them in the same terms that PCL, Successful
Lisp, or On Lisp use, since those are the resources that have taught
me about these concepts so far.
>
> > The package system, for one thing, as has been said before, is just a
> > package of SYMBOLS. That's all. Packages don't store code within them,
> > just names of stuff.
>
> Nobody asserted that they stored actual code. But they organize it,
> indirectly by organizing the names of parts of the code. Furthermore,
> it was indicated elsewhere that they distinguish names of functions,
> names of classes, names of variables, and the like from one another,
> in that a class and a variable, say, can have the same name and be in
> the same package.
/Packages/ don't do that. Saying that Lisp has separate function and
variable namespaces is a bit misleading, because all symbols are equal
in the eyes of packages, the same way that the word "bat" has one
entry in the dictionary, but multiple meanings as different parts of
speech. A person /reading/ a text determines which part of speech to
use to understand the word.
> > > > You haven't even said something along the lines of "I read xyz,
> > > > but I'm still confused about how generic functions frobnobdicate their
> > > > quuxmagogs... clarifications plz?"
>
> > > Generic functions are irrelevant to the matter at hand, namely,
> > > macros. Therefore it is unsurprising that I have not said much about
> > > them.
>
> > People have mentioned gensym, which is completely relevant to macros,
>
> But, as I have demonstrated, it is irrelevant to the capture problem.
> Unless of course you have misdescribed them, in which case they might
> be relevant without that having been made apparent to me.
Maybe I didn't describe it clearly enough. I've tried again. Remember,
a symbol that is not in any package cannot be referred to by its name.
If symbols from GENSYM got interned, then yes, everything you said
about macros would be true. However, because they are not interned,
it's impossible to reference them without the return-value of the
GENSYM function. In a sense, GENSYM is Lisp's version of truly
"private" stuff -- usually variables, in macro code.
> > I cite a page on Peter Norvig's site:http://www.norvig.com/java-lisp.html
> > He talks about a study done in a few different languages. One of the
> > results was that Lisp code for the test program was produced within
> > hours, while many of the submissions in other languages took days.
>
> What was the nature of the test program? This kind of thing can very
> easily be biased, even inadvertently, by the selection of a test
> program suited to a particular language's strengths.
Did you read the page that I linked to? It explained the test program
there. Although it wasn't a huge project, the results did seem to have
some statistical significance. Another example I'd cite, which isn't
as specific, is Viaweb's massive success. Paul Graham, one of Viaweb's
founders, attributes much of this success to the productivity boost
experienced by Lisp programmers.
- Adlai
Adlai <·········@gmail.com> writes:
> On May 23, 11:54�am, Series Expansion <·······@gmail.com> wrote:
>> On May 20, 1:18�pm, Adlai <·········@gmail.com> wrote:
>>
>> > On May 20, 6:03�pm, Series Expansion <·······@gmail.com> wrote:
> [snip]
>> > You've completely ignored GENSYMS.
>>
>> I have not. What you described affected the storage allocation of an
>> object referenced by a variable. This has no impact on collisions
>> among the names of variables when the compiler parses the code that
>> has been transformed previously by the macro.
>
> GENSYM generates a symbol that is not interned in any package; in
This has already been repeated 5 times in this thread. The guy won't
learn, no matter what you may write on usenet. The only way left is
to hit him on the head. Are you prepared to buy a rule and pay the
flight fare to go see him and do the needed pedagogical actions? If
not, PLEASE, just leave it, stop posting in this thread.
--
__Pascal Bourguignon__
On May 23, 2:20 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Adlai <·········@gmail.com> writes:
> > On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
> >> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
>
> >> > On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
> > [snip]
> >> > You've completely ignored GENSYMS.
>
> >> I have not. What you described affected the storage allocation of an
> >> object referenced by a variable. This has no impact on collisions
> >> among the names of variables when the compiler parses the code that
> >> has been transformed previously by the macro.
>
> > GENSYM generates a symbol that is not interned in any package; in
>
> This has already been repeated 5 times in this thread. The guy won't
> learn, no matter what you may write on usenet.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Pascal.
I have a specific and logical objection to Adlai's claim that his
gensyms evade the variable-capture problem; at best, they move it from
the variable holding an argument's evaluation to the variable holding
a reference to the gensym.
> The only way left is to hit him on the head. Are you prepared to
> buy a rule and pay the flight fare to go see him and do the needed
> pedagogical actions?
If I'd considered this incitement to violence to pose a credible
threat, I would now be notifying the police in your area of residence.
lors wrote:
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>> Adlai <·········@gmail.com> writes:
>>> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
>>>> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
>>>>> On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
>>> [snip]
>>>>> You've completely ignored GENSYMS.
>>>> I have not. What you described affected the storage allocation of an
>>>> object referenced by a variable. This has no impact on collisions
>>>> among the names of variables when the compiler parses the code that
>>>> has been transformed previously by the macro.
>>> GENSYM generates a symbol that is not interned in any package; in
>> This has already been repeated 5 times in this thread. The guy won't
>> learn, no matter what you may write on usenet. The only way left is
>> to hit him on the head. Are you prepared to buy a rule and pay the
>> flight fare to go see him and do the needed pedagogical actions? If
>> not, PLEASE, just leave it, stop posting in this thread.
>>
> Be fine if "stop posting" actually did have any effect as a
> function. Hands over ears has never worked with this type of
> asshole. Yo got it very right with
> /qThe only way left is
> to hit him on the head
> /q
> As "Seamus Macrae" the asshole is invading the free news
> server froup.. a service for us all supplied through the
> goodwill of NNTP admins.
> I am looking for history on this guy before the 15th of June
> 2009. IT was not "born" yesterday.
> I can be contacted here:
> lors.washin at yahoo.com
>
> fup set to comp.lang.lisp
>
> For whatever assistance is provided, thanks.
Google for:
Paul Derbyshire
Twisted
Arne
Arne Vajh�j wrote:
> lors wrote:
>> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>>> Adlai <·········@gmail.com> writes:
>>>> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
>>>>> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
>>>>>> On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
>>>> [snip]
>>>>>> You've completely ignored GENSYMS.
>>>>> I have not. What you described affected the storage allocation of an
>>>>> object referenced by a variable. This has no impact on collisions
>>>>> among the names of variables when the compiler parses the code that
>>>>> has been transformed previously by the macro.
>>>> GENSYM generates a symbol that is not interned in any package; in
>>> This has already been repeated 5 times in this thread. The guy won't
>>> learn, no matter what you may write on usenet. The only way left is
>>> to hit him on the head. Are you prepared to buy a rule and pay the
>>> flight fare to go see him and do the needed pedagogical actions? If
>>> not, PLEASE, just leave it, stop posting in this thread.
>>>
>> Be fine if "stop posting" actually did have any effect as a
>> function. Hands over ears has never worked with this type of
>> asshole. Yo got it very right with /qThe only way left is
>> to hit him on the head
>> /q
>> As "Seamus Macrae" the asshole is invading the free news
>> server froup.. a service for us all supplied through the
>> goodwill of NNTP admins.
>> I am looking for history on this guy before the 15th of June
>> 2009. IT was not "born" yesterday.
>> I can be contacted here:
>> lors.washin at yahoo.com
>>
>> fup set to comp.lang.lisp
>>
>> For whatever assistance is provided, thanks.
>
> Google for:
> Paul Derbyshire
> Twisted
Neither of those is my name, or any name I have ever used.
My name is Seamus MacRae.
Therefore, your post is irrelevant.
lors wrote:
> Arne Vajh�j <····@vajhoej.dk> wrote:
>
>> lors wrote:
>>> As "Seamus Macrae" the asshole is invading the free news
>>> server froup.
I am not an asshole and I am invading nothing. That newsgroup was
invaded recently by a bunch of posters from alt.usenet.kooks spewing
enormous amounts of OT blather. We've seen the like before, with meowers
and invasions of newsgroups by alt.tasteless regulars (and the latter
have, in fact, also recently invaded afn).
F'ups set somewhere more appropriate.
>>> I am looking for history on this guy before the 15th of June
>>> 2009. IT was not "born" yesterday.
I am a he, not an it.
>>> fup set to comp.lang.lisp
Your insulting and flamey post is not on topic there either.
>>> For whatever assistance is provided, thanks.
My arms aren't long enough to reach your modem and unplug it, but you're
welcome anyway.
>> Google for:
>> Paul Derbyshire
>
> Man.. you have to be fskn kidding me, right?
> THE Paul Derbyshire!!!
I've never heard of him. What's his claim to fame?
>> Twisted
>
> Author posting ID.. "twisted" is just too much:-D
I have never used such a posting ID.
> Thanks Arne, you're a champ.. I think:-)
He is not.
On Jul 12, 9:57 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> lors wrote:
> > ····@informatimago.com (Pascal J. Bourguignon) wrote:
> >> Adlai <·········@gmail.com> writes:
> >>> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
> >>>> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
> >>>>> On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
> >>> [snip]
> >>>>> You've completely ignored GENSYMS.
> >>>> I have not. What you described affected the storage allocation of an
> >>>> object referenced by a variable. This has no impact on collisions
> >>>> among the names of variables when the compiler parses the code that
> >>>> has been transformed previously by the macro.
> >>> GENSYM generates a symbol that is not interned in any package; in
> >> This has already been repeated 5 times in this thread. The guy won't
> >> learn, no matter what you may write on usenet.
It is certainly true that no-one can be made to learn through
browbeating and hostility.
I, in particular, am impervious to anything that isn't logic. Call me
names, rail at me, pull out my toenails, and I will not "learn"
anything through those methods except maybe that you are what is often
termed, in the vernacular, an "asshole".
> >> The only way left is to hit him on the head.
Threats of physical violence will not persuade me either. Argument by
force is as much a logical fallacy as ad hominem or any of the others
you have employed here lately.
> > Be fine if "stop posting" actually did have any effect as a
> > function. Hands over ears has never worked with this type of
> > asshole.
Pardon me, but if anyone here is an "asshole" it is yourself. I have
been polite throughout this exchange, even when others have been
somewhat less so towards me.
> > As "Seamus Macrae" the asshole is invading the free news
> > server froup.
I have no clue what this is referring to, other than that it clearly
has nothing whatsoever to do with me.
> Google for:
> Paul Derbyshire
> Twisted
None of this appears to be relevant.
On Jul 12, 10:21 pm, lors <······@dev.null> wrote:
> Arne Vajhøj <····@vajhoej.dk> wrote:
> >lors wrote:
> >> ····@informatimago.com (Pascal J. Bourguignon) wrote:
> >>> Adlai <·········@gmail.com> writes:
> >>>> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
> >>>>> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
> >>>>>> On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
> >>>> [snip]
> >>>>>> You've completely ignored GENSYMS.
> >>>>> I have not. What you described affected the storage allocation of an
> >>>>> object referenced by a variable. This has no impact on collisions
> >>>>> among the names of variables when the compiler parses the code that
> >>>>> has been transformed previously by the macro.
> >>>> GENSYM generates a symbol that is not interned in any package; in
> >>> This has already been repeated 5 times in this thread. The guy won't
> >>> learn, no matter what you may write on usenet.
It is certainly true that no-one can be made to learn through
browbeating and hostility.
I, in particular, am impervious to anything that isn't logic. Call me
names, rail at me, pull out my toenails, and I will not "learn"
anything through those methods except maybe that you are what is often
termed, in the vernacular, an "asshole".
> >>> The only way left is to hit him on the head.
Threats of physical violence will not persuade me either. Argument by
force is as much a logical fallacy as ad hominem or any of the others
you have employed here lately.
> >> Be fine if "stop posting" actually did have any effect as a
> >> function. Hands over ears has never worked with this type of
> >> asshole.
Pardon me, but if anyone here is an "asshole" it is yourself. I have
been polite throughout this exchange, even when others have been
somewhat less so towards me.
> >> As "Seamus Macrae" the asshole is invading the free news
> >> server froup.
I have no clue what this is referring to, other than that it clearly
has nothing whatsoever to do with me.
> >Google for:
> > Paul Derbyshire
None of this appears to be relevant.
> Man.. you have to be fskn kidding me, right?
> THE Paul Derbyshire!!!
Who is that, someone famous? I have never heard of him.
On Jul 12, 10:39 pm, lors <······@dev.null> wrote:
> lors <······@dev.null> wrote:
> >Arne Vajhøj <····@vajhoej.dk> wrote:
> >>lors wrote:
> >>> ····@informatimago.com (Pascal J. Bourguignon) wrote:
> >>>> Adlai <·········@gmail.com> writes:
> >>>>> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
> >>>>>> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
> >>>>>>> On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
> >>>>> [snip]
> >>>>>>> You've completely ignored GENSYMS.
> >>>>>> I have not. What you described affected the storage allocation of an
> >>>>>> object referenced by a variable. This has no impact on collisions
> >>>>>> among the names of variables when the compiler parses the code that
> >>>>>> has been transformed previously by the macro.
> >>>>> GENSYM generates a symbol that is not interned in any package; in
> >>>> This has already been repeated 5 times in this thread. The guy won't
> >>>> learn, no matter what you may write on usenet.
It is certainly true that no-one can be made to learn through
browbeating and hostility.
I, in particular, am impervious to anything that isn't logic. Call me
names, rail at me, pull out my toenails, and I will not "learn"
anything through those methods except maybe that you are what is often
termed, in the vernacular, an "asshole".
> >>>> The only way left is to hit him on the head.
Threats of physical violence will not persuade me either. Argument by
force is as much a logical fallacy as ad hominem or any of the others
you have employed here lately.
> >>> Be fine if "stop posting" actually did have any effect as a
> >>> function. Hands over ears has never worked with this type of
> >>> asshole.
Pardon me, but if anyone here is an "asshole" it is yourself. I have
been polite throughout this exchange, even when others have been
somewhat less so towards me.
> >>> As "Seamus Macrae" the asshole is invading the free news
> >>> server froup.
I have no clue what this is referring to, other than that it clearly
has nothing whatsoever to do with me.
> >>Google for:
> >> Paul Derbyshire
None of this appears to be relevant.
> >Man.. you have to be fskn kidding me, right?
> >THE Paul Derbyshire!!!
Who is he, someone famous? I've never heard of him.
> Ole Experience/MacRAE there is wriggling away
> testing the rod, may he bite deep!
This appears to be irrational. It does not parse.
> I am out of your hair when I have information.
> None of this has any place in programming
> froups.
That much is certain.
> there are "special" froups to deal with the likes of Experience/MacRAE.
First of all, we are two separate people and I basically don't know
MacRae.
Secondly, the above looks suspiciously like some sort of a threat,
which would constitute exceedingly rude behavior.
And, of course, none of what you have written here recently is any
kind of convincing, logical argument in favor of Lisp.
lors wrote:
> As "Seamus Macrae" the asshole is invading the free news
> server froup
I am not an asshole and I am invading nothing. That newsgroup was
invaded recently by a bunch of posters from alt.usenet.kooks spewing
enormous amounts of OT blather. We've seen the like before, with meowers
and invasions of newsgroups by alt.tasteless regulars (and the latter
have, in fact, also recently invaded afn).
> I am looking for history on this guy before the 15th of June
> 2009. IT was not "born" yesterday.
I am a he, not an it.
> fup set to comp.lang.lisp
Your insulting and flamey post is not on topic there either.
F'ups set somewhere more appropriate.
> For whatever assistance is provided, thanks.
My arms aren't long enough to reach your modem and unplug it, but you're
welcome anyway.
lors wrote:
> <············@news.eternal-september.org>
>> I am not an asshole and I am invading nothing.
>
> Fuck off troll.
How exceptionally rude!
I am, however, not a troll.
lors <······@dev.null> writes:
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>
>>Adlai <·········@gmail.com> writes:
>>
>>> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
>>>> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
>>>>
>>>> > On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
>>> [snip]
>>>> > You've completely ignored GENSYMS.
>>>>
>>>> I have not. What you described affected the storage allocation of an
>>>> object referenced by a variable. This has no impact on collisions
>>>> among the names of variables when the compiler parses the code that
>>>> has been transformed previously by the macro.
>>>
>>> GENSYM generates a symbol that is not interned in any package; in
>>
>>This has already been repeated 5 times in this thread. The guy won't
>>learn, no matter what you may write on usenet. The only way left is
>>to hit him on the head. Are you prepared to buy a rule and pay the
>>flight fare to go see him and do the needed pedagogical actions? If
>>not, PLEASE, just leave it, stop posting in this thread.
>>
> Be fine if "stop posting" actually did have any effect as a
> function. Hands over ears has never worked with this type of
> asshole. Yo got it very right with
> /qThe only way left is
> to hit him on the head
> /q
What's he going to do, start replying to himself? Maybe if people
filtered him instead of arguing with him, he'd run out of posts to play
off of and go away. There's a reason they say not to feed trolls.
On Jul 13, 4:16 am, Paul Donnelly <·············@sbcglobal.net> wrote:
> lors <······@dev.null> writes:
> > ····@informatimago.com (Pascal J. Bourguignon) wrote:
>
> >>Adlai <·········@gmail.com> writes:
>
> >>> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
> >>>> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
>
> >>>> > On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
> >>> [snip]
> >>>> > You've completely ignored GENSYMS.
>
> >>>> I have not. What you described affected the storage allocation of an
> >>>> object referenced by a variable. This has no impact on collisions
> >>>> among the names of variables when the compiler parses the code that
> >>>> has been transformed previously by the macro.
>
> >>> GENSYM generates a symbol that is not interned in any package; in
>
> >>This has already been repeated 5 times in this thread. The guy won't
> >>learn, no matter what you may write on usenet.
It is certainly true that no-one can be made to learn through
browbeating and hostility.
I, in particular, am impervious to anything that isn't logic. Call me
names, rail at me, pull out my toenails, and I will not "learn"
anything through those methods except maybe that you are what is often
termed, in the vernacular, an "asshole".
> >>The only way left is to hit him on the head.
Threats of physical violence will not persuade me either. Argument by
force is as much a logical fallacy as ad hominem or any of the others
you have employed here lately.
> > Be fine if "stop posting" actually did have any effect as a
> > function. Hands over ears has never worked with this type of
> > asshole.
Pardon me, but if anyone here is an "asshole" it is yourself. I have
been polite throughout this exchange, even when others have been
somewhat less so towards me.
> What's he going to do, start replying to himself? Maybe if people
> filtered him instead of arguing with him, he'd run out of posts to play
> off of and go away. There's a reason they say not to feed trolls.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul.
On Jul 13, 12:21 am, lors <·······@bit.bin.invalid> wrote:
> I said earlier:>> /qThe only way left is
> >> to hit him on the head
> >> /q
It is probably against the law where you live to utter threats of
bodily harm.
> >You replied: What's he going to do, start replying to himself?
>
> Do you need more example?
There are no examples of me replying to myself.
> >Maybe if people
> >filtered him instead of arguing with him, he'd run out of posts to play
> >off of and go away.
>
> Your Maybe and up you two Definitely Nots.
> My bet says the SE/SM troll is no different
> to any other historical truant. He will not "go away".
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "lors" and Paul.
> No argument here on "place on ignore".
> However it only works when you corral the bastard
> and hobble him. Doing that requires work.
> That work is what I do.
> SE/SM has earnt himself a place in the
> "Work List for 2009".
That reads like a threat to me.
> All I use is the information.
> This guy has origins, history, a sickness he cannot hide.
I am perfectly healthy.
lors <·······@bit.bin.invalid> writes:
> I said earlier:
>>> /qThe only way left is
>>> to hit him on the head
>>> /q
>>
> You replied:
>>What's he going to do, start replying to himself?
>>
> Do you need more example?
I've had a 100% success rate avoiding trolls with this technique. Do I
need more examples?
>>Maybe if people filtered him instead of arguing with him, he'd run out
>>of posts to play off of and go away.
>>
> Your Maybe and up you two Definitely Nots.
> My bet says the SE/SM troll is no different
> to any other historical truant. He will not "go away".
The funny thing is that I haven't seen any posts from him in a month. If
the rest of the board managed to block him as well, he'd be as away as I
could ask, since the only way I know he's still here is when I see
someone talking to a brick wall.
> The guy may be technically bereft in Windows usage
> around Usenet but he has certainly displayed an ability
> to have you guys running in a loop.
> Check my headers for where he is headed, given the tools
> and information.
>
>>There's a reason they say not to feed trolls.
>>
> True, shunning being at the core of it.
Shunning? How about not taking the bait?
> How's that working for you in Church.. where the
> practice has its origins?
> All the devils locked out?
No devils here.
> No argument here on "place on ignore".
> However it only works when you corral the bastard
> and hobble him. Doing that requires work.
It works pretty well, except when people, for reasons apparently no more
sane than the troll's, continuously make futile attempts to argue with
him and point out what a troll he is. As if the former weren't uselessly
hopeless, and the latter weren't uselessly obvious. I mean, am I being
metatrolled here? Ignoring him is all anyone needs to do.
On Jul 13, 5:01 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> lors <·······@bit.bin.invalid> writes:
> > I said earlier:
> >>> /qThe only way left is
> >>> to hit him on the head
> >>> /q
A threat.
> >>You replied:
> >>What's he going to do, start replying to himself?
>
> > Do you need more example?
>
> I've had a 100% success rate avoiding trolls with this technique. Do I
> need more examples?
These tiresome personal attacks do not constitute rational arguments
in favor of Lisp or Java, Paul and "lors".
> The funny thing is that I haven't seen any posts from him in a month. If
> the rest of the board managed to block him as well, he'd be as away as I
> could ask, since the only way I know he's still here is when I see
> someone talking to a brick wall.
These tiresome personal attacks do not constitute rational arguments
in favor of Lisp or Java, Paul.
> > No argument here on "place on ignore".
> > However it only works when you corral the bastard
> > and hobble him. Doing that requires work.
>
> It works pretty well, except when people, for reasons apparently no more
> sane than the troll's, continuously make futile attempts to argue with
> him and point out what a troll he is.
These tiresome personal attacks do not constitute rational arguments
in favor of Lisp or Java, Paul and "lors".
> I mean, am I being metatrolled here?
The probability approaches 100%.
On Jul 13, 5:27 pm, lors <······@dev.null> wrote:
> Paul Donnelly <·············@sbcglobal.net> wrote:
> >lors <·······@bit.bin.invalid> writes:
> >> I said earlier:
> >>>> /qThe only way left is
> >>>> to hit him on the head
> >>>> /q
A threat.
> >>>You replied:
> >>>What's he going to do, start replying to himself?
>
> >> Do you need more example?
>
> >I've had a 100% success rate avoiding trolls with this technique.
>
> Then you might write up a RFC on the topic?
These tiresome personal attacks do not constitute rational arguments
in favor of Lisp or Java, "lors" and Paul.
> >> No argument here on "place on ignore".
> >> However it only works when you corral the bastard
> >> and hobble him. Doing that requires work.
>
> >It works pretty well, except when people, for reasons apparently no more
> >sane than the troll's, continuously make futile attempts to argue with
> >him and point out what a troll he is. As if the former weren't uselessly
> >hopeless, and the latter weren't uselessly obvious.
These tiresome personal attacks do not constitute rational arguments
in favor of Lisp or Java, "lors" and Paul.
> >I mean, am I being metatrolled here?
The probability approaches 100%.
> I do not believe you have not seen any posts from him in a
> month. I do believe you have not recognized the posts and I
> would increase the ante to say a search would find you
> replying to him.. without you knowing the OP was him.
That would be incorrect. I have not used any other name but this one
to participate here.
> Whatever, I am not looking to argue the point, I am looking
> for information and you are helping, thank you for that.
I have gathered from remarks in several of your recent posts that you
are, in fact, looking to commit an invasion of privacy followed by an
unstated but probably-illegal harassment campaign of unspecified exact
nature.
I recommend that you not attempt such a thing. I will not hesitate to
seek the assistance of law enforcement in the event that I am
subjected to any form of privacy invasion, stalking, violence,
threatened violence, or similarly line-crossing harassment. You would
likely face fines and probation as a consequence of perpetrating any
such acts, and, quite possibly, jail time. You would not find the
experience pleasant.
lors <······@dev.null> writes:
> Paul Donnelly <·············@sbcglobal.net> wrote:
>
>>lors <·······@bit.bin.invalid> writes:
>>
>>> I said earlier:
>>>>> /qThe only way left is
>>>>> to hit him on the head
>>>>> /q
>>>>
>>> You replied:
>>>>What's he going to do, start replying to himself?
>>>>
>>> Do you need more example?
>>
>>I've had a 100% success rate avoiding trolls with this technique.
>>
> Then you might write up a RFC on the topic?
>
>>Do I need more examples?
>>
> Did you check the headers of my post before you wrote that?
No, because the point was that for anyone uninterested in reading a
known troll's posts, filtering them is trivial. Unless your headers
indicate that this is nowhere near effective, I don't see what they
could have to do with it.
>>>>Maybe if people filtered him instead of arguing with him, he'd run out
>>>>of posts to play off of and go away.
>>>>
>>> Your Maybe and up you two Definitely Nots.
>>> My bet says the SE/SM troll is no different
>>> to any other historical truant. He will not "go away".
>>
>>The funny thing is that I haven't seen any posts from him in a month. If
>>the rest of the board managed to block him as well, he'd be as away as I
>>could ask, since the only way I know he's still here is when I see
>>someone talking to a brick wall.
>>
>>> The guy may be technically bereft in Windows usage
>>> around Usenet but he has certainly displayed an ability
>>> to have you guys running in a loop.
>>> Check my headers for where he is headed, given the tools
>>> and information.
>>>
>>>>There's a reason they say not to feed trolls.
>>>>
>>> True, shunning being at the core of it.
>>
>>Shunning? How about not taking the bait?
>>
>>> How's that working for you in Church.. where the
>>> practice has its origins?
>>> All the devils locked out?
>>
>>No devils here.
>>
>>> No argument here on "place on ignore".
>>> However it only works when you corral the bastard
>>> and hobble him. Doing that requires work.
>>
>>It works pretty well, except when people, for reasons apparently no more
>>sane than the troll's, continuously make futile attempts to argue with
>>him and point out what a troll he is. As if the former weren't uselessly
>>hopeless, and the latter weren't uselessly obvious. I mean, am I being
>>metatrolled here? Ignoring him is all anyone needs to do.
>>
> Shift the timeline back a few years and you would have my
> full agreeance with _all_ you put, Paul.
> Today is a different world, different culture, differing
> access points and certainly a wider field of play.
> Shunning is redundant.
Look, I'm not saying the only use for a troll is to flex your killfile —
some people like arguing with inanity for the sake of argument, and have
a near-insatiable appetite for the same. I'm saying if you want to “deal
with” a troll in some way, just block. It works great, the troll is
dealt with, and it doesn't mess with everybody else's SNR. Arguing with
it for some reason other than personal improvement, or pointing out its
obvious nature? Come on, be serious.
> I do not believe you have not seen any posts from him in a
> month. I do believe you have not recognized the posts and I
> would increase the ante to say a search would find you
> replying to him.. without you knowing the OP was him.
Ah. You would perhaps win the first half of that bet. I believe I
detected a new alias recently, which of course I couldn't block until it
appeared. Replying to him... oh, no, you're not going to find that (with
the qualification that I don't recall when I lost interest in him — I
estimate it to be at least a month, but I could misremember). Unless
you're yet another alias for the same guy, which would be very clever.
> Whatever, I am not looking to argue the point, I am looking
> for information and you are helping, thank you for that.
You're welcome?
lórs <·····@dev.null> writes:
> Paul Donnelly <·············@sbcglobal.net> wrote:
>
>>lors <······@dev.null> writes:
>>
>>> Paul Donnelly <·············@sbcglobal.net> wrote:
>>>
>>>>lors <·······@bit.bin.invalid> writes:
>>>>
>>>>> I said earlier:
>>>>>>> /qThe only way left is
>>>>>>> to hit him on the head
>>>>>>> /q
>>>>>>
>>>>> You replied:
>>>>>>What's he going to do, start replying to himself?
>>>>>>
>>>>> Do you need more example?
>>>>
>>>>I've had a 100% success rate avoiding trolls with this technique.
>>>>
>>> Then you might write up a RFC on the topic?
>>>
>>>>Do I need more examples?
>>>>
>>> Did you check the headers of my post before you wrote that?
>>
>>No, because the point was that for anyone uninterested in reading a
>>known troll's posts, filtering them is trivial. Unless your headers
>>indicate that this is nowhere near effective, I don't see what they
>>could have to do with it.
>>
> errr.. Paul, you missed my point completely.
> I jumped a few explanations as I believed programmers
> would be aware of what can be done in hacking up a
> clean set of headers, continuously, machine generated even.
>
> I have changed some of my X- again, as a demonstration.
> My client is patched to do this "on the fly".
Okay, fair enough. He could change his name around, even to the extent
that I have to (*gasp*) manually ignore him or attempt to write a clever
enough filter to catch him.
Just out of curiousity, what is it that you think should be done to
avoid being trolled, other than refusing to take the bait?
On 2009-07-13 22:01:53 +0100, Paul Donnelly <·············@sbcglobal.net> said:
> It works pretty well, except when people, for reasons apparently no more
> sane than the troll's, continuously make futile attempts to argue with
> him and point out what a troll he is
I argue with them because it entertains me, and also because (other
than the troll, who is never hearing what you say) it's occasionally
helpful to me (and maybe others) to think about the issues arising from
the kind of hideous failures of understanding these people have. A
(now long-ago) instance of this was someone who catastrophically
misunderstood how the Lisp reader worked, and (although, of course, he
never learned anything), *I* worked out things based on responding to
his misunderstandings. In the current case, I was thinking in the last
few minutes about the whole parse-tree/parse-graph thing, and realised
that of course other languages *don't* have parse trees: they have
parse graphs as well, because whatever object represents variable
bindings needs to be shared.
--tim
On Jul 13, 5:21 pm, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-13 22:01:53 +0100, Paul Donnelly <·············@sbcglobal.net> said:
>
> > It works pretty well, except when people, for reasons apparently no more
> > sane than the troll's, continuously make futile attempts to argue with
> > him and point out what a troll he is
>
> I argue with them because it entertains me, and also because (other
> than the troll, who is never hearing what you say) it's occasionally
> helpful to me (and maybe others) to think about the issues arising from
> the kind of hideous failures of understanding these people have.
These tiresome personal attacks do not constitute rational arguments
in favor of Lisp or Java, Tim and Paul.
On Jul 13, 5:30 pm, lors <······@dev.null> wrote:
> Tim Bradshaw <····@cley.com> wrote:
> >On 2009-07-13 22:01:53 +0100, Paul Donnelly <·············@sbcglobal.net> said:
> >> It works pretty well, except when people, for reasons apparently no more
> >> sane than the troll's, continuously make futile attempts to argue with
> >> him and point out what a troll he is
> >I argue with them because it entertains me, and also because (other
> >than the troll, who is never hearing what you say) it's occasionally
> >helpful to me (and maybe others) to think about the issues arising from
> >the kind of hideous failures of understanding these people have.
[etc.]
> Some folk, still today, see "Troll" running around with a
> huge banner, just so everyone knows who they are and can
> avoid them.. yeh.. right! not!
These tiresome personal attacks do not constitute rational arguments
in favor of Lisp or Java, "lors", Tim, and Paul.
Tim Bradshaw <···@cley.com> writes:
> On 2009-07-13 22:01:53 +0100, Paul Donnelly <·············@sbcglobal.net> said:
>
>> It works pretty well, except when people, for reasons apparently no more
>> sane than the troll's, continuously make futile attempts to argue with
>> him and point out what a troll he is
>
> I argue with them because it entertains me,
So I've noticed. I can't really argue with that.
> and also because (other than the troll, who is never hearing what you
> say) it's occasionally helpful to me (and maybe others) to think about
> the issues arising from the kind of hideous failures of understanding
> these people have. A (now long-ago) instance of this was someone who
> catastrophically misunderstood how the Lisp reader worked, and
> (although, of course, he never learned anything), *I* worked out
> things based on responding to his misunderstandings. In the current
> case, I was thinking in the last few minutes about the whole
> parse-tree/parse-graph thing, and realised that of course other
> languages *don't* have parse trees: they have parse graphs as well,
> because whatever object represents variable bindings needs to be
> shared.
>
> --tim
On 2009-07-13 22:51:50 +0100, Paul Donnelly <·············@sbcglobal.net> said:
>> I argue with them because it entertains me,
>
> So I've noticed. I can't really argue with that.
Incidentally, I do apologise if some of these things have been
crossposted into other groups - I figure CLL people can decide to
ignore me or not, but it is kind of rude to blunder into other groups.
My only (weak) excuse is that the newsreader I'm using is somewhat
rudimentry (does anyone know of a good OSX newsreader - a GUI one and
not a crappy port of some X one, or Emacs?)
--tim
On Jul 12, 9:14 pm, lors <······@dev.null> wrote:
> ····@informatimago.com (Pascal J. Bourguignon) wrote:
> >Adlai <·········@gmail.com> writes:
> >> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
> >>> On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
> >>> > On May 20, 6:03 pm, Series Expansion <·······@gmail.com> wrote:
> >> [snip]
> >>> > You've completely ignored GENSYMS.
> >>> I have not. What you described affected the storage allocation of an
> >>> object referenced by a variable. This has no impact on collisions
> >>> among the names of variables when the compiler parses the code that
> >>> has been transformed previously by the macro.
> >> GENSYM generates a symbol that is not interned in any package; in
>
> >This has already been repeated 5 times in this thread. The guy won't
> >learn, no matter what you may write on usenet.
It is certainly true that no-one can be made to learn through
browbeating and hostility.
I, in particular, am impervious to anything that isn't logic. Call me
names, rail at me, pull out my toenails, and I will not "learn"
anything through those methods except maybe that you are what is often
termed, in the vernacular, an "asshole".
> >The only way left is to hit him on the head.
Threats of physical violence will not persuade me either. Argument by
force is as much a logical fallacy as ad hominem or any of the others
you have employed here lately.
> Be fine if "stop posting" actually did have any effect as a
> function. Hands over ears has never worked with this type of
> asshole.
Pardon me, but if anyone here is an "asshole" it is yourself. I have
been polite throughout this exchange, even when others have been
somewhat less so towards me.
> As "Seamus Macrae" the asshole is invading the free news
> server froup.
I have no clue what this is referring to, other than that it clearly
has nothing whatsoever to do with me.
On May 23, 2:17 pm, Adlai <·········@gmail.com> wrote:
> On May 23, 11:54 am, Series Expansion <·······@gmail.com> wrote:
> > On May 20, 1:18 pm, Adlai <·········@gmail.com> wrote:
> > > You've completely ignored GENSYMS.
>
> > I have not. What you described affected the storage allocation of an
> > object referenced by a variable. This has no impact on collisions
> > among the names of variables when the compiler parses the code that
> > has been transformed previously by the macro.
>
> GENSYM generates a symbol that is not interned in any package; in
> fact, any such symbol could not be re-referenced by simply reading
> it's name
As a consequence of which, it could not be used to store and then
successfully recover a value, except if it were itself referenced by
another variable that was then used indirectly to store and recover
the value.
And then THAT variable becomes a potential source of collisions.
Attempting to solve the collision problem with these things is like
attempting to reach the corner store on foot by taking a step forward
on your exercise treadmill. You end up precisely where you started,
after a slight expenditure of energy, and no closer to reaching the
store.
> Thus, you have to have the original reference to these symbols from
> their creation to access them.
And, of course, you have to store that reference somewhere. And, of
course, you have to name that storage to refer to *it*. And, of
course, if this too is a gensym, then that too must now have a
reference, and so forth. Eventually you must stop taking more and more
steps forward on that treadmill and get off, and then you are back
where you started: with a non-gensym variable name and a risk of a
collision.
> > Thus we have arrived at a contradiction. Your hypothesis that a macro
> > exists that can do as you have described has been disproven.
>
> Addressed by the first paragraph in this post.
Not so, as I have explained. You haven't even succeeded in moving the
problem this time, let alone eliminating it.
> I've tried to explain here again, why GENSYM creates symbols that
> enable capture-free macros.
And I've tried to explain here again why they do not.
> > > Also, it does seem to me that you haven't put much effort into
> > > understanding the Lisp package system or CLOS.
>
> > I have put precisely as much effort into doing so as you have put into
> > describing them, since I have read what you have written about them.
> > If you have not done a very good job of explaining them in terms a lay
> > person would understand, then that is hardly a basis for concluding
> > something negative about me.
>
> I've tried to explain them in the same terms that PCL, Successful
> Lisp, or On Lisp use, since those are the resources that have taught
> me about these concepts so far.
Then perhaps these reference works, which you so highly recommended
previously and even rudely demanded I purchase, are not, what is the
expression, "all they are cracked up to be"?
> > > The package system, for one thing, as has been said before, is just a
> > > package of SYMBOLS. That's all. Packages don't store code within them,
> > > just names of stuff.
>
> > Nobody asserted that they stored actual code. But they organize it,
> > indirectly by organizing the names of parts of the code. Furthermore,
> > it was indicated elsewhere that they distinguish names of functions,
> > names of classes, names of variables, and the like from one another,
> > in that a class and a variable, say, can have the same name and be in
> > the same package.
>
> /Packages/ don't do that.
But apparently they do.
> Saying that Lisp has separate function and variable namespaces is a bit
> misleading
Then perhaps you should edit the Wikipedia article that says to to
correct it.
> because all symbols are equal in the eyes of packages, the same way that
> the word "bat" has one entry in the dictionary, but multiple meanings as
> different parts of speech. A person /reading/ a text determines which part
> of speech to use to understand the word.
If the package is analogous to a dictionary, then it stores, and
distinguishes, these multiple definitions, contrary to your claims
about Lisp packages.
Otherwise, your analogy given above fails to be applicable and is
void.
> > > > > You haven't even said something along the lines of "I read xyz,
> > > > > but I'm still confused about how generic functions frobnobdicate their
> > > > > quuxmagogs... clarifications plz?"
>
> > > > Generic functions are irrelevant to the matter at hand, namely,
> > > > macros. Therefore it is unsurprising that I have not said much about
> > > > them.
>
> > > People have mentioned gensym, which is completely relevant to macros,
>
> > But, as I have demonstrated, it is irrelevant to the capture problem.
> > Unless of course you have misdescribed them, in which case they might
> > be relevant without that having been made apparent to me.
>
> Maybe I didn't describe it clearly enough. I've tried again.
Indeed you have, and it did not take me long to discover, and explain,
why they do not solve the capture problem.
> However, because they are not interned, it's impossible to reference them
> without the return-value of the GENSYM function.
And this return value must be stored somewhere, whence we are back to
square one. Initially, we needed to evaluate an argument once and then
use the result multiple times, and so needed somewhere to store it.
Now, we need to generate a gensym once and then use the result
multiple times, and so need somewhere to store it.
> > > I cite a page on Peter Norvig's site:http://www.norvig.com/java-lisp.html
> > > He talks about a study done in a few different languages. One of the
> > > results was that Lisp code for the test program was produced within
> > > hours, while many of the submissions in other languages took days.
>
> > What was the nature of the test program? This kind of thing can very
> > easily be biased, even inadvertently, by the selection of a test
> > program suited to a particular language's strengths.
>
> Did you read the page that I linked to?
No. I had not the time to dig through that site looking for whatever
specific paragraph or two MIGHT have existed containing the specific
information in question, nor is it likely to have materially affected
my point here.
> Although it wasn't a huge project, the results did seem to have
> some statistical significance.
That seems doubtful, given that the sample size of programmers per
language/requirements pair was probably in the single digits, and the
size of the sample of requirements certainly was, being just one.
> Another example I'd cite, which isn't as specific, is Viaweb's
> massive success. Paul Graham, one of Viaweb's founders,
> attributes much of this success to the productivity boost
> experienced by Lisp programmers.
An anecdotal story has even less statistical significance.
On May 21, 12:54 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> > a macro invocation is replaced with some code, inside which
> > placeholders are replaced with copies of the call's arguments, and
> > then the result of the substitution is compiled.
>
> This is false.
You are being illogical.
> > My concerns regarding macro use derive entirely from this one fact,
> > which you have not denied is true of Lisp macros.
>
> And I told you Lisp macros are functions. They can expand into
> anything computable, not just "some code, inside which placeholders
> are replaced with copies of the call's arguments"
If they don't expand into code, then the result after applying the
macro will not compile. So a functional macro does expand into "some
code". And when macros have arguments, these are typically not ignored
but, rather, used as inputs to that function, generally by
substituting them for something in the expansion.
Regardless, the key point I am making is that "a variable name that
will not collide with any variable name in any enclosing scope" is not
computable from just the arguments -- it is only computable from the
entire code base, or a large fraction thereof.
On 2009-05-17, Series Expansion <·······@gmail.com> wrote:
> I came to this debate curious about Lisp, rather than
> inherently hostile to it, but found myself somewhat alarmed by things
> that I realized would inevitably cause serious problems in any
> realistic large-scale software-development effort.
I don't think anyone in their right mind would let a twit like
you into a building where such a project is taking place.
> My criticism in
> this area was offered with the hope that it might lead to
> improvements
Your criticism after sniffing Lisp for five minutes is about as valuable as a
wet paper tissue.
Kaz Kylheku wrote:
> On 2009-05-17, Series Expansion <·······@gmail.com> wrote:
>> I came to this debate curious about Lisp, rather than
>> inherently hostile to it, but found myself somewhat alarmed by things
>> that I realized would inevitably cause serious problems in any
>> realistic large-scale software-development effort.
>
> I don't think anyone in their right mind would let a twit like
> you into a building where such a project is taking place.
Don't worry. No chance that would happen.
Arne
On May 22, 9:23 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Kaz Kylheku wrote:
> > On 2009-05-17, Series Expansion <·······@gmail.com> wrote:
> >> I came to this debate curious about Lisp, rather than
> >> inherently hostile to it, but found myself somewhat alarmed by things
> >> that I realized would inevitably cause serious problems in any
> >> realistic large-scale software-development effort.
> > I don't think anyone in their right mind would let a twit like
> > you into a building where such a project is taking place.
> Don't worry. No chance that would happen.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Kaz and Arne.
On May 21, 1:10 am, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-05-17, Series Expansion <·······@gmail.com> wrote:
>
> > I came to this debate curious about Lisp, rather than
> > inherently hostile to it, but found myself somewhat alarmed by things
> > that I realized would inevitably cause serious problems in any
> > realistic large-scale software-development effort.
>
> I don't think anyone in their right mind would let a twit like
> you into a building where such a project is taking place.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Kaz.
> > My criticism in this area was offered with the hope that it might
> > lead to improvements
>
> Your criticism after sniffing Lisp for five minutes is about as valuable as a
> wet paper tissue.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Kaz.
The fact is that you, collectively, have given me a very poor first
impression of Lisp. If Lisp is as great as you claim it is, then you
have misrepresented it, albeit probably not intentionally. If it is
not, then my original claims stand, and your attacking of those claims
was irrational. In either case, you have made some type of error.
On May 16, 5:21 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > This is not Lisp vs. Java debate. We are not attacking Java at all,
> > because we are not the trolls here. This is more a "Java programmers
> > that don't understand and never programmed in Lisp before rudely,
> > pointlessly and with very weak arguments attacking Lisp" debate. Give
>
> "Series" does not represent the typical Java programmer.
Actually, I am an entirely typical Java programmer.
> > You Javaers are the ones
> > treating us like if we are a bunch of amateurs who don't know how to
> > program.
>
> Now that is a very unfair generalization. Don't tar Java programmers with the
> "Series Expansion" brush. I'm a Java programmer myself, but that doesn't mean
> I agree with or endorse his behavior.
There is nothing wrong with my behavior. A cursory examination of this
thread will reveal that it is the Lisp advocacy side of this debate
that has accused the other side of being amateurs, in one particular
case asserting that Java programmers are incompetent for example. It
is also the Lisp side that has engaged routinely in the ad hominem
variety of debating tactics, widely considered to be an indication
that the side doing so first has lost the argument.
> In fact, I don't. I assess that "Series" is a brat.
Then you would be wrong.
> From time to time even entirely within the comp.lang.java.programmer
> newsgroup we get posts from people who profess to be Java programmers but only
> use the forum to exercise their nasty little egos.
People like yourself? Certainly I have not been egotistical here. You
on the other hand have recently dumped a rather large slurry of ad
hominem posts, first aimed at the Lispers, then at Seamus from what
had been your own camp, and now at myself. It seems probable that you
now have few friends in either camp. Such behavior will soon condemn
you to walk the battlefield alone, a target for both sides.
> Does that never happen entirely within the comp.lang.lisp group?
> Is everyone who posts their fair and balanced?
Of those that have crossposted into comp.lang.java.programmer, it
would appear that none of them are.
> Clearly, "Series Expansion" is not.
On the contrary. My lack of your biases may have convinced you that I
am biased the other way, but this could not be further from the truth.
One thing I am is stubborn. I don't tend to accept arguments that
consist of "this isn't a problem for us, though we have not and
apparently will not furnish arguments or evidence as to why", or of
expressions of faith, or even simply of "no, no, no, no, none of these
problems occur". That is, such arguments don't sway me. Neither do
arguments of the ad hominem variety. Only logic and evidence will sway
me in either direction, and whereas I have provided detailed
explanations of why certain pitfalls are inevitable consequences of
macro use, none have furnished any valid arguments to refute those
explanations.
I have also caught some of the Lispers in contradictions from time to
time, or pointed out absurdities in something they said, but that they
did not apparently examine closely enough before pressing "send".
Perhaps that has not enamored me to them, or to you, but that is not
my aim. These are software engineering newsgroups. Politics should
take a backseat to pragmatism and reason. It is saddening that this
has not apparently occurred.
On May 17, 10:51 pm, Series Expansion <·······@gmail.com> wrote:
> On May 16, 5:21 pm, Lew <·····@lewscanon.com> wrote:
>
> > gugamilare wrote:
> > > This is not Lisp vs. Java debate. We are not attacking Java at all,
> > > because we are not the trolls here. This is more a "Java programmers
> > > that don't understand and never programmed in Lisp before rudely,
> > > pointlessly and with very weak arguments attacking Lisp" debate. Give
>
> > "Series" does not represent the typical Java programmer.
>
> Actually, I am an entirely typical Java programmer.
>
> > > You Javaers are the ones
> > > treating us like if we are a bunch of amateurs who don't know how to
> > > program.
>
> > Now that is a very unfair generalization. Don't tar Java programmers with the
> > "Series Expansion" brush. I'm a Java programmer myself, but that doesn't mean
> > I agree with or endorse his behavior.
>
> There is nothing wrong with my behavior. A cursory examination of this
> thread will reveal that it is the Lisp advocacy side of this debate
> that has accused the other side of being amateurs, in one particular
> case asserting that Java programmers are incompetent for example. It
> is also the Lisp side that has engaged routinely in the ad hominem
> variety of debating tactics, widely considered to be an indication
> that the side doing so first has lost the argument.
>
> > In fact, I don't. I assess that "Series" is a brat.
>
> Then you would be wrong.
>
> > From time to time even entirely within the comp.lang.java.programmer
> > newsgroup we get posts from people who profess to be Java programmers but only
> > use the forum to exercise their nasty little egos.
>
> People like yourself? Certainly I have not been egotistical here. You
> on the other hand have recently dumped a rather large slurry of ad
> hominem posts, first aimed at the Lispers, then at Seamus from what
> had been your own camp, and now at myself. It seems probable that you
> now have few friends in either camp. Such behavior will soon condemn
> you to walk the battlefield alone, a target for both sides.
>
> > Does that never happen entirely within the comp.lang.lisp group?
> > Is everyone who posts their fair and balanced?
>
> Of those that have crossposted into comp.lang.java.programmer, it
> would appear that none of them are.
>
> > Clearly, "Series Expansion" is not.
>
> On the contrary. My lack of your biases may have convinced you that I
> am biased the other way, but this could not be further from the truth.
>
> One thing I am is stubborn. I don't tend to accept arguments that
> consist of "this isn't a problem for us, though we have not and
> apparently will not furnish arguments or evidence as to why", or of
> expressions of faith, or even simply of "no, no, no, no, none of these
> problems occur". That is, such arguments don't sway me. Neither do
> arguments of the ad hominem variety. Only logic and evidence will sway
> me in either direction, and whereas I have provided detailed
> explanations of why certain pitfalls are inevitable consequences of
> macro use, none have furnished any valid arguments to refute those
> explanations.
Hello @ you re: numerous posts where people have patiently explained
- the differences between the Lisp macro system and the C macro
system,
- the power of the Lisp package system
- Emacs
- Why you are a flaming frolicking freelance TROLL
>
> I have also caught some of the Lispers in contradictions from time to
> time, or pointed out absurdities in something they said, but that they
> did not apparently examine closely enough before pressing "send".
> Perhaps that has not enamored me to them, or to you, but that is not
> my aim. These are software engineering newsgroups. Politics should
> take a backseat to pragmatism and reason. It is saddening that this
> has not apparently occurred.
How has politics come out in this thread? I think the only remotely
political comment made RECENTLY (there were some posts about the
politics of the job market, but those were before anti-Lisp flaming
began) was something about going to hell. I think that more political
is the style of the responses you use, where you filibuster away
patient and thought-out explanations with tear-jerking (not!)tales of
your troubles trying to reason (not!) logically (not!) with all the
ignoranuses (not!) on c.l.l and their oft-changing (not!) ill-defined
(not!) opinions.
Good night, and good luck.
- Adlai
On May 17, 4:04 pm, Adlai <·········@gmail.com> wrote:
> On May 17, 10:51 pm, Series Expansion <·······@gmail.com> wrote:
> > On the contrary. My lack of your biases may have convinced you that I
> > am biased the other way, but this could not be further from the truth.
>
> > One thing I am is stubborn. I don't tend to accept arguments that
> > consist of "this isn't a problem for us, though we have not and
> > apparently will not furnish arguments or evidence as to why", or of
> > expressions of faith, or even simply of "no, no, no, no, none of these
> > problems occur". That is, such arguments don't sway me. Neither do
> > arguments of the ad hominem variety. Only logic and evidence will sway
> > me in either direction, and whereas I have provided detailed
> > explanations of why certain pitfalls are inevitable consequences of
> > macro use, none have furnished any valid arguments to refute those
> > explanations.
>
> Hello @ you re: numerous posts where people have patiently explained
> - the differences between the Lisp macro system and the C macro
> system,
I have patiently and repeatedly explained why these are irrelevant; my
arguments depended only on those features common to all macros, indeed
inherent in the very definition of "macro".
> - the power of the Lisp package system
I have shown little interest in the topic of the package system.
Perhaps you are thinking of Seamus MacRae, another
comp.lang.java.programmer poster who has been involved extensively in
that topic?
> - Emacs
Your fascination with archaic software and tolerance for archaic user
interfaces remains inexplicable.
> - Why you are a flaming frolicking freelance TROLL
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Adlai.
> > I have also caught some of the Lispers in contradictions from time to
> > time, or pointed out absurdities in something they said, but that they
> > did not apparently examine closely enough before pressing "send".
> > Perhaps that has not enamored me to them, or to you, but that is not
> > my aim. These are software engineering newsgroups. Politics should
> > take a backseat to pragmatism and reason. It is saddening that this
> > has not apparently occurred.
>
> How has politics come out in this thread?
Certainly pragmatism and reason has not, except primarily on my own
part.
There have been indications that Lew's behavior in particular stems
from misdirected rage whose true target is absent. His animosity, and
also certain exchanges among Kaz, Kevin, and Seamus involving
references to living persons as "gods", imply some kind of power
politics is in play among the more regular users of both newsgroups,
as is to be expected in any large enough group of human beings with
somewhat stable membership, and furthermore that the politics in
question is influencing peoples' behavior in this thread, particularly
where they are observed displaying hatred, loyalty, solidarity, anger,
and other irrational emotions, and allowing these to thoroughly
override reason and supplant civilized behavior.
Furthermore, there were some anti-Semitic remarks from Lispers a while
ago, and, more recently, a claim fronted by Lew that promoted bigotry
against a sizable fraction of the planet's population, particularly
those of British ancestry.
It is possible that this last is a clue to the identity of Lew's
inferred nemesis. I will observe with some fascination the fireworks
that are likely to ensue should this individual choose to put in an
appearance here.
> I think the only remotely political comment made RECENTLY (there were
> some posts about the politics of the job market, but those were before
> anti-Lisp flaming began)
There has been some argumentation with respect to the utility and
desirability of some Lisp features, but actually very little of what I
would characterize as "anti-Lisp flaming". There was considerably more
anti-Java flaming. Of late, the vast majority of the flaming has been
interpersonal rather than intergroup, however, and indeed much of it
has been internal to comp.lang.java.programmer's population, to wit,
the voluminous irrational personal attacks by Lew perpetrated against
both myself and Seamus MacRae.
> I think that more political is the style of the responses you use,
> where you filibuster away patient and thought-out explanations with
> tear-jerking (not!)tales of your troubles trying to reason (not!)
> logically (not!) with all the ignoranuses (not!) on c.l.l and their
> oft-changing (not!) ill-defined (not!) opinions.
On the contrary, it is you who filibuster away my patient and thought-
out explanations with tear-jerking (not!) tales of your troubles
trying to reason (not!) logically (not!) with all the ignoramuses
(not!) on c.l.j.p.
I have been exceedingly patient, with only a few outbursts of my own,
whereas I have witnessed a most remarkably diverse array of illogic,
emotion, random behavior, and churlishness from many of the other
participants here.
> Good night, and good luck.
I require neither rest nor what you superstitiously term "luck"; only
logic, and that I already have. You, however, could benefit greatly
from acquiring more, in my estimation. You fervently believe your
side's propositions yet you seem unable to muster any arguments for
them more cogent than "I believe it" or "I don't believe your
objections" and frequently resort to ignoring your opponent,
misstating his position, insulting his character, and mere repetition
in an attempt to convince him or others that, using such methods, is
quite futile. If your position has merit, logic will be your ally in
supporting those points that you have on your side, and eventually in
enabling those points to prevail against opposition. Of course, if it
has none, logic will avail you of nothing, save the capability to
realize that it is not your opponents' minds that need changing but
rather your own.
Series Expansion wrote:
> I have patiently and repeatedly explained why these are irrelevant; my
> arguments depended only on those features common to all macros, indeed
> inherent in the very definition of "macro".
the definition of the british word 'fanny' does not have anything in common
with the definition of the american word 'fanny'. they both name body
regions that sit between the torso and the legs, but that's about it.
don't assume that because two words sound identical, they mean the same
thing or that their definitions have anything in common. lisp-style macros
and C-style macros have about as much in common as british 'fanny' and
american 'fanny'. so IOW there is nothing "inherent in the very definition
of 'macro'".
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
On May 20, 9:39 am, Joost Kremers <············@yahoo.com> wrote:
> Series Expansion wrote:
> > I have patiently and repeatedly explained why these are irrelevant; my
> > arguments depended only on those features common to all macros, indeed
> > inherent in the very definition of "macro".
>
> the definition of the british word 'fanny'
is irrelevant.
> don't assume that because two words sound identical, they mean the same
> thing or that their definitions have anything in common.
I did not, and your admonishment based on a faulty assumption is quite
rude.
The only thing I assumed was that a) a Lisp macro invocation gets
replaced with some code for the compiler to compile in it place, and
b) in that code certain placeholders are replaced by the macro
arguments.
This has since been acknowledged as true by several of the
comp.lang.lisp people at various points.
That you continue to argue against it suggests that you are
irrational.
On May 23, 10:49 am, Series Expansion <·······@gmail.com> wrote:
> On May 20, 9:39 am, Joost Kremers <············@yahoo.com> wrote:
>
> > Series Expansion wrote:
> > > I have patiently and repeatedly explained why these are irrelevant; my
> > > arguments depended only on those features common to all macros, indeed
> > > inherent in the very definition of "macro".
>
> > the definition of the british word 'fanny'
>
> is irrelevant.
You cut off what Joost was saying in the middle of a sentance. I think
that's more rude than telling somebody they're wrong, because it shows
that you care more about misquoting them than about reading what they
were telling you.
>
> > don't assume that because two words sound identical, they mean the same
> > thing or that their definitions have anything in common.
>
> I did not, and your admonishment based on a faulty assumption is quite
> rude.
>
> The only thing I assumed was that a) a Lisp macro invocation gets
> replaced with some code for the compiler to compile in it place, and
> b) in that code certain placeholders are replaced by the macro
> arguments.
No, you made another assumption -- it is as follows:
It is possible for the compiler to generate code referring to a symbol
named by code given to the compiler. This is wrong, because you can
have two symbols with names that print (and read) the same, a feature
primarily used for generating safe macro code without resorting to
Scheme-style macros. This is /not possible to do/ in C macros, but
possible in Lisp macros.
- Adlai
On May 23, 1:12 pm, Adlai <·········@gmail.com> wrote:
> On May 23, 10:49 am, Series Expansion <·······@gmail.com> wrote:
> > On May 20, 9:39 am, Joost Kremers <············@yahoo.com> wrote:
> > > Series Expansion wrote:
> > > > I have patiently and repeatedly explained why these are irrelevant; my
> > > > arguments depended only on those features common to all macros, indeed
> > > > inherent in the very definition of "macro".
>
> > > the definition of the british word 'fanny'
>
> > is irrelevant.
>
> You cut off what Joost was saying in the middle of a sentance.
Because he was obviously flying off onto an unproductive and pointless
tangent that I had neither the time nor the inclination to pursue.
> that's more rude than ...
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Adlai.
Please confine your remarks to the subjects of Lisp and Java, and keep
your negative opinions of me to yourself. Publishing the latter can
serve no constructive purpose.
> > The only thing I assumed was that a) a Lisp macro invocation gets
> > replaced with some code for the compiler to compile in it place, and
> > b) in that code certain placeholders are replaced by the macro
> > arguments.
>
> No, you made another assumption -- it is as follows:
>
> It is possible for the compiler to generate code referring to a symbol
> named by code given to the compiler.
This follows logically from the fact that it is possible for the
compiler to generate arbitrary code, which in turn follows from Turing-
completeness of the language.
The rest of your post was incoherent, so I see little point in either
quoting or further commenting upon it.
Lew wrote:
>> "Series" does not represent the typical Java programmer.
Series Expansion wrote:
> Actually, I am an entirely typical Java programmer.
Gods, I hope not!
Lew wrote:
>> I'm a Java programmer myself, but that doesn't mean
>> I agree with or endorse his behavior.
Series Expansion wrote:
> There is nothing wrong with my behavior.
Your behavior sucks, you liar.
>> In fact, I don't. I assess that "Series" is a brat.
> Then you would be wrong.
Brat.
Lew:
>> From time to time even entirely within the comp.lang.java.programmer
>> newsgroup we get posts from people who profess to be Java programmers but only
>> use the forum to exercise their nasty little egos.
That nasty worm, who styles himself "Series Expansion":
> People like yourself? Certainly I have not been egotistical here. You
Hahaha.
> on the other hand have recently dumped a rather large slurry of ad
> hominem posts, first aimed at the Lispers, then at Seamus from what
Not at "Lispers", as you call them, but certainly at "Seamus" and you, you
unworthy.
> had been your own camp, and now at myself. It seems probable that you
Neither you nor "Seamus" are in my camp. How arrogant of you to place
yourself with me. I spurn you. You are beneath contempt.
> now have few friends in either camp. Such behavior will soon condemn
> you to walk the battlefield alone, a target for both sides.
I can take it. Can you?
>> Does that never happen entirely within the comp.lang.lisp group?
>> Is everyone who posts their fair and balanced?
...
>> Clearly, "Series Expansion" is not.
>
> On the contrary. My lack of your biases may have convinced you that I
> am biased the other way, but this could not be further from the truth.
Your bias is to self-aggrandisement and nastiness, and certainly as far from
the truth as one can get.
> One thing I am is stubborn.
Clearly. Not in a good way, either.
> ... none have furnished any valid arguments to refute those
> explanations.
You wouldn't know a valid argument if it bit you in the fundament.
> I have also caught some of the Lispers in contradictions from time to
> time, or pointed out absurdities in something they said, but that they
You're a fine one to talk about "absurdities in something they said", whose
every utterance is as absurd as it is unwarranted and hostile.
You have engaged with me, which is all that I required. I just could not
understand why you didn't answer me when I have tried so hard to goad you into
responding by calling you out for what you are, you craven fool. Now my ego
is fulfilled, and I hope I haven't spoiled it for everyone else. Now that I
have your attention, "Series Expansion", I shall plonk you. Rest assured,
"Series", that I am flipping you the bird as I do so.
To the rest of the world, and especially to the Lisp adherents whom "Series"
has abused, and to the Java programmers (myself excluded, of course, since I'm
every bit as trollish in this thread) whom "Series" has so egregiously
misrepresented, I sincerely apologize for stooping to his level.
But, man, it sure was fun for me!
--
Lew
On May 17, 4:08 pm, Lew <·····@lewscanon.com> wrote:
> Lew wrote:
Why reply to yourself?
> Series Expansion wrote:
> > Actually, I am an entirely typical Java programmer.
>
> Gods, I hope not!
Then your hopes are in vain.
And apparently you did not reply to yourself; you mangled your
attributions again.
> >> I'm a Java programmer myself, but that doesn't mean
> >> I agree with or endorse his behavior.
> > There is nothing wrong with my behavior.
>
> Your behavior sucks, you liar.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> >> In fact, I don't. I assess that "Series" is a brat.
> > Then you would be wrong.
>
> Brat.
These childish personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> >> From time to time even entirely within the comp.lang.java.programmer
> >> newsgroup we get posts from people who profess to be Java programmers but only
> >> use the forum to exercise their nasty little egos.
>
> That nasty worm, who styles himself "Series Expansion"
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > People like yourself? Certainly I have not been egotistical here. You
>
> Hahaha.
Fascinating. The frequency and severity of these irrational, emotional
outbursts from "Lew" indicate that he is on the verge of some kind of
breakdown of mental functioning. He appears largely incapable of
reason at this time, yet insists on attempting to participate in this
debate regardless of his possibly-temporary incompetence to do so. I
would suspect that he was inebriated, quite severely, but for the
observation that he has been in this state more-or-less continually
for over 96 hours now.
It is possible that he is in need of medical attention.
> > on the other hand have recently dumped a rather large slurry of ad
> > hominem posts, first aimed at the Lispers, then at Seamus from what
>
> Not at "Lispers", as you call them, but certainly at "Seamus" and you, you
> unworthy.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
You did indeed flame several of the Lispers prior to beginning to
flame your former allies. The following links all are to examples of
your flaming non-comp.lang.java.programmer-regulars early in this
thread:
http://groups.google.com/group/comp.lang.lisp/msg/6702901a0832ef74
http://groups.google.com/group/comp.lang.lisp/msg/ee3e2fc66718b18f
http://groups.google.com/group/comp.lang.lisp/msg/013ddb2d0a59b931
Of these, at least one of them, Kaz, is or has been a Lisp partisan in
the present debate.
> > had been your own camp, and now at myself. It seems probable that you
>
> Neither you nor "Seamus" are in my camp.
By "your own camp" I refer to Java advocates.
There seem to have been two recent events affecting your behavior.
Neither of them appears to have happened in this thread, but one
occurred approximately on May 14, at which time you started
occasionally flaming non-Java participants; the second occurred
approximately one day later. At that time your posting volume rose by
an order of magnitude, you turned on the other Java-advocate
participants in this thread (at that point only myself and Seamus),
and you appear to have lost all remaining capacity for reason or self-
control.
What happened?
> How arrogant of you to place yourself with me.
I place myself with the other advocates of Java. If for some reason
you wish to avoid that you will have to change programming-language
preference.
I do not, however, recommend that you alter your language preference
for irrational reasons stemming from emotions such as animosity, but
rather only for pragmatic ones.
> I spurn you. You are beneath contempt.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > now have few friends in either camp. Such behavior will soon condemn
> > you to walk the battlefield alone, a target for both sides.
>
> I can take it. Can you?
As you can see, I am completely unperturbed by your illogical
behavior. Indeed, to be otherwise would be illogical. You pose no
threat to me, and your visible progression of mental collapse,
triggered by causes unknown, is fascinating to observe.
> > On the contrary. My lack of your biases may have convinced you that I
> > am biased the other way, but this could not be further from the truth.
>
> Your bias is to self-aggrandisement and nastiness, and certainly as far from
> the truth as one can get.
That is incorrect. I have engaged in no self-promotion or similar
illogical, egotistical behaviors here. Nor have I displayed much of
what you term "nastiness". And I most certainly have not lied.
The behaviors you are describing, with the possible exception of self-
aggrandizement, appear to apply best to you, among all of the present
participants in this thread and based on their present behavior. There
has been some mutual aggrandizement, though not self-aggrandizement,
in the Lisp camp.
> > One thing I am is stubborn.
>
> Clearly. Not in a good way, either.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > ... none have furnished any valid arguments to refute those
> > explanations.
>
> You wouldn't know a valid argument if it bit you in the fundament.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
Bald assertions unsupported by evidence or reason, expressions of
faith devoid of logic, and assorted ad hominem remarks do not
constitute valid arguments.
> > I have also caught some of the Lispers in contradictions from time to
> > time, or pointed out absurdities in something they said, but that they
>
> You're a fine one to talk about "absurdities in something they said", whose
> every utterance is as absurd as it is unwarranted and hostile.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
Your every utterance is unwarranted and hostile. Many times you have
responded to a civil remark by myself or another person with a
personal attack directed against myself or another person, often not
the same person as made the civil remark.
My own posts are devoid of absurdities, and none are unwarranted.
Exceedingly few have been hostile.
Your accusations are peculiar. Most of the traits you erroneously
impute to me are in fact traits possessed by you; likewise most of the
traits you erroneously impute to my posts are possessed in quantity by
your own. This may be an indication of psychological projection.
Another possibility is transference; your anger truly lies with
another, and the various attacks upon my character reflect your
feelings about that individual, but his or her absence leads you to
"vent" your anger upon a substitute target, essentially a scapegoat
for whatever perceived or actual wrong you experience on or near the
fifteenth of May.
Psychotherapy may offer some relief of your condition. If that does
not suffice, psychiatric examination and medication may be indicated.
> You have engaged with me, which is all that I required.
Your behavior and motives are not rational. Perhaps you have
misunderstood the purpose of comp.lang.java.programmer?
> I just could not understand why you didn't answer me when I have tried so
> hard to goad you into responding by calling you out for what you are, you
> craven fool.
Perhaps it is because your irrational posts, devoid as they are of
useful content, did not interest me much.
> Now my ego is fulfilled, and I hope I haven't spoiled it for everyone else.
> Now that I have your attention, "Series Expansion", I shall plonk you.
> Rest assured, "Series", that I am flipping you the bird as I do so.
Fascinating. A most illogical outburst of emotion. First he attempts
to obtain attention not by posting something worth other people's time
and attention, but by posting irrational nonsense and drivel. Then,
when someone alerts him that his nonsense is of no value and that it
fails to advance either side of the debate, he asserts an intention to
leave it, though this will deprive him of the attention he formerly
craved. Add to that an expression of hostility directed at the person
that informed him helpfully of his strategic error. His behavior
contradicts his stated aims, and appears devoid of logical purpose. A
most unusual case of temporary psychosis.
> To the rest of the world, and especially to the Lisp adherents whom "Series"
> has abused
I have abused no-one. Those who do not wish to engage in a reasoned
debate with me are quite free to ignore me or even to ignore this
entire thread. There is no coercion, and where there is no coercion
there is by definition no abuse.
> and to the Java programmers (myself excluded, of course, since I'm
> every bit as trollish in this thread)
Intriguing. There are now signs of some degree of logical self-
assessment returning within "Lew". Perhaps his condition has begun to
resolve itself spontaneously, without the need for counseling or
medical attention.
> whom "Series" has so egregiously misrepresented
I have done nothing of the sort. My statements regarding Java have
been accurate, as have, in the aggregate, my statements regarding Java
programmers.
> I sincerely apologize for stooping to his level.
This statement is irrational. For you to have "stooped to my level"
would have required that I had been engaged in the sort of inane,
content-free, violently abrasive, and irrational posting behavior as
you have, whereas my posts have almost entirely been cogent, logical,
and above petty name-calling, chest-beating, vindictive character-
assassination, and similar personal power politics.
> But, man, it sure was fun for me!
"Fun" is not a justification for unpleasant and antisocial behavior.
Series Expansion wrote:
> On May 16, 5:21 pm, Lew <·····@lewscanon.com> wrote:
>> gugamilare wrote:
>>> This is not Lisp vs. Java debate. We are not attacking Java at all,
>>> because we are not the trolls here. This is more a "Java programmers
>>> that don't understand and never programmed in Lisp before rudely,
>>> pointlessly and with very weak arguments attacking Lisp" debate. Give
>> "Series" does not represent the typical Java programmer.
>
> Actually, I am an entirely typical Java programmer.
Absolutely not.
Typical Java programmer are a lot better at listening and learning.
>> In fact, I don't. I assess that "Series" is a brat.
>
> Then you would be wrong.
Maybe not according to birth certificate, but ...
Arne
On May 18, 10:28 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > Actually, I am an entirely typical Java programmer.
>
> Absolutely not.
But I am. Unless you have run statistical studies on Java programmers,
you cannot logically refute it, and to assert otherwise anyway is
therefore illogical. Moreover, it is tantamount to calling me a liar,
which is as extraordinarily rude as it is unprovoked.
> Typical Java programmer are a lot better at listening and learning.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
> >> In fact, I don't. I assess that "Series" is a brat.
>
> > Then you would be wrong.
>
> Maybe not according to birth certificate, but ...
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne and "Lew".
Series Expansion wrote:
> On May 18, 10:28 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>> Series Expansion wrote:
>>> Actually, I am an entirely typical Java programmer.
>> Absolutely not.
>
> But I am.
Absolutely not.
> Unless you have run statistical studies on Java programmers,
> you cannot logically refute it, and to assert otherwise anyway is
> therefore illogical.
Typical Java programmers are reasonable guys (or girls).
You are just a complete wacko.
> Moreover, it is tantamount to calling me a liar,
You claim of being a typical Java programmers is not true.
Arne
On May 22, 10:37 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 18, 10:28 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Series Expansion wrote:
> >>> Actually, I am an entirely typical Java programmer.
> >> Absolutely not.
>
> > But I am.
>
> Absolutely not.
And yet I am.
> > Unless you have run statistical studies on Java programmers,
> > you cannot logically refute it, and to assert otherwise anyway is
> > therefore illogical.
>
> Typical Java programmers are reasonable guys (or girls).
As am I.
> You are just a complete wacko.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
> > Moreover, it is tantamount to calling me a liar,
>
> You claim of being a typical Java programmers is not true.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
On May 16, 4:03 pm, gugamilare <··········@gmail.com> wrote:
> On 16 maio, 16:21, Series Expansion <·······@gmail.com> wrote:
>
> > The first post in this thread was some guy whining that he couldn't
> > get a job. You'll forgive me if I fail to see how that's relevant to
> > the Great Lisp vs. Java Debate of 2009.
>
> 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.
On 17 maio, 01:40, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:03 pm, gugamilare <··········@gmail.com> wrote:
>
> > On 16 maio, 16:21, Series Expansion <·······@gmail.com> wrote:
>
> > > The first post in this thread was some guy whining that he couldn't
> > > get a job. You'll forgive me if I fail to see how that's relevant to
> > > the Great Lisp vs. Java Debate of 2009.
>
> > 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/36a74c9087908698http://groups.google.com/group/comp.lang.lisp/msg/cc4b883036859e6chttp://groups.google.com/group/comp.lang.lisp/msg/26f94536dd3ff7abhttp://groups.google.com/group/comp.lang.lisp/msg/930c3cc4a528bfabhttp://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.
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.
> > 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.
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.
> > 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.
Aleluia!
On May 17, 1:29 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 01:40, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 4:03 pm, gugamilare <··········@gmail.com> wrote:
> > > 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/36a74c9087908698htt...
>
> > 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.
>
> I didn't say that the Java side is wrong. I just say things work
> differently both ways, yadda yadda yadda
Oddly enough, this does not seem to be an apology or even an
acknowledgement of having been in error, despite the quoted material
immediately above it.
Furthermore, the following:
> > > Give me one reference to someone here saying that Java is a bad language,
> > > and I am done talking.
apparently was an outright lie. Remarkable.
> > > 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.
>
> But you still haven't given one argument independent of syntax and
> implementation.
I have done so in several recent posts. Perhaps you have accidentally
marked them as "read" within your news client, prior to actually
reading them? I have done so again in some posts written after yours
above, but before this particular response of mine. I suggest you
locate and read all of the posts in question.
> the way that the programmers think.
Is that to be your final redoubt, then? A claim that Lisp programmers'
thought processes are in fact alien, and that this enables them to
avoid many of the pitfalls that would affect any human programmers
attempting a large scale project in the language? You'll pardon me if
I find that difficult to believe without some kind of evidence.
On the other hand, there is much about the behavior of some of the
participants in this thread that could be explained by the hypothesis
that Lisp programmers are alien. Although Lew's behavior would remain
a mystery.
> > 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.
That you neglected to even address the point until now suggested that
perhaps you were unaware of it. One plausible explanation of that
would of course have been that you were amateurs. That would also
explain, through the psychological phenomenon of projection, the
claims recently mooted among you that we Java programmers are
amateurs.
If that is not the case, however, then those mysteries remain unsolved
for now.
A further examination of what you have just written is warranted now,
since it furnishes the Java side with the tools to achieve immediate
victory:
> Unless the user knows the macro locally creates a variable.
And that, as they say, is "the rub". The user must know each macro's
detailed internals to use it safely, and not merely its intended
semantics and its call signature, unlike with a function or method.
This has been one of my contentions all along, and you have now
confirmed it in full public view. Thank you for that.
The inherent unsafety of macros, particularly the lack of a certain
encapsulation barrier that functions possess, and the problems
consequently attendant upon any editing of macro bodies in a large
code base thus established, I rest my case.
> This shadowing variable thing is well known
I'm sure it is. One generally knows well the most frequent sources of
one's headaches.
> we take a lot of care when using features like that.
Unfortunately, it is evident that you must take a lot of care when
anyone on the development team uses features like that, with "features
like that" including any nontrivial macro.
> I have never seen other macro that captures some variable like that. It
> is rare, and, when done, it is done very carefully.
Now this simply does not seem plausible. The only way to avoid the
noted issues completely is to avoid using any temporaries inside
nearly all macros, which would severely constrain what they can do. As
for "when done, it is done very carefully", this seems to allow no
scope for accidents.
Perhaps you have none, the consequences being so catastrophic that you
are very slow, careful, and deliberate, like workers in a virology lab
handling phials containing deadly pathogens. This is not going to
combine well with the fast-paced world of modern large-scale software
development efforts, however; that degree of caution is incompatible
with meeting next month's deadlines.
> > The best you can hope for is to use a nested scope, give the macro's
> > local variables long and obscure names, 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.
>
> Aleluia!
Unfortunately, there still seem to be over 100 more posts in this
thread. Obviously some participants are still posting voluminously,
even to the extent that it is not easy for me to get caught up. This
is probably because, unlike I, some of the participants have allowed
this to become personal for them, the result, as usual, being an
unfortunate amount of acrimony and a pointless waste of bandwidth.
Series Expansion <·······@gmail.com> writes:
> 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.
I'll try a last time. You've been explained that the macro can and
will generate unique name, that in no way may be collided. This is
absolutely impossible.
And now for the "personal insult":
Go learn Common Lisp! Or even Scheme with its hygienic macros, you
might like them better than Common Lisp macros.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Series Expansion <·······@gmail.com> writes:
>> 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.
>
> I'll try a last time. You've been explained that the macro can and
> will generate unique name, that in no way may be collided. This is
> absolutely impossible.
>
>
> And now for the "personal insult":
>
> Go learn Common Lisp! Or even Scheme with its hygienic macros, you
> might like them better than Common Lisp macros.
Man, that was weak, considering how much of a buffoon and liar "Series
Expansion" is. Every true personal statement you could make about him would
sound like an insult if applied to a normal person.
--
Lew
On May 17, 1:15 pm, Lew <·····@lewscanon.com> wrote:
> Pascal J. Bourguignon wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> 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.
>
> > Go learn Common Lisp! Or even Scheme with its hygienic macros, you
> > might like them better than Common Lisp macros.
>
> Man, that was weak, considering how much of a buffoon and liar "Series
> Expansion" is. Every true personal statement you could make about him would
> sound like an insult if applied to a normal person.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Pascal.
On May 17, 9:19 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > 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.
>
> I'll try a last time.
This is a non-sequitur.
> You've been explained that the macro can and will generate unique
> name, that in no way may be collided.
That would require the macro to be able to examine the contents of the
scope containing the call site. Which means moving more things into
the macro's arguments from outside, so that they're available to the
macro's code to examine. The macro eventually grows to absorb the
entire calling function; every macro then has additional part-of-
function-before-macro's-job and part-of-function-after-macro's-job
arguments.
When you want to have *multiple* macro calls inside a single function,
then the fun really begins, as the macros have to avoid tripping over
*each other*. A combinatorial explosion ensues.
> This is absolutely impossible.
I'm gratified that you apparently realize this.
> And now for the "personal insult":
None are desired or necessary.
> Go learn Common Lisp! Or even Scheme with its hygienic macros, you
> might like them better than Common Lisp macros.
It sounds like Scheme's do something like auto-create a nested scope,
as if #define wrapped things in an implicit brace pair. This solves
variable capture but not variable hiding or multiple evaluation. To be
more "hygienic" (= encapsulated like regular functions) one supposes
it would also need to evaluate its actual arguments once, in left to
right order, assigning to local variables named the formal parameter
names. At this point, it's only half a macro; indeed, it's really just
an always-inlined function.
My guess is that Scheme macros are not any more encapsulated than Lisp
macros with respect to multiple evaluation issues, so implementation
changes to a Scheme macro can still screw up some call sites. The
variable hiding issue would also remain.
Tell me again what macros get you that closures don't?
Series Expansion <·······@gmail.com> writes:
> On May 15, 3:52�pm, gugamilare <··········@gmail.com> wrote:
>> > Code with bugs, potentially, if the macro OR its inputs has bugs.
>>
>> Just like a function can have bugs. Or do you write bugless functions?
>> Tell me the secret then.
>
> Did you miss the bit about tight coupling making it harder to find the
> bugs?
>
>> By using macros the bug will be in one single place, so you can easily
>> change it. If you write the same code a hundred times and realize that
>> it is wrong, you will have to change the one hundred places where you
>> wrote that same thing.
>
> If your editor doesn't support search and replace, I suggest you
> search for a new one to replace it. :)
Apart for emacs, I know of no editor able to do the syntactic analysis
that is needed to match the boilerplates you have to have in non-lisp
programming language, and do the needed substitutions.
But in practice it's too hard to do, so you end doing the updates
manually or mostly manually anyways.
Check again the example of open/try/close vs. with-open-file.
> And now you've replaced a bit of your code with the expanded version.
> Later you'll change the macro for whatever reason, but at this one
> spot the change won't be applied since the macro call was replaced
> with its expansion in your editor at that spot. That copy now gets out
> of synch with the rest of the code.
You are so confused! The macros are not expanded by the editor! They
are compiler hooks, they are expanded by the compiler, from the
source. You never see (unless you use MACROEXPAND) the code generated
by macros, it's immediately processed by the compiler.
The only thing you have to do when you change a macro, is to recompile
the functions that use it. This is easily done automatically by
putting macros in a separate source file and defining correctly the
dependencies of the other files.
> Of course, a proper IDE should let you right click on the macro call
> and get a menu with options like "go to definition", "view
> documentation", and "see expansion in a pop-over window WITHOUT
> altering the code in your source file". For that you need something
> obviously way more sophisticated than what you're describing, which
> ("small sequence of keystrokes") sounds suspiciously like emacs.
"Go to definition" can be implemented using classical tags, like for any
other programming language.
Getting the documentation and seeing the expansions are primitive
feature of the Common Lisp language. Trivial. There's no need for an
IDE. So it's rather trivial to have a simple editor like emacs (or
even simplier) to get the documentation of lisp operators or to expand
a macro.
> 2. At one point, something goes wrong so you hit a "small sequence of
> keystrokes" to do an in-place replacement of a call to that macro
> with its expansion.
Why would we do that? That would mean shooting in one's foot. Nobody
would do that.
> Congratulations, gugamilare, it's a bug!
In your dreams only.
> A made-up example. You haven't named a real, running mission-critical
> system that is routinely modified on the fly while in production use
> and has no back-ups.
>
> Show me one of those, and I'll show you a headline from the future:
> "Over sixty thousand customers in the dark after catastrophic computer
> failure at power distribution center", "Over three hundred million
> awarded in class-action suit over defective products caused by process
> control computer error", "One person dead after ill-timed heart attack
> during last night's six-hour 911 outage", "E-commerce giant courting
> bankruptcy after catastrophic three-week Web site downtime", or
> something along those lines.
In really, such a mission-critical system was developed by Paul
Graham, and sold to Yahoo for a fortune, which used it without such a
catastrophe. http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
Another example, is the debugging of the OS code of the Deep Space 1
code when it was millions of kilometers from the Earth. Again, the
modifications were made on a running program without outage, and even
without physical access to computer.
http://www.flownet.com/gat/jpl-lisp.html
>> How about saving your changes in a file before you load them???
>
> These were changes being made to the copy of the program running in
> RAM using the debugging tools, remember? Not to the source code on
> disk.
Well probably lisp programmers are smarter. For sure you make us
think so. Is it so hard a concept to make the modifications both in
the running lisp image and in some persistent storage?
This is actually the normal work flow of a lisp programmer: he will
edit the source file in emacs, type C-x C-b which will ask slime to
send the file to the running lisp image, which updates it.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Series Expansion <·······@gmail.com> writes:
>> And now you've replaced a bit of your code with the expanded version.
>> Later you'll change the macro for whatever reason, but at this one
>> spot the change won't be applied since the macro call was replaced
>> with its expansion in your editor at that spot. That copy now gets out
>> of synch with the rest of the code.
>
> You are so confused! The macros are not expanded by the editor!
Eh. That wasn't my interpretation of the OP's post. He was responding to
this:
"Macros are not a source of headaches in CL because they are most times
as simple as a normal function. And you can always expand the code
directly from the source (by hitting a small sequence of keystrokes) if
you thing it has a bug somewhere."
where someone said if he suspected a macro was buggy he'd type something
in his IDE that would cause the macro to be expanded in-place.
Series is pointing out that if he then went off to fix the bug in the
macro, but forgot to return to that other part of the code to change the
expanded code back into a macro call, then there's two copies of the
macro code -- the macro, and the one particular application of it that
was replaced in the code editor with its expansion pre-compilation.
As I understand it, he's saying the compiler still expands the macro at
all its other usage sites.
The C equivalent (I'm more familiar with C than Lisp) would be:
You have
#define DOIT(x,y) ((x)+(y)+(y))
Later you find a bug at
DOIT(a,b++)
where b is getting incremented twice instead of once.
You do whatever it is and the code there changes to
((a) + (b++) + (b++))
and realize why b is being incremented twice. You remove the "++" from
the first "b" and then zip back up to the top of the file to change the
macro definition to:
#define DOIT(x,y) ((x)+2*(y))
feeling secure in the knowledge that everything used with DOIT can be
multiplied by two (there's no string "+" concatenation operator in C).
Later, there's a decision made to change it to ((x)+3*(y)). In most
locations in the code where it "does it", the compiler dutifully expands
DOIT(foo,bar) into ((foo)+3*(bar)).
But in one lonely spot the code still reads ((a) + (b) + (b++)).
So b is still multiplied by two, instead of three, there.
Bit of a contrived example? Maybe. But I think this is what Series was
getting at. Maybe he's misunderstanding something somewhere, but I think
you definitely are.
> The only thing you have to do when you change a macro, is to recompile
> the functions that use it. This is easily done automatically by
> putting macros in a separate source file and defining correctly the
> dependencies of the other files.
In the practical software development world, we have long since adopted
tools that track dependencies for us more or less automatically (Java
has the niggling "public static final field problem" though). Your
manual tracking of dependencies would not scale to a real-world
productive code shop in a major company or major open source project.
>> Of course, a proper IDE should let you right click on the macro call
>> and get a menu with options like "go to definition", "view
>> documentation", and "see expansion in a pop-over window WITHOUT
>> altering the code in your source file". For that you need something
>> obviously way more sophisticated than what you're describing, which
>> ("small sequence of keystrokes") sounds suspiciously like emacs.
>
> "Go to definition" can be implemented using classical tags, like for any
> other programming language.
We NetBeans users don't have to implement it at all, nor worry our heads
about editor internals like "classical tags" (whatever those are). We
just right click and away we go, without any mess or fuss.
> Getting the documentation and seeing the expansions are primitive
> feature of the Common Lisp language. Trivial.
There are two problems with this statement. First, getting the
documentation seems to presuppose there is some. I've seen a fair bit of
Lisp code in my time, but never has any piece of it had anything
recognizable as some kind of doc comment attached to it. If there is any
documentation, it apparently has to be searched manually, and being
maintained separately from the source code, is liable to be out of synch
with the codebase at any given time.
Second, as Series was trying to point out (but you misunderstood), the
command to expand the macro in-place, when used to simply see how it
expands in a particular place, has the side effect of actually modifying
the source code in the editor. If that modification is saved, the macro
expansion is now "baked in" at that one location, and won't reflect
future changes to the macro's definition. So things once again drift out
of synch.
Series noted that a hypothetical NetBeans-like IDE for Lisp would have
the capability, unlike a text editor, to show the results of the
expansion in some sort of pop-over or tooltip or balloon help instead of
having only one place to put it, in the source code itself. As a result,
one could have a "view what this looks like expanded" command that was
actually a non-modifying operation, instead of having to (ab)use the
modifying operation "replace this macro call with its expansion"
(preferably immediately followed by "undo"!) to achieve the desired effect.
I'll note though that the implied lack of such an IDE is not inherently
a problem with the Lisp language itself; one could be written. A
NetBeans plugin could probably even be written. Or an Eclipse one for
people that swing that way. :)
> There's no need for an IDE.
Spoken like someone who's never had to do any REAL programming. :)
> So it's rather trivial to have a simple editor like emacs (or
> even simplier) to get the documentation of lisp operators or to expand
> a macro.
"Rather trivial" if you like to spend as much time or more programming
the editor as you do actually programming what you're being paid to
program -- and your boss likes you dividing your time that way, too.
Oh, and making mistakes by using "replace this macro call with its
expansion" but forgetting the subsequent "undo", which mistake silently
cause no symptoms until days, weeks, or even years in the future when
the macro definition is changed and something suddenly doesn't quite
work right, and after tearing your hair out for hours you still can't
find any error in the new macro definition, never suspecting that the
error lies somewhere else entirely because the macro definition is the
only recent change.
>> 2. At one point, something goes wrong so you hit a "small sequence of
>> keystrokes" to do an in-place replacement of a call to that macro
>> with its expansion.
>
> Why would we do that? That would mean shooting in one's foot. Nobody
> would do that.
Apparently, the person Series was responding to would do that.
That person seems to go by the name "gugamilare". If you'd like to tell
him what a horrible kludge it is to use "replace macro with expansion"
as a poor-man's "view this macro call's expansion" due to lack of a
graphical IDE, well, go right on ahead. I wholeheartedly agree with that
sentiment.
>> Show me one of those, and I'll show you a headline from the future:
>> "Over sixty thousand customers in the dark after catastrophic computer
>> failure at power distribution center", "Over three hundred million
>> awarded in class-action suit over defective products caused by process
>> control computer error", "One person dead after ill-timed heart attack
>> during last night's six-hour 911 outage", "E-commerce giant courting
>> bankruptcy after catastrophic three-week Web site downtime", or
>> something along those lines.
>
> In really, such a mission-critical system was developed by Paul
> Graham, and sold to Yahoo for a fortune, which used it without such a
> catastrophe. http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
Somehow, I doubt Yahoo abandoned all their change-management and
version-control practises and just started hacking on their servers
while they were live. If they'd done that, Series is right about the
likely outcome: some sort of at least downtime, if not a big data loss
or other disaster.
> Another example, is the debugging of the OS code of the Deep Space 1
> code when it was millions of kilometers from the Earth. Again, the
> modifications were made on a running program without outage, and even
> without physical access to computer.
That's a rather unusual, special case. Also, I expect they did this
while it was coasting in the vastness of space, so nothing could go too
horribly wrong too quickly so long as they didn't render it unable to
receive and execute commands or become unbootable.
They were also probably very careful indeed; I expect they tested their
changes in a simulator of some sort groundside before beaming any code
modifications to the probe. NASA doesn't take the preservation of
multi-billion-dollar machinery lightly, I expect.
>>> How about saving your changes in a file before you load them???
>> These were changes being made to the copy of the program running in
>> RAM using the debugging tools, remember? Not to the source code on
>> disk.
>
> Well probably lisp programmers are smarter. For sure you make us
> think so. Is it so hard a concept to make the modifications both in
> the running lisp image and in some persistent storage?
Well, now you're making changes in two places at once. Better not forget
one, or make slightly different changes to both.
> This is actually the normal work flow of a lisp programmer: he will
> edit the source file in emacs, type C-x C-b which will ask slime to
> send the file to the running lisp image, which updates it.
Who are you calling slime, ooze? :)
But if you are editing the source file and then copying the changes to
the running image, that's a bit better since they shouldn't get out of
synch nor any changes be lost. Gugamilare apparently told Series he just
edits the running image and where it stops, no-one knows.
The stuff Series said about keeping separate testing and production
systems, only hacking on the former, and having some sort of version
control seems to stand though. Editing text files on disk does not scale
up to a major software project's development practises; you'll spend
more time using the command line to check in and check out than you
spend editing, testing, or compiling anything. NetBeans provides
integration with multiple widely-used version control systems, by
contrast -- you can edit the file and save it and it can more or less
transparently commit the changes to the repository, maybe prompting you
for a change summary, as well as check out files you browse to.
Meanwhile browsing a manually-maintained mirror on your hard drive means
sometimes seeing code that's out of date, if you forget to re-checkin a
file you haven't viewed in a while.
NetBeans also provides an internal, lightweight version control system
that can recall or undo the changes to a local codebase over the past
week or so. It also can show you diffs of your recent changes in an
easy-to-read way. Quite handy, actually, and way beyond the capabilities
of a mere text editor. Particularly, the NetBeans diff-viewer could
never be even approximated in a text console no matter how fancy you got
with ncurses. You can see at a glance corresponding parts of both
versions, highlighted to indicate what corresponds, what's inserted,
what's removed, and everything, even around parts that have gotten a
fair bit longer or shorter. Lines marking corresponding bits may be
diagonal, at angles you could never manage using /-\|. And it's
*stretchy* in a way that no rigid grid of letters and numbers could ever
be. :)
On May 15, 8:09 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pascal J. Bourguignon wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> And now you've replaced a bit of your code with the expanded version.
> >> Later you'll change the macro for whatever reason, but at this one
> >> spot the change won't be applied since the macro call was replaced
> >> with its expansion in your editor at that spot. That copy now gets out
> >> of synch with the rest of the code.
>
> > You are so confused! The macros are not expanded by the editor!
>
> Eh. That wasn't my interpretation of the OP's post. He was responding to
> this:
>
> "Macros are not a source of headaches in CL because they are most times
> as simple as a normal function. And you can always expand the code
> directly from the source (by hitting a small sequence of keystrokes) if
> you thing it has a bug somewhere."
>
> where someone said if he suspected a macro was buggy he'd type something
> in his IDE that would cause the macro to be expanded in-place.
>
It probably doesn't work like that.
Cue benny hill music if it does..
> Series is pointing out that if he then went off to fix the bug in the
> macro, but forgot to return to that other part of the code to change the
> expanded code back into a macro call, then there's two copies of the
> macro code -- the macro, and the one particular application of it that
> was replaced in the code editor with its expansion pre-compilation.
>
> As I understand it, he's saying the compiler still expands the macro at
> all its other usage sites.
>
> The C equivalent (I'm more familiar with C than Lisp) would be:
>
This is where you are going wrong.
Lisp macros and C macros are not equivalent.
> You have
>
> #define DOIT(x,y) ((x)+(y)+(y))
>
> Later you find a bug at
>
> DOIT(a,b++)
>
> where b is getting incremented twice instead of once.
>
> You do whatever it is and the code there changes to
>
> ((a) + (b++) + (b++))
>
> and realize why b is being incremented twice. You remove the "++" from
> the first "b" and then zip back up to the top of the file to change the
> macro definition to:
>
> #define DOIT(x,y) ((x)+2*(y))
>
> feeling secure in the knowledge that everything used with DOIT can be
> multiplied by two (there's no string "+" concatenation operator in C).
>
> Later, there's a decision made to change it to ((x)+3*(y)). In most
> locations in the code where it "does it", the compiler dutifully expands
> DOIT(foo,bar) into ((foo)+3*(bar)).
>
> But in one lonely spot the code still reads ((a) + (b) + (b++)).
>
> So b is still multiplied by two, instead of three, there.
>
> Bit of a contrived example? Maybe. But I think this is what Series was
> getting at. Maybe he's misunderstanding something somewhere, but I think
> you definitely are.
>
> > The only thing you have to do when you change a macro, is to recompile
> > the functions that use it. This is easily done automatically by
> > putting macros in a separate source file and defining correctly the
> > dependencies of the other files.
>
> In the practical software development world, we have long since adopted
> tools that track dependencies for us more or less automatically (Java
> has the niggling "public static final field problem" though). Your
> manual tracking of dependencies would not scale to a real-world
> productive code shop in a major company or major open source project.
>
> >> Of course, a proper IDE should let you right click on the macro call
> >> and get a menu with options like "go to definition", "view
> >> documentation", and "see expansion in a pop-over window WITHOUT
> >> altering the code in your source file". For that you need something
> >> obviously way more sophisticated than what you're describing, which
> >> ("small sequence of keystrokes") sounds suspiciously like emacs.
>
> > "Go to definition" can be implemented using classical tags, like for any
> > other programming language.
>
> We NetBeans users don't have to implement it at all, nor worry our heads
> about editor internals like "classical tags" (whatever those are). We
> just right click and away we go, without any mess or fuss.
>
> > Getting the documentation and seeing the expansions are primitive
> > feature of the Common Lisp language. Trivial.
>
> There are two problems with this statement. First, getting the
> documentation seems to presuppose there is some. I've seen a fair bit of
> Lisp code in my time, but never has any piece of it had anything
> recognizable as some kind of doc comment attached to it. If there is any
> documentation, it apparently has to be searched manually, and being
> maintained separately from the source code, is liable to be out of synch
> with the codebase at any given time.
>
> Second, as Series was trying to point out (but you misunderstood), the
> command to expand the macro in-place, when used to simply see how it
> expands in a particular place, has the side effect of actually modifying
> the source code in the editor. If that modification is saved, the macro
> expansion is now "baked in" at that one location, and won't reflect
> future changes to the macro's definition. So things once again drift out
> of synch.
>
> Series noted that a hypothetical NetBeans-like IDE for Lisp would have
> the capability, unlike a text editor, to show the results of the
> expansion in some sort of pop-over or tooltip or balloon help instead of
> having only one place to put it, in the source code itself. As a result,
> one could have a "view what this looks like expanded" command that was
> actually a non-modifying operation, instead of having to (ab)use the
> modifying operation "replace this macro call with its expansion"
> (preferably immediately followed by "undo"!) to achieve the desired effect.
>
> I'll note though that the implied lack of such an IDE is not inherently
> a problem with the Lisp language itself; one could be written. A
> NetBeans plugin could probably even be written. Or an Eclipse one for
> people that swing that way. :)
>
> > There's no need for an IDE.
>
> Spoken like someone who's never had to do any REAL programming. :)
>
> > So it's rather trivial to have a simple editor like emacs (or
> > even simplier) to get the documentation of lisp operators or to expand
> > a macro.
>
> "Rather trivial" if you like to spend as much time or more programming
> the editor as you do actually programming what you're being paid to
> program -- and your boss likes you dividing your time that way, too.
>
> Oh, and making mistakes by using "replace this macro call with its
> expansion" but forgetting the subsequent "undo", which mistake silently
> cause no symptoms until days, weeks, or even years in the future when
> the macro definition is changed and something suddenly doesn't quite
> work right, and after tearing your hair out for hours you still can't
> find any error in the new macro definition, never suspecting that the
> error lies somewhere else entirely because the macro definition is the
> only recent change.
>
> >> 2. At one point, something goes wrong so you hit a "small sequence of
> >> keystrokes" to do an in-place replacement of a call to that macro
> >> with its expansion.
>
> > Why would we do that? That would mean shooting in one's foot. Nobody
> > would do that.
>
> Apparently, the person Series was responding to would do that.
>
> That person seems to go by the name "gugamilare". If you'd like to tell
> him what a horrible kludge it is to use "replace macro with expansion"
> as a poor-man's "view this macro call's expansion" due to lack of a
> graphical IDE, well, go right on ahead. I wholeheartedly agree with that
> sentiment.
>
> >> Show me one of those, and I'll show you a headline from the future:
> >> "Over sixty thousand customers in the dark after catastrophic computer
> >> failure at power distribution center", "Over three hundred million
> >> awarded in class-action suit over defective products caused by process
> >> control computer error", "One person dead after ill-timed heart attack
> >> during last night's six-hour 911 outage", "E-commerce giant courting
> >> bankruptcy after catastrophic three-week Web site downtime", or
> >> something along those lines.
>
> > In really, such a mission-critical system was developed by Paul
> > Graham, and sold to Yahoo for a fortune, which used it without such a
> > catastrophe.http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
>
> Somehow, I doubt Yahoo abandoned all their change-management and
> version-control practises and just started hacking on their servers
> while they were live. If they'd done that, Series is right about the
> likely outcome: some sort of at least downtime, if not a big data loss
> or other disaster.
>
> > Another example, is the debugging of the OS code of the Deep Space 1
> > code when it was millions of kilometers from the Earth. Again, the
> > modifications were made on a running program without outage, and even
> > without physical access to computer.
>
> That's a rather unusual, special case. Also, I expect they did this
> while it was coasting in the vastness of space, so nothing could go too
> horribly wrong too quickly so long as they didn't render it unable to
> receive and execute commands or become unbootable.
>
> They were also probably very careful indeed; I expect they tested their
> changes in a simulator of some sort groundside before beaming any code
> modifications to the probe. NASA doesn't take the preservation of
> multi-billion-dollar machinery lightly, I expect.
>
> >>> How about saving your changes in a file before you load them???
> >> These were changes being made to the copy of the program running in
> >> RAM using the debugging tools, remember? Not to the source code on
> >> disk.
>
> > Well probably lisp programmers are smarter. For sure you make us
> > think so. Is it so hard a concept to make the modifications both in
> > the running lisp image and in some persistent storage?
>
> Well, now you're making changes in two places at once. Better not forget
> one, or make slightly different changes to both.
>
> > This is actually the normal work flow of a lisp programmer: he will
> > edit the source file in emacs, type C-x C-b which will ask slime to
> > send the file to the running lisp image, which updates it.
>
> Who are you calling slime, ooze? :)
>
> But if you are editing the source file and then copying the changes to
> the running image, that's a bit better since they shouldn't get out of...
>
> read more »
Its nice out so I didn't read the rest of this, sorry. :-)
You all have a nice flame war.
··················@gmail.com wrote:
> On May 15, 8:09 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pascal J. Bourguignon wrote:
>>> Series Expansion <·······@gmail.com> writes:
>>>> And now you've replaced a bit of your code with the expanded version.
>>>> Later you'll change the macro for whatever reason, but at this one
>>>> spot the change won't be applied since the macro call was replaced
>>>> with its expansion in your editor at that spot. That copy now gets out
>>>> of synch with the rest of the code.
>>> You are so confused! The macros are not expanded by the editor!
>> Eh. That wasn't my interpretation of the OP's post. He was responding to
>> this:
>>
>> "Macros are not a source of headaches in CL because they are most times
>> as simple as a normal function. And you can always expand the code
>> directly from the source (by hitting a small sequence of keystrokes) if
>> you thing it has a bug somewhere."
>>
>> where someone said if he suspected a macro was buggy he'd type something
>> in his IDE that would cause the macro to be expanded in-place.
>>
> It probably doesn't work like that.
> Cue benny hill music if it does..
Someone -- gugamilare? -- seemed to think it did.
>> The C equivalent (I'm more familiar with C than Lisp) would be:
>
> This is where you are going wrong.
> [flamage]
> [tons of untrimmed quoted text]
>
> Its nice out so I didn't read the rest of this, sorry. :-)
>
> You all have a nice flame war.
A drive-by! Why, of all the dirty, rotten, low-down ... !
On May 15, 9:48 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> ··················@gmail.com wrote:
> > On May 15, 8:09 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Pascal J. Bourguignon wrote:
> >>> Series Expansion <·······@gmail.com> writes:
> >>>> And now you've replaced a bit of your code with the expanded version.
> >>>> Later you'll change the macro for whatever reason, but at this one
> >>>> spot the change won't be applied since the macro call was replaced
> >>>> with its expansion in your editor at that spot. That copy now gets out
> >>>> of synch with the rest of the code.
> >>> You are so confused! The macros are not expanded by the editor!
> >> Eh. That wasn't my interpretation of the OP's post. He was responding to
> >> this:
>
> >> "Macros are not a source of headaches in CL because they are most times
> >> as simple as a normal function. And you can always expand the code
> >> directly from the source (by hitting a small sequence of keystrokes) if
> >> you thing it has a bug somewhere."
>
> >> where someone said if he suspected a macro was buggy he'd type something
> >> in his IDE that would cause the macro to be expanded in-place.
>
> > It probably doesn't work like that.
> > Cue benny hill music if it does..
>
> Someone -- gugamilare? -- seemed to think it did.
>
> >> The C equivalent (I'm more familiar with C than Lisp) would be:
>
> > This is where you are going wrong.
> > [flamage]
> > [tons of untrimmed quoted text]
>
> > Its nice out so I didn't read the rest of this, sorry. :-)
>
> > You all have a nice flame war.
>
> A drive-by! Why, of all the dirty, rotten, low-down ... !
Just because you insert [flame] or [flammage] somewhere, doesn't make
it so.
I apologise if you mistook my comments.
Have a nice day.
··················@gmail.com wrote:
> On May 15, 9:48 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> A drive-by! Why, of all the dirty, rotten, low-down ... !
>
> Just because you insert [flame] or [flammage] somewhere, doesn't make
> it so.
Are you calling me a liar?
> I apologise if you mistook my comments.
I did not.
On May 15, 8:09 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pascal J. Bourguignon wrote:
> > There's no need for an IDE.
>
> Spoken like someone who's never had to do any REAL programming. :)
Oh, here we go. Flamewar. FLAMEWAR!
I suppose it was inevitable. We have all the ingredients of the Usenet
Fire Triangle together here don't we? Lisp vs. Java. Netbeans vs.
Eclipse vs. emacs, no doubt with a vi-lover about to jump in and offer
to show us what's behind door number four. Dynamic vs. static typing,
too. Now all we need is for someone to mention "gun control", or
"abortion", or 9/11, and ...
oops
Dangling Pointer wrote:
> On May 15, 8:09 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pascal J. Bourguignon wrote:
>>> There's no need for an IDE.
>> Spoken like someone who's never had to do any REAL programming. :)
>
> Oh, here we go. Flamewar. FLAMEWAR!
>
> I suppose it was inevitable. We have all the ingredients of the Usenet
> Fire Triangle together here don't we? Lisp vs. Java. Netbeans vs.
> Eclipse vs. emacs, no doubt with a vi-lover about to jump in and offer
> to show us what's behind door number four. Dynamic vs. static typing,
> too. Now all we need is for someone to mention "gun control", or
> "abortion", or 9/11, and ...
>
> oops
rofl
Seamus MacRae <··········@live.ca.nospam> writes:
> Pascal J. Bourguignon wrote:
>> Series Expansion <·······@gmail.com> writes:
>>> And now you've replaced a bit of your code with the expanded version.
>>> Later you'll change the macro for whatever reason, but at this one
>>> spot the change won't be applied since the macro call was replaced
>>> with its expansion in your editor at that spot. That copy now gets out
>>> of synch with the rest of the code.
>> You are so confused! The macros are not expanded by the editor!
>
> Eh. That wasn't my interpretation of the OP's post.
Ok, I was confused then.
> He was responding
> to this:
>
> "Macros are not a source of headaches in CL because they are most
> times as simple as a normal function. And you can always expand the
> code directly from the source (by hitting a small sequence of
> keystrokes) if you thing it has a bug somewhere."
>
> where someone said if he suspected a macro was buggy he'd type
> something in his IDE that would cause the macro to be expanded
> in-place.
Ok, but he didn't mean to modify the source. Only that if you have a
doubt about the correct behavior of the macro, you can obtain the
expansion of one of it's invocations to check that the correct code is
generated. (And if not, you go to the source of the macro to modify
it). The generated code doesn't replace the macro invocation in the
source, such results are displayed in the mini buffer of emacs, which
is transient.
> [...]
> As I understand it, he's saying the compiler still expands the macro
> at all its other usage sites.
Yes, that's it.
> The C equivalent (I'm more familiar with C than Lisp) would be:
>
> You have
>
> #define DOIT(x,y) ((x)+(y)+(y))
>
> Later you find a bug at
>
> DOIT(a,b++)
> [...]
Emacs provides the same feature for cpp: you can select a region
containing macros calls in a C or C++ buffer and use the
c-macro-expand command to have it send the #includes and the selected
text to the C pre-processor, and display the result to another
temporary buffer.
> Bit of a contrived example? Maybe. But I think this is what Series was
> getting at. Maybe he's misunderstanding something somewhere, but I
> think you definitely are.
>> The only thing you have to do when you change a macro, is to recompile
>> the functions that use it. This is easily done automatically by
>> putting macros in a separate source file and defining correctly the
>> dependencies of the other files.
>
> In the practical software development world, we have long since
> adopted tools that track dependencies for us more or less
> automatically (Java has the niggling "public static final field
> problem" though). Your manual tracking of dependencies would not scale
> to a real-world productive code shop in a major company or major open
> source project.
Who said it was manual? I didn't mention make or ant because that's
not what would be used on a lisp project, but there are tools with
equivalent features.
And don't worry about real-world productive lisp code shops, they do
perfectly well, thank for them. (Even if there's not a lot of them,
they still develop software as big as any other).
>>> Of course, a proper IDE should let you right click on the macro call
>>> and get a menu with options like "go to definition", "view
>>> documentation", and "see expansion in a pop-over window WITHOUT
>>> altering the code in your source file". For that you need something
>>> obviously way more sophisticated than what you're describing, which
>>> ("small sequence of keystrokes") sounds suspiciously like emacs.
>> "Go to definition" can be implemented using classical tags, like for
>> any
>> other programming language.
>
> We NetBeans users don't have to implement it at all, nor worry our
> heads about editor internals like "classical tags" (whatever those
> are). We just right click and away we go, without any mess or fuss.
Neither lisp programmers: these features are provided by any
programmer editor such as emacs. There's nothing to be done.
>> Getting the documentation and seeing the expansions are primitive
>> feature of the Common Lisp language. Trivial.
>
> There are two problems with this statement. First, getting the
> documentation seems to presuppose there is some.
I don't presuppose that there is no documentation of your java codes,
so don't presuppose that there's no documentaiton of my lisp codes.
> I've seen a fair bit
> of Lisp code in my time, but never has any piece of it had anything
> recognizable as some kind of doc comment attached to it.
I saw no more documentation of the java code I had the occasion to see.
> If there is
> any documentation, it apparently has to be searched manually, and
> being maintained separately from the source code, is liable to be out
> of synch with the codebase at any given time.
You can always do things manually, you seem to like it...
> Second, as Series was trying to point out (but you misunderstood), the
> command to expand the macro in-place,
It is called in place, but doesn't replace in-place.
> when used to simply see how it
> expands in a particular place, has the side effect of actually
> modifying the source code in the editor.
I know of no lisp IDE having this feature.
> [...]
> Series noted that a hypothetical NetBeans-like IDE for Lisp would have
Lisp IDEs are not hypothetical.
> the capability, unlike a text editor, to show the results of the
> expansion in some sort of pop-over or tooltip or balloon help instead
> of having only one place to put it, in the source code itself.
Has anybody said it was otherwise?
> As a
> result, one could have a "view what this looks like expanded" command
> that was actually a non-modifying operation, instead of having to
> (ab)use the modifying operation "replace this macro call with its
> expansion" (preferably immediately followed by "undo"!) to achieve the
> desired effect.
Such a feature has never been described.
> [...]
>> There's no need for an IDE.
>
> Spoken like someone who's never had to do any REAL programming. :)
Yes, I've been programming professionnaly for 27 years, that must have
been IMAGINARY. Have you a -i to spare?
>> So it's rather trivial to have a simple editor like emacs (or
>> even simplier) to get the documentation of lisp operators or to expand
>> a macro.
>
> "Rather trivial" if you like to spend as much time or more programming
> the editor as you do actually programming what you're being paid to
> program -- and your boss likes you dividing your time that way, too.
No, as trivial as using the simple features provided with emacs, or as
downloading the slime IDE and using its more sophisticated but simple
to use features. Or as simple as downloading a commercial IDE from
one of the various Common Lisp implementation vendors.
> [...]
> But if you are editing the source file and then copying the changes to
> the running image, that's a bit better since they shouldn't get out of
> synch nor any changes be lost. Gugamilare apparently told Series he
> just edits the running image and where it stops, no-one knows.
The point is that the tools renders the bookkeeping so oblivious that
it feels like if you are just editing the running image, but you're
working from emacs, so what you are always editing are local files.
> The stuff Series said about keeping separate testing and production
> systems, only hacking on the former, and having some sort of version
> control seems to stand though. Editing text files on disk does not
> scale up to a major software project's development practises; you'll
> spend more time using the command line to check in and check out than
What CLI?
> you spend editing, testing, or compiling anything. NetBeans provides
> integration with multiple widely-used version control systems,
Where do you think NetBeans developers got the idea from? Where these
developers even _born_ when emacs was created?
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
> [lots of back-and-forth]
>
> Emacs provides the same feature for cpp: you can select a region
> containing macros calls in a C or C++ buffer and use the
> c-macro-expand command to have it send the #includes and the selected
> text to the C pre-processor, and display the result to another
> temporary buffer.
Ah, regions and temporary buffers! How quaint.
Here in the 21st century we have balloon help and the ability to overlap
windows with one another. :)
>>> The only thing you have to do when you change a macro, is to recompile
>>> the functions that use it. This is easily done automatically by
>>> putting macros in a separate source file and defining correctly the
>>> dependencies of the other files.
>> In the practical software development world, we have long since
>> adopted tools that track dependencies for us more or less
>> automatically (Java has the niggling "public static final field
>> problem" though). Your manual tracking of dependencies would not scale
>> to a real-world productive code shop in a major company or major open
>> source project.
>
> Who said it was manual?
You said something about putting macros in a separate source file "and
defining correctly the dependencies of the other files". Sounds like you
need to stick (defdependency foo bar) type thingies in "the other
files", which sure seems manual to me.
>>> "Go to definition" can be implemented using classical tags, like for
>>> any other programming language.
>>
>> We NetBeans users don't have to implement it at all, nor worry our
>> heads about editor internals like "classical tags" (whatever those
>> are). We just right click and away we go, without any mess or fuss.
>
> Neither lisp programmers: these features are provided by any
> programmer editor such as emacs. There's nothing to be done.
Oh? You said earlier, that it "can be implemented using" technical stuff
etc. etc. yadda yadda yadda. I'd rather spend my time implementing what
my boss is paying me to implement than implementing my own half-assed
pseudo-IDE with some editor's scripting language.
>>> Getting the documentation and seeing the expansions are primitive
>>> feature of the Common Lisp language. Trivial.
>> There are two problems with this statement. First, getting the
>> documentation seems to presuppose there is some.
>
> I don't presuppose that there is no documentation of your java codes,
> so don't presuppose that there's no documentaiton of my lisp codes.
My Java codes (note: capitalization) had documentation right there in
them when I posted them. Your lisp codes had none. Unless maybe all
those parentheses somehow constitute the documentation. :)
>> I've seen a fair bit
>> of Lisp code in my time, but never has any piece of it had anything
>> recognizable as some kind of doc comment attached to it.
>
> I saw no more documentation of the java code I had the occasion to see.
Try turning the contrast knob to the right, and then reread the post of
mine that somebody characterized as a "piece of vomit" earlier today.
>> Second, as Series was trying to point out (but you misunderstood), the
>> command to expand the macro in-place,
>
> It is called in place, but doesn't replace in-place.
What, you mean that guy's editor's user interface lies to the user? WTF?
>> when used to simply see how it
>> expands in a particular place, has the side effect of actually
>> modifying the source code in the editor.
>
> I know of no lisp IDE having this feature.
Well, gugamilare apparently does, so that makes one of you.
>> Series noted that a hypothetical NetBeans-like IDE for Lisp would have
>
> Lisp IDEs are not hypothetical.
Eh. I'll believe that when I see one. (And no, a text editor with
delusions of grandeur is not an IDE.)
>> the capability, unlike a text editor, to show the results of the
>> expansion in some sort of pop-over or tooltip or balloon help instead
>> of having only one place to put it, in the source code itself.
>
> Has anybody said it was otherwise?
Well, certainly the curses-based editors you lot all seem to be using
wouldn't know balloon help even if it fell from the sky and knocked
their neat little grids of ASCII characters all out of whack. :)
>> As a
>> result, one could have a "view what this looks like expanded" command
>> that was actually a non-modifying operation, instead of having to
>> (ab)use the modifying operation "replace this macro call with its
>> expansion" (preferably immediately followed by "undo"!) to achieve the
>> desired effect.
>
> Such a feature has never been described.
I think gugamilare might have some objections to your implied claim that
one of his news-posts doesn't exist.
>>> There's no need for an IDE.
>> Spoken like someone who's never had to do any REAL programming. :)
>
> Yes, I've been programming professionnaly for 27 years, that must have
> been IMAGINARY. Have you a -i to spare?
Will it annihilate you? It sounds like it might be your antiparticle,
and I wouldn't want to have a murder rap hanging over my head. Well,
maybe just negligent homicide or something. :)
>>> So it's rather trivial to have a simple editor like emacs (or
>>> even simplier) to get the documentation of lisp operators or to expand
>>> a macro.
>> "Rather trivial" if you like to spend as much time or more programming
>> the editor as you do actually programming what you're being paid to
>> program -- and your boss likes you dividing your time that way, too.
>
> No, as trivial as using the simple features provided with emacs, or as
> downloading the slime IDE and using its more sophisticated but simple
> to use features.
Slime IDE. Well, that's probably a step up from emacs, though I'll bet
dollars to doughnuts it's no NetBeans.
>> But if you are editing the source file and then copying the changes to
>> the running image, that's a bit better since they shouldn't get out of
>> synch nor any changes be lost. Gugamilare apparently told Series he
>> just edits the running image and where it stops, no-one knows.
>
> The point is that the tools renders the bookkeeping so oblivious that
> it feels like if you are just editing the running image, but ...
If I liked using tools that render me oblivious to live dangerously, I'd
fly a Cessna while wearing dark glasses.
Thanks, but no thanks.
If flying blind is your kick, all the power to you. I'll stick with my
NetBeans, which never leaves me in any doubt as to where anything is or
where any changes are going, and which nicely interoperates with svn.
>> The stuff Series said about keeping separate testing and production
>> systems, only hacking on the former, and having some sort of version
>> control seems to stand though. Editing text files on disk does not
>> scale up to a major software project's development practises; you'll
>> spend more time using the command line to check in and check out than
>
> What CLI?
Well, that would depend. On our Windows machines, we use the lame
Windows command.com most of the time, but occasionally some enterprising
soul seems to have a Windows port of bash. The Unix wizards running the
server room seem to prefer bash, with the odd ksh or csh user. Not that
it really matters, the svn commands to check in and check out files in
the repositories are pretty much the same whichever shell is used.
Most of us use IDEs that talk directly to the repository anyway, saving
us the bother.
>> you spend editing, testing, or compiling anything. NetBeans provides
>> integration with multiple widely-used version control systems,
>
> Where do you think NetBeans developers got the idea from?
Probably from Eclipse.
> Where these developers even _born_ when emacs was created?
Probably some of them were and some of them were not. Not that legacy
applications are really our forte. We're not an old enough shop for
that. I think some of the unix guys that manage the web servers use vi,
and other deep wizard stuff, but us programmers prefer full-featured
IDEs with modern user interfaces, not to mention language-aware search,
svn integration, and all sorts of other bells and whistles you won't
find even in a modern programmer's text editor, let alone in things like
Editpad and MacWrite, or thirty-year-old curses-based museum-pieces, or
forty-year-old line editors, or fifty-year-old card punches.
On May 16, 5:16 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> You said something about putting macros in a separate source file "and
> defining correctly the dependencies of the other files". Sounds like you
> need to stick (defdependency foo bar) type thingies in "the other
> files", which sure seems manual to me.
There is a very minimal amount of dependency-defining. Defining
packages in Lisp used to be a task involving several different
functions, until it was standardized into a system using -- guess
what? -- a handful of macros that do the job very powerfully and
concisely.
> Oh? You said earlier, that it "can be implemented using" technical stuff
> etc. etc. yadda yadda yadda. I'd rather spend my time implementing what
> my boss is paying me to implement than implementing my own half-assed
> pseudo-IDE with some editor's scripting language.
This is where something like SLIME comes in.
Superior Lisp Integration Mode for Emacs is, essentially, a set of
options and scripts for Emacs that turn it into a Lisp IDE. While you
can't have minor cosmetic features such as help bubbles and popping
things into half a trillion windows all over your screen, you CAN:
- Compile files as you work on them, or choose specific functions to
compile separately.
- Run a Lisp image so that you can test out new ideas and debug your
code as you write it.
- View macroexpansions.
- Jump to source definitions for functions and macros.
- Perform sophisticated function tracing and cross-referencing for
debugging.
- When you compile and the compiler has warnings, the warnings show
up in the relevant places in the source code.
- With two mouse clicks, you can deal with checking parenthesis
matching, updating indentations, etc -- in other words, you have to
manually deal with less syntax than a Python programmer does.
I'm not gonna go into a whole list of features here, but basically,
SLIME turns Notepad into NetBeans.
> >>> Getting the documentation and seeing the expansions are primitive
> >>> feature of the Common Lisp language. Trivial.
> >> There are two problems with this statement. First, getting the
> >> documentation seems to presuppose there is some.
>
> > I don't presuppose that there is no documentation of your java codes,
> > so don't presuppose that there's no documentaiton of my lisp codes.
>
> My Java codes (note: capitalization) had documentation right there in
> them when I posted them. Your lisp codes had none. Unless maybe all
> those parentheses somehow constitute the documentation. :)
EVERY SINGLE Lisp form that "defines" something -- be it a function,
macro, class (even slots within a class get this), constant, etc --
has a syntax for adding documentation. It's good style to add
documentation in exactly the same way that it's good style to add
documentation to programs in Java, C, or any other language.
Some examples:
(defun foo (bar)
"Returns the foorier transform of bar"
(form1)
(form2)
... etc)
(defvar *users* NIL
"A list of all the users of the system")
(defclass programmer (engineer designer)
((languages
:documentation "A list of the languages the programmer is
'fluent' in.")
(current-project
:documentation "The project that this programmer spends most of
his time on."))
(:documentation "The programmer class. Inherits from the classes
Engineer and Designer."))
Lisp also has comment syntax, just like any other language. You can
intersperse comments anywhere in your code.
(defun tr-fact (n &optional (acc 1))
"A tail-recursive factorial function" ; This line has both
documentation and a comment
(if (= n 1)
acc ; Factorial value is accumulated in
variable
(tr-fact (1- n) ; ACC as the function recurses. This is
done
(* n acc)))) ; to facilitate tail recursion.
Whether you comment and document your code in great detail or not
depends on you, and your taste, not on the language you're using.
There's a function that's part of the Common Lisp standard, for
retrieving documentation for a function, class, variable, etc. If the
person who wrote the libraries you're using wrote documentation,
you'll be able to read it. Good IDEs for Lisp provide quick ways to
access documentation, so that you just select a function and you can
view the docstring for it.
> >> Second, as Series was trying to point out (but you misunderstood), the
> >> command to expand the macro in-place,
>
> > It is called in place, but doesn't replace in-place.
>
> What, you mean that guy's editor's user interface lies to the user? WTF?
Capsule summary of Lisp macros:
A macro call doesn't change your source code. The macro changes the
code once it's being compiled or interpreted. When you write (some-
macro-call foozbozz (a b c) (print foo)), that is what will stay in
your source files until you manually change it. Macros work their
magic once you send that form to be compiled or evaluated. Although
SLIME is aware of macro calls and formats them differently from
function calls, the place where "in-place" macroexpansion happens is
in the compiler.
However, there is a way to view the code that a macro call expands
into, if you want to view it to catch that one bug and fix 50 errors
at once. This is part of the CL standard, it's a function called
MACROEXPAND that displays the expansion of a macro call which you pass
as its argument, and it's also a command supported by most Lisp IDEs.
> >> Series noted that a hypothetical NetBeans-like IDE for Lisp would have
>
> > Lisp IDEs are not hypothetical.
>
> Eh. I'll believe that when I see one. (And no, a text editor with
> delusions of grandeur is not an IDE.)
Emacs is just a text editor. Emacs + SLIME is a full-fledged IDE.
> >> the capability, unlike a text editor, to show the results of the
> >> expansion in some sort of pop-over or tooltip or balloon help instead
> >> of having only one place to put it, in the source code itself.
>
> > Has anybody said it was otherwise?
>
> Well, certainly the curses-based editors you lot all seem to be using
> wouldn't know balloon help even if it fell from the sky and knocked
> their neat little grids of ASCII characters all out of whack. :)
Firstly, in SLIME, when you use various IDE options, they usually open
apart from the source code.
Secondly, commercial IDEs actually -- big surprise -- do use separate
windows for stuff!
> Will it annihilate you? It sounds like it might be your antiparticle,
> and I wouldn't want to have a murder rap hanging over my head. Well,
> maybe just negligent homicide or something. :)
Seamus, for someone who started out their posts criticising people for
flaming, you're starting to seem a bit hypocritical. I know this
sounds like giving advice to a 6yo kid, but -- if someone starts
taunting you, that's no reason to send it back. If you think they
don't understand something you tried to say -- as I think that some
people posting here aren't familiar with the differences between Lisp
as it was in 1958, and Common Lisp as it is today -- then just
patiently try to clear up any misunderstandings, ok? :)
> >>> So it's rather trivial to have a simple editor like emacs (or
> >>> even simplier) to get the documentation of lisp operators or to expand
> >>> a macro.
> >> "Rather trivial" if you like to spend as much time or more programming
> >> the editor as you do actually programming what you're being paid to
> >> program -- and your boss likes you dividing your time that way, too.
>
> > No, as trivial as using the simple features provided with emacs, or as
> > downloading the slime IDE and using its more sophisticated but simple
> > to use features.
>
> Slime IDE. Well, that's probably a step up from emacs, though I'll bet
> dollars to doughnuts it's no NetBeans.
I've addressed this already. It might not have the exact same sugar-
coated bubbles and glossy GUI, but it has very powerful functionality.
You could customize it further if you really wanted to, but SLIME is
like a library of customizations, and it's quite powerful as-is.
> >> you spend editing, testing, or compiling anything. NetBeans provides
> >> integration with multiple widely-used version control systems,
>
> > Where do you think NetBeans developers got the idea from?
>
> Probably from Eclipse.
Not to put words in Pascal's mouth, but I think he's implying that 1)
these ideas originated in Emacs, or early IDEs similar to it, and 2)
functionalities that originated there, are still there today, as
powerful as ever.
I hope I've cleared up a few confusions about the IDE and about macro
expansions.
- Adlai
Seamus MacRae <··········@live.ca.nospam> writes:
> Pascal J. Bourguignon wrote:
>>> The stuff Series said about keeping separate testing and production
>>> systems, only hacking on the former, and having some sort of version
>>> control seems to stand though. Editing text files on disk does not
>>> scale up to a major software project's development practises; you'll
>>> spend more time using the command line to check in and check out than
>> What CLI?
>
> Well, that would depend. On our Windows machines, we use the lame
I meant that NetBeans has exactly the same feature as emacs, nothing
more. AFAIR, emac has been able to checkout and checkin files from
any version control system. There's no need to go to a cli to do
these operations anymore in emacs than in NetBean. And again, guess
who copied who?
>>> you spend editing, testing, or compiling anything. NetBeans provides
>>> integration with multiple widely-used version control systems,
>> Where do you think NetBeans developers got the idea from?
>
> Probably from Eclipse.
No, from emacs.
--
__Pascal Bourguignon__
On May 15, 11:06 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> I meant that NetBeans has exactly the same feature as emacs
uh.
Ah.
AAAACHOOOOO!
Oh, I'm sorry. I'm allergic to bullshit.
(I don't think you can find two more different pieces of software than
NetBeans and emacs!)
Pascal J. Bourguignon wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Pascal J. Bourguignon wrote:
>>>> The stuff Series said about keeping separate testing and production
>>>> systems, only hacking on the former, and having some sort of version
>>>> control seems to stand though. Editing text files on disk does not
>>>> scale up to a major software project's development practises; you'll
>>>> spend more time using the command line to check in and check out than
>>> What CLI?
>> Well, that would depend. On our Windows machines, we use the lame
>
> I meant that NetBeans has exactly the same feature as emacs, nothing
> more.
That's a joke, right? One's a full-blown IDE, the other just a text editor.
>>>> you spend editing, testing, or compiling anything. NetBeans provides
>>>> integration with multiple widely-used version control systems,
>>> Where do you think NetBeans developers got the idea from?
>> Probably from Eclipse.
>
> No, from emacs.
Copying something from emacs is a good way to give your user base a
headache. Especially if it involves "meta" or (n)curses.
On May 15, 11:34 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pascal J. Bourguignon wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
>
> >> Pascal J. Bourguignon wrote:
> >>>> The stuff Series said about keeping separate testing and production
> >>>> systems, only hacking on the former, and having some sort of version
> >>>> control seems to stand though. Editing text files on disk does not
> >>>> scale up to a major software project's development practises; you'll
> >>>> spend more time using the command line to check in and check out than
> >>> What CLI?
> >> Well, that would depend. On our Windows machines, we use the lame
>
> > I meant that NetBeans has exactly the same feature as emacs, nothing
> > more.
>
> That's a joke, right? One's a full-blown IDE, the other just a text editor.
>
> >>>> you spend editing, testing, or compiling anything. NetBeans provides
> >>>> integration with multiple widely-used version control systems,
> >>> Where do you think NetBeans developers got the idea from?
> >> Probably from Eclipse.
>
> > No, from emacs.
>
> Copying something from emacs is a good way to give your user base a
> headache. Especially if it involves "meta" or (n)curses.
I love your posts,
Please never stop.
Seamus MacRae <··········@live.ca.nospam> writes:
> Pascal J. Bourguignon wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>> Pascal J. Bourguignon wrote:
>>>>> The stuff Series said about keeping separate testing and production
>>>>> systems, only hacking on the former, and having some sort of version
>>>>> control seems to stand though. Editing text files on disk does not
>>>>> scale up to a major software project's development practises; you'll
>>>>> spend more time using the command line to check in and check out than
>>>> What CLI?
>>> Well, that would depend. On our Windows machines, we use the lame
>> I meant that NetBeans has exactly the same feature as emacs, nothing
>> more.
>
> That's a joke, right? One's a full-blown IDE, the other just a text editor.
By the way, I'm using emacs to post these newsgroups articles, to read
my email, to browse the web, to chat with irc and jabber, to do my
accounting, to compute my spreadsheets, to manage my address book, and
of course to develop all my programs, including coding, compiling,
debugging.
Can you do only half of that with your "IDE"?
>>>>> you spend editing, testing, or compiling anything. NetBeans provides
>>>>> integration with multiple widely-used version control systems,
>>>> Where do you think NetBeans developers got the idea from?
>>> Probably from Eclipse.
>> No, from emacs.
>
> Copying something from emacs is a good way to give your user base a
> headache. Especially if it involves "meta" or (n)curses.
I don't know why you keep mentionning ncurses. emacs is a GUI
application like any other, it has menus, toolbar, scrollbars, pop-up
dialogs, and runs with any window manager the host system provides,
such as X, Aqua or whatever they have on MS-Windows.
--
__Pascal Bourguignon__
"Seamus MacRae" writes:
>> Copying something from emacs is a good way to give your user base a
>> headache. Especially if it involves "meta" or (n)curses.
Pascal J. Bourguignon wrote:
> I don't know why you keep mentionning ncurses. emacs is a GUI
> application like any other, it has menus, toolbar, scrollbars, pop-up
> dialogs, and runs with any window manager the host system provides,
> such as X, Aqua or whatever they have on MS-Windows.
"Seamus" is fond of the intellectually dishonest technique of arguing about a
25-year-old version of the product as if it disproved anything about your
claims regarding the modern world. I don't think you'll be able to get him to
admit publicly that emacs is a GUI product or that it's as flexible as it is.
--
Lew
Lew wrote:
> "Seamus MacRae" writes:
>>> Copying something from emacs is a good way to give your user base a
>>> headache. Especially if it involves "meta" or (n)curses.
>
> Pascal J. Bourguignon wrote:
>> I don't know why you keep mentionning ncurses. emacs is a GUI
>> application like any other, it has menus, toolbar, scrollbars, pop-up
>> dialogs, and runs with any window manager the host system provides,
>> such as X, Aqua or whatever they have on MS-Windows.
>
> "Seamus" is fond of the intellectually dishonest technique [rest of
> bullshit deleted]
Your personal attacks and general viciousness have gone far enough. I
have remained civil despite some extreme provocations recently, largely
from you. This blatant accusation of lying is the final straw.
I have now reported your behavior in this thread to Albasani, who will
hopefully see fit to improve the signal to noise ratio in this thread by
removing its least interesting, reasonable, informative, on-topic, and
polite participant.
Have a nice day.
Pascal J. Bourguignon wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Pascal J. Bourguignon wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>
>>>> Pascal J. Bourguignon wrote:
>>>>>> The stuff Series said about keeping separate testing and production
>>>>>> systems, only hacking on the former, and having some sort of version
>>>>>> control seems to stand though. Editing text files on disk does not
>>>>>> scale up to a major software project's development practises; you'll
>>>>>> spend more time using the command line to check in and check out than
>>>>> What CLI?
>>>> Well, that would depend. On our Windows machines, we use the lame
>>> I meant that NetBeans has exactly the same feature as emacs, nothing
>>> more.
>> That's a joke, right? One's a full-blown IDE, the other just a text editor.
>
> By the way, I'm using emacs to post these newsgroups articles, to read
> my email, to browse the web, to chat with irc and jabber, to do my
> accounting, to compute my spreadsheets, to manage my address book, and
> of course to develop all my programs, including coding, compiling,
> debugging.
>
> Can you do only half of that with your "IDE"?
I can do all of that with my operating system, which is the mode of
usage you seem to be describing. :P
My IDE, by contrast, does one job (code related stuff) and does it well.
EXTREMELY well.
>>>>>> you spend editing, testing, or compiling anything. NetBeans provides
>>>>>> integration with multiple widely-used version control systems,
>>>>> Where do you think NetBeans developers got the idea from?
>>>> Probably from Eclipse.
>>> No, from emacs.
>> Copying something from emacs is a good way to give your user base a
>> headache. Especially if it involves "meta" or (n)curses.
>
> I don't know why you keep mentionning ncurses.
Because that's the usual way to implement a full-screen text editor at
the Unix command line, as opposed to a line-oriented one (or something
actually modern).
> emacs is a GUI application like any other
I'm sorry, but I don't consider a shell or shell-launched tool in an
xterm to be "a GUI application" at all, let alone one "like any other".
(The xterm itself arguably qualifies for the former classification.)
> it has menus, toolbar, scrollbars, pop-up
> dialogs, and runs with any window manager the host system provides,
> such as X, Aqua or whatever they have on MS-Windows.
So does EDLIN.EXE if I run it in a command prompt window in Windows, in
the sense that it's in a window with menus (mark mode, copy from
terminal, paste into terminal, one or two others, print, quit) and the like.
I still wouldn't call EDLIN.EXE a GUI application though, "like any
other" or otherwise.
Seamus MacRae <··········@live.ca.nospam> writes:
> Pascal J. Bourguignon wrote:
>> Can you do only half of that with your "IDE"?
>
> I can do all of that with my operating system, which is the mode of
> usage you seem to be describing. :P
>
> My IDE, by contrast, does one job (code related stuff) and does it
> well. EXTREMELY well.
Which one are you using ?
Frank GOENNINGER wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Pascal J. Bourguignon wrote:
>>> Can you do only half of that with your "IDE"?
>> I can do all of that with my operating system, which is the mode of
>> usage you seem to be describing. :P
>>
>> My IDE, by contrast, does one job (code related stuff) and does it
>> well. EXTREMELY well.
>
> Which one are you using ?
NetBeans.
On May 15, 6:25 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > If your editor doesn't support search and replace, I suggest you
> > search for a new one to replace it. :)
>
> Apart for emacs, I know of no editor able to do the syntactic analysis
Text editors don't do syntactic analysis. They deal strictly in ASCII
strings.
> that is needed to match the boilerplates you have to have in non-lisp
> programming language, and do the needed substitutions.
>
> But in practice it's too hard to do, so you end doing the updates
> manually or mostly manually anyways.
Well, that's emacs for you. Those of us using a real IDE don't have
these problems. :)
> > And now you've replaced a bit of your code with the expanded version.
> > Later you'll change the macro for whatever reason, but at this one
> > spot the change won't be applied since the macro call was replaced
> > with its expansion in your editor at that spot. That copy now gets out
> > of synch with the rest of the code.
>
> You are so confused! The macros are not expanded by the editor! They
> are compiler hooks
Yes, normally, but the debugging procedure just described involved
changing some particular bit of macro-using code, in the text editor,
to what it becomes after the macro transforms it, in order to get a
clue as to why the macro wasn't doing the right thing there. If that
change isn't undone afterward, it will no longer reflect subsequent
changes made to the macro (including the bug fix!) and that's going to
cause problems.
> The only thing you have to do when you change a macro, is to recompile
> the functions that use it. This is easily done automatically by
> putting macros in a separate source file and defining correctly the
> dependencies of the other files.
Manually defining dependencies? How 1980s. I haven't done that since
God finally invented automake. And these days I use ant. What a world
of difference that makes!
(Guess what -- automake turns 15 this September! I think I'll order a
birthday cake for it, though I won't be able to share it with it.)
> > Of course, a proper IDE should let you right click on the macro call
> > and get a menu with options like "go to definition", "view
> > documentation", and "see expansion in a pop-over window WITHOUT
> > altering the code in your source file". For that you need something
> > obviously way more sophisticated than what you're describing, which
> > ("small sequence of keystrokes") sounds suspiciously like emacs.
>
> "Go to definition" can be implemented using classical tags, like for any
> other programming language.
I want to spend my time programming my actual project, not programming
an editor.
> a simple editor like emacs
*sputter* What?!
Oh Christ, I've got Coke running down my screen, gimme a minute to
wipe it up.
And don't do that again! Sheesh.
> > 2. At one point, something goes wrong so you hit a "small sequence of
> > keystrokes" to do an in-place replacement of a call to that macro
> > with its expansion.
>
> Why would we do that? That would mean shooting in one's foot. Nobody
> would do that.
Apparently, gugamilare would.
> > Congratulations, gugamilare, it's a bug!
>
> In your dreams only.
I am fairly certain that I was not imagining the post I replied to.
> > A made-up example. You haven't named a real, running mission-critical
> > system that is routinely modified on the fly while in production use
> > and has no back-ups.
>
> > Show me one of those, and I'll show you a headline from the future:
> > "Over sixty thousand customers in the dark after catastrophic computer
> > failure at power distribution center", "Over three hundred million
> > awarded in class-action suit over defective products caused by process
> > control computer error", "One person dead after ill-timed heart attack
> > during last night's six-hour 911 outage", "E-commerce giant courting
> > bankruptcy after catastrophic three-week Web site downtime", or
> > something along those lines.
>
> In really, such a mission-critical system was developed by Paul
> Graham, and sold to Yahoo for a fortune, which used it without such a
> catastrophe.http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
"This style of development fits well with the rolling releases that
are possible with Web-based software. It's also a faster way to
get software written generally."
Releases. Sounds like they didn't hack the live web-server on the fly,
but kept a separate test-monkey, though with fairly frequent updates
to the live version.
Still not an example of what I was talking about, then.
> Another example, is the debugging of the OS code of the Deep Space 1
> code when it was millions of kilometers from the Earth. Again, the
> modifications were made on a running program without outage, and even
> without physical access to computer.http://www.flownet.com/gat/jpl-lisp.html
Modifications first tested on a copy dirtside, no doubt, running on
some NASA emulator against simulated mission parameters.
And what became of Lisp at JPL? Why, it got shitcanned, and now their
Lisp flavor does the lowly menial work of serving the Google ads that
one of my browser plugins (probably written in Java) blocks.
> >> How about saving your changes in a file before you load them???
>
> > These were changes being made to the copy of the program running in
> > RAM using the debugging tools, remember? Not to the source code on
> > disk.
>
> Well probably lisp programmers are smarter. For sure you make us
> think so.
Is there a point here, or just some lashing out at the messenger?
> Is it so hard a concept to make the modifications both in
> the running lisp image and in some persistent storage?
Having to make the same changes in two places is a recipe for trouble.
> This is actually the normal work flow of a lisp programmer: he will
> edit the source file in emacs, type C-x C-b which will ask slime to
> send the file to the running lisp image, which updates it.
I find it hard to take seriously any proposed procedure that has "ask
slime" as a step. Or involves emacs. :)
On May 16, 8:10 am, Series Expansion <·······@gmail.com> wrote:
> On May 15, 6:25 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Series Expansion <·······@gmail.com> writes:
> > > If your editor doesn't support search and replace, I suggest you
> > > search for a new one to replace it. :)
>
> > Apart for emacs, I know of no editor able to do the syntactic analysis
>
> Text editors don't do syntactic analysis. They deal strictly in ASCII
> strings.
Yeah, and you read the ASCII string and do syntactic analysis on it!
Look, I don't know how Emacs is built, but I do know that when I'm
working on some Lisp code, there's a little info bar that lets me know
the syntax of the form I'm editing at the moment. Yes, that's right,
my TEXT EDITOR is able to sniff out the syntax of what I'm typing in,
figure out which ASCII string is the function, macro, or special form
that I'm making a call to, look up the syntax of that form (including
syntax of user-defined forms), and displays that syntax to me. It even
highlights the part of the syntax that I'm currently editing.
Emacs has this power for two reasons (that I know of off the top of my
head):
1) It's written in a dialect of Lisp, which gives it a lot of symbolic
processing power, and
2) I've got SLIME running as well, which enhances Emacs's knowledge of
Lisp, and its functionality.
READ MY DETAILED POST ABOUT SLIME PLEASE BEFORE SPEWING FORTH MORE
IGNORANCE UNTO THE NETS!
> > > And now you've replaced a bit of your code with the expanded version.
> > > Later you'll change the macro for whatever reason, but at this one
> > > spot the change won't be applied since the macro call was replaced
> > > with its expansion in your editor at that spot. That copy now gets out
> > > of synch with the rest of the code.
>
> > You are so confused! The macros are not expanded by the editor! They
> > are compiler hooks
>
> Yes, normally, but the debugging procedure just described involved
> changing some particular bit of macro-using code, in the text editor,
> to what it becomes after the macro transforms it, in order to get a
> clue as to why the macro wasn't doing the right thing there. If that
> change isn't undone afterward, it will no longer reflect subsequent
> changes made to the macro (including the bug fix!) and that's going to
> cause problems.
Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
SOURCE CODE.
You've either misunderstood gugamilare (highly likely), or gugamilare
has made some questionable decisions about how he works on his code.
When you test a macro using the MACROEXPAND form, you evaluate that
separately, in a Lisp prompt, or in a separate prompt opened by slime,
the way a normal IDE does. IT DOES NOT EXPAND INTO YOUR SOURCE CODE.
Your source code stays exactly as you left it.
> > The only thing you have to do when you change a macro, is to recompile
> > the functions that use it. This is easily done automatically by
> > putting macros in a separate source file and defining correctly the
> > dependencies of the other files.
>
> Manually defining dependencies? How 1980s. I haven't done that since
> God finally invented automake. And these days I use ant. What a world
> of difference that makes!
>
> (Guess what -- automake turns 15 this September! I think I'll order a
> birthday cake for it, though I won't be able to share it with it.)
Defining dependencies is a) a piece of cake, and b) something that
macros do for you.
> > > Of course, a proper IDE should let you right click on the macro call
> > > and get a menu with options like "go to definition", "view
> > > documentation", and "see expansion in a pop-over window WITHOUT
> > > altering the code in your source file". For that you need something
> > > obviously way more sophisticated than what you're describing, which
> > > ("small sequence of keystrokes") sounds suspiciously like emacs.
>
> > "Go to definition" can be implemented using classical tags, like for any
> > other programming language.
>
> I want to spend my time programming my actual project, not programming
> an editor.
That's why we've got SLIME, a huge package of editor customizations
that sets up Emacs into a powerful Lisp IDE. Read my post here if you
haven't already, so that you understand what you're talking about
before you say Emacs can't do syntactic analysis:
http://groups.google.com/group/comp.lang.lisp/msg/af00fe4c6ff30ae8?hl=en
> Apparently, gugamilare would.
>
> > > Congratulations, gugamilare, it's a bug!
>
> > In your dreams only.
>
> I am fairly certain that I was not imagining the post I replied to.
Man, give the guy a break. He miscommunicated to you, and now you're
just deliberately sticking to a misinterpretation to wave in our face,
instead of trying to understand our explanations.
> > In really, such a mission-critical system was developed by Paul
> > Graham, and sold to Yahoo for a fortune, which used it without such a
> > catastrophe.http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
>
> "This style of development fits well with the rolling releases that
> are possible with Web-based software. It's also a faster way to
> get software written generally."
>
> Releases. Sounds like they didn't hack the live web-server on the fly,
> but kept a separate test-monkey, though with fairly frequent updates
> to the live version.
>
> Still not an example of what I was talking about, then.
Uh, actually, they did hack the server while it was live. While on the
phone with customers reporting bugs. So yeah, this is EXACTLY what you
were talking about. This is the power of Lisp.
> > Another example, is the debugging of the OS code of the Deep Space 1
> > code when it was millions of kilometers from the Earth. Again, the
> > modifications were made on a running program without outage, and even
> > without physical access to computer.http://www.flownet.com/gat/jpl-lisp.html
>
> Modifications first tested on a copy dirtside, no doubt, running on
> some NASA emulator against simulated mission parameters.
>
> And what became of Lisp at JPL? Why, it got shitcanned, and now their
> Lisp flavor does the lowly menial work of serving the Google ads that
> one of my browser plugins (probably written in Java) blocks.
Somebody posted this link earlier, maybe you missed it.
http://www.flownet.com/gat/jpl-lisp.html
Here's a quote from that page (under the heading "1994 - 2000": Remote
Agent):
"""Remote Agent controlled DS1 for two days in May of 1999. During
that time we were able to debug and fix a race condition that had not
shown up during ground testing. (Debugging a program running on a
$100M piece of hardware that is 100 million miles away is an
interesting experience. Having a read-eval-print loop running on the
spacecraft proved invaluable in finding and fixing the problem."""
Is it possible to scream "Lisp saved our asses" more loudly than that
does!?
Please read up on SLIME, Emacs, CLOS, and Common Lisp Macros before
you continue posting ignorance!
- Adlai
On May 16, 1:36 am, Adlai <·········@gmail.com> wrote:
> On May 16, 8:10 am, Series Expansion <·······@gmail.com> wrote:
> > Text editors don't do syntactic analysis. They deal strictly in ASCII
> > strings.
>
> Yeah, and you read the ASCII string and do syntactic analysis on it!
No, YOU read the ASCII string and do syntactic analysis on it. I
prefer to have tools that will do that sort of crap for me.
> Emacs has this power for two reasons (that I know of off the top of my
> head):
> 1) It's written in a dialect of Lisp
To you guys, Lisp is like some magic elixir that grants lifelike
behavior and extraordinary properties to anything infused with it,
isn't it?
Well, I've got news for you. Here in the real world, there ain't no
silver bullet. No philosopher's stone. No magic spell a wizard can
cast to make brooms come to life and carry water or whatever. Instead,
we have this thing called "engineering". We actually have to figure
something out and then build it to run on ordinary electricity or
gasoline. And if something is impossible, it just plain won't work.
> READ MY DETAILED POST ABOUT SLIME PLEASE BEFORE SPEWING FORTH MORE
> IGNORANCE UNTO THE NETS!
READ EMILY POST PLEASE BEFORE SPEWING FORTH MORE PERSONAL ATTACKS UNTO
THE NETS!
> > Yes, normally, but the debugging procedure just described involved
> > changing some particular bit of macro-using code, in the text editor,
> > to what it becomes after the macro transforms it, in order to get a
> > clue as to why the macro wasn't doing the right thing there. If that
> > change isn't undone afterward, it will no longer reflect subsequent
> > changes made to the macro (including the bug fix!) and that's going to
> > cause problems.
>
> Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
> SOURCE CODE.
Apparently, gugamilare disagrees.
> When you test a macro using the MACROEXPAND form, you evaluate that
> separately, in a Lisp prompt, or in a separate prompt opened by slime,
> the way a normal IDE does.
Prompts are so 1985. And wouldn't you need an MDI window system to
have anywhere else for it to expand into BESIDES your source file?
> > > The only thing you have to do when you change a macro, is to recompile
> > > the functions that use it. This is easily done automatically by
> > > putting macros in a separate source file and defining correctly the
> > > dependencies of the other files.
>
> > Manually defining dependencies? How 1980s. I haven't done that since
> > God finally invented automake. And these days I use ant. What a world
> > of difference that makes!
>
> > (Guess what -- automake turns 15 this September! I think I'll order a
> > birthday cake for it, though I won't be able to share it with it.)
>
> Defining dependencies is a) a piece of cake
Yeah, yeah, that's what they all say.
> and b) something that macros do for you.
Fan-bloody-tastic. You know that can't possibly work reliably, right?
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.
> > > "Go to definition" can be implemented using classical tags, like for any
> > > other programming language.
>
> > I want to spend my time programming my actual project, not programming
> > an editor.
>
> That's why we've got SLIME, a huge package of editor customizations
> that sets up Emacs into a powerful Lisp IDE.
SLIME must be magic, then, if it can grant the editor the knowledge
that SuperVGA has been invented from *inside its internal script
interpreter* without even a droplet of native C code to actually talk
to the display hardware. It's amazing! It's fantastic! It makes
Windows Plug'n'Pray obsolete! It's ... slime!
Well, it's that or someone was wrong about SLIME being written
entirely in an editor's scripting language, or you're wrong about what
it can do, or (least plausible of all) someone's definition of
"powerful IDE" allows the possibility of one being a prompt-driven
terminal-mode archaism from the 80s.
My personal theory is that someone's looking at all of this stuff
through rose-colored glasses.
> Read my post here if you haven't already, so that you understand what you're talking about...
I don't tend to comply with requests that are asked of me as rudely as
that.
> > > > Congratulations, gugamilare, it's a bug!
>
> > > In your dreams only.
>
> > I am fairly certain that I was not imagining the post I replied to.
>
> Man, give the guy a break. He miscommunicated to you, and now you're
> just deliberately sticking to a misinterpretation to wave in our face,
> instead of trying to understand our explanations.
Another personal attack, this time accusing me of lacking integrity
and intellectual honesty? Wow, you must have completely run out of
rational arguments in favor of dynamic typing if the only shots left
in your quiver are this lame.
> > > In really, such a mission-critical system was developed by Paul
> > > Graham, and sold to Yahoo for a fortune, which used it without such a
> > > catastrophe.http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
>
> > "This style of development fits well with the rolling releases that
> > are possible with Web-based software. It's also a faster way to
> > get software written generally."
>
> > Releases. Sounds like they didn't hack the live web-server on the fly,
> > but kept a separate test-monkey, though with fairly frequent updates
> > to the live version.
>
> > Still not an example of what I was talking about, then.
>
> Uh, actually, they did hack the server while it was live.
No, the term "releases" indicates they followed a standard development
model, perhaps somewhat accelerated but otherwise typical, rather than
going the "no plans, no prototype, no backup" route.
> > > Another example, is the debugging of the OS code of the Deep Space 1
> > > code when it was millions of kilometers from the Earth. Again, the
> > > modifications were made on a running program without outage, and even
> > > without physical access to computer.http://www.flownet.com/gat/jpl-lisp.html
>
> > Modifications first tested on a copy dirtside, no doubt, running on
> > some NASA emulator against simulated mission parameters.
>
> > And what became of Lisp at JPL? Why, it got shitcanned, and now their
> > Lisp flavor does the lowly menial work of serving the Google ads that
> > one of my browser plugins (probably written in Java) blocks.
>
> Somebody posted this link earlier, maybe you missed it.http://www.flownet.com/gat/jpl-lisp.html
I quoted and responded to it right there, you dipshit!
> Here's a quote from that page (under the heading "1994 - 2000": Remote
> Agent):
>
> """Remote Agent controlled DS1 for two days in May of 1999. During
> that time we were able to debug and fix a race condition that had not
> shown up during ground testing. (Debugging a program running on a
> $100M piece of hardware that is 100 million miles away is an
> interesting experience. Having a read-eval-print loop running on the
> spacecraft proved invaluable in finding and fixing the problem."""
They used it to perform remote diagnostics, and subsequently to upload
a patch. Nothing is implied about how that patch was developed and
tested in the meantime. Consider though that experimenting with the
live version on board the spacecraft, were this to shut it down or
render it unable to receive or transmit signals, would have meant the
loss of the multi-million-dollar probe. It stands to reason that they
did nothing to modify the probe's code without extensive testing on
the ground first.
> Is it possible to scream "Lisp saved our asses" more loudly than that
> does!?
They could have launched it hosting a JVM with an attached debugger
and still done what it's implied they did.
> Please read up on SLIME, Emacs, CLOS, and Common Lisp Macros before
> you continue posting ignorance!
Please read up on etiquette, polite society, civilization, and Emily
Post before you continue posting personal attacks!
On 16 maio, 16:51, Series Expansion <·······@gmail.com> wrote:
> On May 16, 1:36 am, Adlai <·········@gmail.com> wrote:
>
> > On May 16, 8:10 am, Series Expansion <·······@gmail.com> wrote:
> > > Text editors don't do syntactic analysis. They deal strictly in ASCII
> > > strings.
>
> > Yeah, and you read the ASCII string and do syntactic analysis on it!
>
> No, YOU read the ASCII string and do syntactic analysis on it. I
> prefer to have tools that will do that sort of crap for me.
That is what he meant - Emacs does this, not we.
>
> > Emacs has this power for two reasons (that I know of off the top of my
> > head):
> > 1) It's written in a dialect of Lisp
>
> To you guys, Lisp is like some magic elixir that grants lifelike
> behavior and extraordinary properties to anything infused with it,
> isn't it?
You tell me that ain't also the case of Eclipse? 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.
>
> Well, I've got news for you. Here in the real world, there ain't no
> silver bullet. No philosopher's stone. No magic spell a wizard can
> cast to make brooms come to life and carry water or whatever. Instead,
> we have this thing called "engineering". We actually have to figure
> something out and then build it to run on ordinary electricity or
> gasoline. And if something is impossible, it just plain won't work.
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.
>
> > Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
> > SOURCE CODE.
>
> Apparently, gugamilare disagrees.
I DON'T! Read my last posts and NEVER put words in my mouth again.
>
> > When you test a macro using the MACROEXPAND form, you evaluate that
> > separately, in a Lisp prompt, or in a separate prompt opened by slime,
> > the way a normal IDE does.
>
> Prompts are so 1985. And wouldn't you need an MDI window system to
> have anywhere else for it to expand into BESIDES your source file?
>
You say that Java does not have a prompt where you can test and debug
things? Are you saying that Linux terminals are useless? make /
Autoconf is made on top of them. Don't you compile code and download
packages from the shell at all?
> > > > The only thing you have to do when you change a macro, is to recompile
> > > > the functions that use it. This is easily done automatically by
> > > > putting macros in a separate source file and defining correctly the
> > > > dependencies of the other files.
>
> > > Manually defining dependencies? How 1980s. I haven't done that since
> > > God finally invented automake. And these days I use ant. What a world
> > > of difference that makes!
>
> > > (Guess what -- automake turns 15 this September! I think I'll order a
> > > birthday cake for it, though I won't be able to share it with it.)
>
> > Defining dependencies is a) a piece of cake
>
> Yeah, yeah, that's what they all say.
>
> > and b) something that macros do for you.
>
> Fan-bloody-tastic. You know that can't possibly work reliably, right?
You are such a child, you have no idea of what you are saying.
> 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. It is a
automake-like feature, the only difference is that it is written in
Lisp (and in separated files, just like the makefiles and stuff).
>
> > > > "Go to definition" can be implemented using classical tags, like for any
> > > > other programming language.
>
> > > I want to spend my time programming my actual project, not programming
> > > an editor.
>
> > That's why we've got SLIME, a huge package of editor customizations
> > that sets up Emacs into a powerful Lisp IDE.
>
> SLIME must be magic, then, if it can grant the editor the knowledge
> that SuperVGA has been invented from *inside its internal script
> interpreter* without even a droplet of native C code to actually talk
> to the display hardware. It's amazing! It's fantastic! It makes
> Windows Plug'n'Pray obsolete! It's ... slime!
Slime connects to the lisp environment and asks questions about where
the definition files are. It just works, you really should stop making
so dumb arguments and learn Lisp before anything else.
>
> Well, it's that or someone was wrong about SLIME being written
> entirely in an editor's scripting language, or you're wrong about what
> it can do, or (least plausible of all) someone's definition of
> "powerful IDE" allows the possibility of one being a prompt-driven
> terminal-mode archaism from the 80s.
He is not wrong. This is just every-day use of Slime. I use this
feature every day I program in Lisp. You tell me that Eclipse for
instance can't find the source definition of something if you ask it
to do so? If the answer is no, then I can only say that Eclipse sucks,
this is not possible.
> > Please read up on SLIME, Emacs, CLOS, and Common Lisp Macros before
> > you continue posting ignorance!
>
> Please read up on etiquette, polite society, civilization, and Emily
> Post before you continue posting personal attacks!
He is serious about that, he is not attacking you or stuff like that.
You do sound like a novel writer talking about quantum mechanics. You
need to learn things before you can attack them, or you just don't
attack them. You won't see me in comp.lang.java unless I learn Java.
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.
gugamilare wrote:
> You won't see me in comp.lang.java unless I learn Java.
Actually, your posts are showing up over "here" in comp.lang.java.programmer.
> 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.
"Series Expansion" is a worthless troll. Ignore him. He's not in any way
representative of the universe of Java programmers. He's just a nasty little man.
--
Lew
Lew <·····@lewscanon.com> writes:
> "Series Expansion" is a worthless troll. Ignore him. He's not in any
> way representative of the universe of Java programmers. He's just a
> nasty little man.
Yes, don't judge a language by its trolls - we have some of them in
comp.lang.lisp, too. At the moment, we are in the lucky situation that Xah
Lee and Jon Harrop are taking a rest, but the Maas troll who started this
thread is still active.
Nicolas
P.S.: I think we can also be quite sure that there are no Lisp or Java
"gods" present in this thread. At least, one "god" (or better wise man)
who posts to comp.lang.lisp more or less regularly, namely Kent Pitman, has
stated explicitly that he does not participate in crossposted threads.
On May 17, 5:11 am, Nicolas Neuss <········@math.uni-karlsruhe.de>
wrote:
> Lew <·····@lewscanon.com> writes:
> > "Series Expansion" is a worthless troll. Ignore him. He's not in any
> > way representative of the universe of Java programmers. He's just a
> > nasty little man.
As you can see, Lew has nothing worthwhile to say whatsoever in the
way of arguments either for or against Lisp, merely a vitriolic
outpouring of namecalling so foul as to inspire me to wash my hands
after reading it due to a certain open question regarding exactly
which orifice oozed forth the reeking substance of it.
> Yes, don't judge a language by its trolls - we have some of them in
> comp.lang.lisp, too.
We've noticed.
> At the moment, we are in the lucky situation that Xah Lee and Jon
> Harrop are taking a rest
I have seen several of Xah Lee's threads in comp.lang.java.programmer,
and remain unconvinced that he's a troll, at least in the classic
sense. Rather he seems to use Usenet as a publication platform for
lengthy tracts, and a promotional vehicle for his Web site. That he
doesn't seem to use automated posting or large Breidbart indices, and
sometimes lingers to discuss at least briefly some of the replies,
causes him to also fail to qualify as a spammer.
I am not familiar with Jon Harrop. He does not seem to post to
comp.lang.java.programmer.
> but the Maas troll who started this thread is still active.
I'm also unconvinced that he's a troll. He's disturbed, if you ask me.
> P.S.: I think we can also be quite sure that there are no Lisp or Java
> "gods" present in this thread.
Certainly nobody in this thread has impressed me as having that kind
of status; in the other direction, I suspect several to be under legal
drinking age.
The closest thing to a Java "god" in comp.lang.java.programmer that we
have right now might be Patricia Shanahan. Knowledge, wisdom,
intelligence, and a tendency to stay out of the sordid business of
personal attacks at least most of the time. There are several other
people of note, some quite knowledgeable, but most of these stand out
primarily by being loudmouthed, argumentative boors. You've met one. I
assume that merely being opinionated a vocal does not a "god" make
you.
Those that actually designed Java and those that are highly placed in
Sun Microsystems seem not to hang out in comp.lang.java.programmer.
Meanwhile I theorize that some of the Lisp vs. Java animosity might be
explained as a kind of sublimated emacs vs. vi hostility. Whereas
there seems to be a close association between Lisp and emacs, and the
latter uses a dialect of the former as its scripting language, one of
the creators of Java was also the principal developer of vi some
decades ago. On the other hand, plenty of Java developers use neither
of the old Unix editors, preferring more modern tools. This leads to
Eclipse vs. NetBeans fights. :)
Series Expansion wrote:
> I am not familiar with Jon Harrop. He does not seem to post to
> comp.lang.java.programmer.
He does occasionally.
Mostly stating that ML-derivative languages are faster than
Java and similar.
Arne
Series Expansion wrote:
> Meanwhile I theorize that some of the Lisp vs. Java animosity might be
> explained as a kind of sublimated emacs vs. vi hostility. Whereas
> there seems to be a close association between Lisp and emacs, and the
> latter uses a dialect of the former as its scripting language, one of
> the creators of Java was also the principal developer of vi some
> decades ago.
Bill Joy was part of early vi.
But James Gosling was part of early emacs.
No reason to think Java people should particular prefer
vi over emacs.
Arne
On May 18, 9:44 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > Meanwhile I theorize that some of the Lisp vs. Java animosity might be
> > explained as a kind of sublimated emacs vs. vi hostility. Whereas
> > there seems to be a close association between Lisp and emacs, and the
> > latter uses a dialect of the former as its scripting language, one of
> > the creators of Java was also the principal developer of vi some
> > decades ago.
>
> Bill Joy was part of early vi.
On May 16, 5:33 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > You won't see me in comp.lang.java unless I learn Java.
>
> Actually, your posts are showing up over "here" in comp.lang.java.programmer.
>
> > 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.
>
> "Series Expansion" is a worthless troll. Ignore him. He's not in any way
> representative of the universe of Java programmers. He's just a nasty little man.
I find it far more likely that the term "troll" is applicable to the
two individuals in this little side-debate that are flinging insults
around and making imperious demands, than that it is applicable to the
one who has (with one or two exceptions) remained rational.
On May 17, 11:21 pm, Series Expansion <·······@gmail.com> wrote:
> On May 16, 5:33 pm, Lew <·····@lewscanon.com> wrote:
>
> > gugamilare wrote:
> > > You won't see me in comp.lang.java unless I learn Java.
>
> > Actually, your posts are showing up over "here" in comp.lang.java.programmer.
>
> > > 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.
>
> > "Series Expansion" is a worthless troll. Ignore him. He's not in any way
> > representative of the universe of Java programmers. He's just a nasty little man.
>
> I find it far more likely that the term "troll" is applicable to the
> two individuals in this little side-debate that are flinging insults
> around and making imperious demands, than that it is applicable to the
> one who has (with one or two exceptions) remained rational.
It's not called rational when:
- People tell you to spend a few minutes understanding some new
concept, and
- They provide resources, whether by directly explaining, or pointing
you to a free resource (not ONE of the resources recommended herein
wasn't free: PCL, Successful Lisp, and On Lisp are all books available
for free on the internet. Google, or clicking the links provided
earlier, would bring them to you instantly), and
- They redirect you to these efforts after the first few times you
ignore them, but
- You continually ignore these resources, while saying that you only
deal reasonably and requesting us to supply any backing for statements
like "C macros and Lisp macros are two very different beasts."
Open up your eyes, and tell us what you see.
- Adlai
Adlai wrote:
> It's not called rational when:
> - People tell you to spend a few minutes understanding some new
> concept, and
> - They provide resources, whether by directly explaining, or pointing
> you to a free resource (not ONE of the resources recommended herein
> wasn't free: PCL, Successful Lisp, and On Lisp are all books available
> for free on the internet. Google, or clicking the links provided
> earlier, would bring them to you instantly), and
> - They redirect you to these efforts after the first few times you
> ignore them, but
> - You continually ignore these resources, while saying that you only
> deal reasonably and requesting us to supply any backing for statements
> like "C macros and Lisp macros are two very different beasts."
>
> Open up your eyes, and tell us what you see.
Please take this thread out of the Java newsgroup.
--
Lew
On May 17, 4:34 pm, Adlai <·········@gmail.com> wrote:
> On May 17, 11:21 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 5:33 pm, Lew <·····@lewscanon.com> wrote:
> > > gugamilare wrote:
> > > > 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.
>
> > > "Series Expansion" is a worthless troll. Ignore him. He's not in any way
> > > representative of the universe of Java programmers. He's just a nasty little man.
>
> > I find it far more likely that the term "troll" is applicable to the
> > two individuals in this little side-debate that are flinging insults
> > around and making imperious demands, than that it is applicable to the
> > one who has (with one or two exceptions) remained rational.
>
> It's not called rational when:
> - People tell you to [etc]
Yes, it is indeed irrational to demand that a usenet poster do
something, given the general inability to back such a demand up with
force. Perhaps you should stop being irrational.
> - They provide resources, whether by directly explaining, or pointing
Resources are not relevant. Evidence and logic are needed to refute an
argument. You have employed neither of them very often.
> - They redirect you to these efforts after the first few times you
> ignore them
It is illogical to expect me to not ignore irrelevancies and
distractions. I described how ANY macro with the basic property of
eventual lexical replacement of the call with other code, which in
turn includes embedded copies of the call's arguments, will inevitably
suffer from at least one of a particular set of four problems. No
links to Lisp tutorials and similar information, much of which I
already know anyway, would have any bearing on this more general
subject. The arguments I fronted do not depend in any way, shape, or
form on the language details, merely on the fact of lexical
replacement of the call and substitution within the replacement code
of the arguments. From this fact alone, which is demonstrably
applicable to Lisp macros, the consequences and associated tradeoffs
that I outlined inevitably result. Nothing in my final argument
assumed the presence of any behaviors peculiar to C macros or to any
other particular implementation of macros; their SOLE assumption was
that the call is replaced with some code, within which certain
placeholder constructs are replaced by the call's arguments, after
which the altered code is compiled. And that assumption is not
violated by Lisp macros.
> - You continually ignore these resources, while saying that you only
> deal reasonably and requesting us to supply any backing for statements
> like "C macros and Lisp macros are two very different beasts."
I ignored what was not relevant. I never did request backing for "C
macros and Lisp macros are different". They are different in some ways
but they share the essential characteristic that a call is replaced
with some code, within which certain placeholder constructs are
replaced by the call's arguments, after which the altered code is
compiled. A characteristic that, in particular, is true of Lisp
macros.
You continue to ignore this core point and nibble away at peripheral
matters and irrelevancies, which I take to be evidence that you are
unable to address the core point; in other words, that you are unable
to prove your position or to disprove mine.
An honest and fair-minded opponent might react to such a state of
affairs via a graceful capitulation. You, on the other hand, have
resorted to verbal violence. That is poor sportsmanship.
> Open up your eyes, and tell us what you see.
I see a Firefox window containing a form with this post nearly ready
to send.
On May 16, 4:24 pm, gugamilare <··········@gmail.com> wrote:
> On 16 maio, 16:51, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 1:36 am, Adlai <·········@gmail.com> wrote:
> > > On May 16, 8:10 am, Series Expansion <·······@gmail.com> wrote:
> > > > Text editors don't do syntactic analysis. They deal strictly in ASCII
> > > > strings.
>
> > > Yeah, and you read the ASCII string and do syntactic analysis on it!
>
> > No, YOU read the ASCII string and do syntactic analysis on it. I
> > prefer to have tools that will do that sort of crap for me.
>
> 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.
> > > Emacs has this power for two reasons (that I know of off the top of my
> > > head):
> > > 1) It's written in a dialect of Lisp
>
> > To you guys, Lisp is like some magic elixir that grants lifelike
> > behavior and extraordinary properties to anything infused with it,
> > isn't it?
>
> 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.
> > Well, I've got news for you. Here in the real world, there ain't no
> > silver bullet. No philosopher's stone. No magic spell a wizard can
> > cast to make brooms come to life and carry water or whatever. Instead,
> > we have this thing called "engineering". We actually have to figure
> > something out and then build it to run on ordinary electricity or
> > gasoline. And if something is impossible, it just plain won't work.
>
> 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.)
> > > Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
> > > SOURCE CODE.
>
> > Apparently, gugamilare disagrees.
>
> 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.
> > > When you test a macro using the MACROEXPAND form, you evaluate that
> > > separately, in a Lisp prompt, or in a separate prompt opened by slime,
> > > the way a normal IDE does.
>
> > Prompts are so 1985. And wouldn't you need an MDI window system to
> > have anywhere else for it to expand into BESIDES your source file?
>
> 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.
> > > Defining dependencies is ... something that macros do for you.
>
> > 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 must be magic, then, if it can grant the editor the knowledge
> > that SuperVGA has been invented from *inside its internal script
> > interpreter* without even a droplet of native C code to actually talk
> > to the display hardware. It's amazing! It's fantastic! It makes
> > Windows Plug'n'Pray obsolete! It's ... slime!
>
> 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?
> > Well, it's that or someone was wrong about SLIME being written
> > entirely in an editor's scripting language, or you're wrong about what
> > it can do, or (least plausible of all) someone's definition of
> > "powerful IDE" allows the possibility of one being a prompt-driven
> > terminal-mode archaism from the 80s.
>
> 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".)
> > Please read up on etiquette, polite society, civilization, and Emily
> > Post before you continue posting personal attacks!
>
> 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.
On May 17, 8:29 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:24 pm, gugamilare <··········@gmail.com> wrote:
>
> > On 16 maio, 16:51, Series Expansion <·······@gmail.com> wrote:
> > > On May 16, 1:36 am, Adlai <·········@gmail.com> wrote:
> > > > On May 16, 8:10 am, Series Expansion <·······@gmail.com> wrote:
> > > > > Text editors don't do syntactic analysis. They deal strictly in ASCII
> > > > > strings.
>
> > > > Yeah, and you read the ASCII string and do syntactic analysis on it!
>
> > > No, YOU read the ASCII string and do syntactic analysis on it. I
> > > prefer to have tools that will do that sort of crap for me.
>
> > 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 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.
> > > > Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
> > > > SOURCE CODE.
>
> > > Apparently, gugamilare disagrees.
>
> > I DON'T!
>
> 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.
>
> > Read my last posts and
>
> 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.
>
> > > > When you test a macro using the MACROEXPAND form, you evaluate that
> > > > separately, in a Lisp prompt, or in a separate prompt opened by slime,
> > > > the way a normal IDE does.
>
> > > Prompts are so 1985. And wouldn't you need an MDI window system to
> > > have anywhere else for it to expand into BESIDES your source file?
>
> > 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.
Lisp has had all of that for 20+ years, plus an interactive prompt
that you can use to "sketch" your code.
> > > SLIME must be magic, then, if it can grant the editor the knowledge
> > > that SuperVGA has been invented from *inside its internal script
> > > interpreter* without even a droplet of native C code to actually talk
> > > to the display hardware. It's amazing! It's fantastic! It makes
> > > Windows Plug'n'Pray obsolete! It's ... slime!
>
> > 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.
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.
>
> > 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!
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.
>
> > 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?
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
On May 17, 1:51 am, Adlai <·········@gmail.com> wrote:
> On May 17, 8:29 am, Series Expansion <·······@gmail.com> wrote:
> > 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.
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.
> > 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.
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.
> > > > > Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
> > > > > SOURCE CODE.
>
> > > > Apparently, gugamilare disagrees.
>
> > > I DON'T!
>
> > 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,
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.
> > > Read my last posts and
>
> > NEVER order me around like I'm your personal slave again.
>
> 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.
> > > > > When you test a macro using the MACROEXPAND form, you evaluate that
> > > > > separately, in a Lisp prompt, or in a separate prompt opened by slime,
> > > > > the way a normal IDE does.
>
> > > > Prompts are so 1985. And wouldn't you need an MDI window system to
> > > > have anywhere else for it to expand into BESIDES your source file?
>
> > > 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.
>
> 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.
> > > 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.
>
> 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.)
> > 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 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.
> > > 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?
>
> Yes.
By all means, then.
On 18 maio, 00:09, Series Expansion <·······@gmail.com> wrote:
> On May 17, 1:51 am, Adlai <·········@gmail.com> wrote:
> > 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.
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.
gugamilare wrote:
> On 18 maio, 00:09, Series Expansion <·······@gmail.com> wrote:
>> On May 17, 1:51 am, Adlai <·········@gmail.com> wrote:
>>> 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.
>
> 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.
--
Lew
On 18 maio, 01:51, Lew <·····@lewscanon.com> wrote:
> 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?
Sorry, you are right, and I already had thought about that myself. But
I was a tempted for a long time to just take a screenshoot of Emacs
and scrub at his face. I didn't because I thought he would just
believe when people said "Emacs has windows", but...
> 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.
I will.
> 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.
Yes, I feel better now.
On May 18, 1:32 am, gugamilare <··········@gmail.com> wrote:
> On 18 maio, 01:51, Lew <·····@lewscanon.com> wrote:
> > Are you kids still squabbling? Do I have to send you to your room?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > You do realize that "Series" has done this before
I have not.
> > he in any way has erred?
I have not.
> > That there is no victory with him?
This much is true. Your defeat is inevitable. Resistance is futile.
> Sorry, you are right, and I already had thought about that myself. But
> I was a tempted for a long time to just take a screenshoot of Emacs
> and scrub at his face.
Threats. How unpleasant.
> I didn't because I thought he would just believe
It takes more than expressions of religious faith to get me to believe
anything. The more so the more preposterous the claim made.
> > Although I did achieve victory over him in this thread myself.
He did not. He ended up holding the moral, tactical, AND strategic low
ground.
> > Seriously, forget about "Series". He's not worth it.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > Emacs is the best editor yet devised.
Except for all the other ones. (Except, in turn, vi and all line-
editors, and maybe Notepad).
> > You're just never going to get "Series" to yield a millimeter
> > even on points of basic fact.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
Particularly calling me a liar.
> > Take comfort in the fact that he can never be real competition to you in the
> > programming work force.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> Yes, I feel better now.
Blissful delusions?
On May 18, 12:51 am, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > On 18 maio, 00:09, Series Expansion <·······@gmail.com> wrote:
> >> On May 17, 1:51 am, Adlai <·········@gmail.com> wrote:
> >>> 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.
>
> > You say you have personal experience with Emacs, but you probably only
> > used it before 1980's.
I used it in the 90s, contrary to gugamilare's uninformed speculation
on the matter.
> Are you kids still squabbling? Do I have to send you to your room?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> 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?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> Although I did achieve victory over him in this thread myself.
You did not. You currently hold the moral, tactical, AND strategic low
ground.
> Seriously, forget about "Series". He's not worth it.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> Emacs is the best editor yet devised.
Except for all the other ones. (Except, in turn, vi and all line-
editors, and maybe Notepad).
> You're just never going to get "Series"
> to yield a millimeter even on points of basic fact.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
Particularly calling me a liar.
> Take comfort in the fact that he can never be real competition to you in the
> programming work force.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
[some final irrelevancies deleted]
On May 18, 12:31 am, gugamilare <··········@gmail.com> wrote:
> On 18 maio, 00:09, Series Expansion <·······@gmail.com> wrote:
>
> > On May 17, 1:51 am, Adlai <·········@gmail.com> wrote:
> > > 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.
>
> You say you have personal experience with Emacs, but you probably only
> used it before 1980's.
That is incorrect. I used it in the late 1990s, though only because I
had to (no physical access to the host, and no remote X capability).
Series Expansion escreveu:
[snip crap]
I can't believe this whole HUUUGE thread is dedicated to trying to
persuade a troll!
--
a game sig: http://tinyurl.com/d3rxz9
[c.l.j.p stripped from 'froups.]
On May 22, 3:00 pm, namekuseijin <············@gmail.com> wrote:
> Series Expansion escreveu:
> [snip crap]
One of the Google "Sponsored Links" I saw for this thread advertises a
free colon cleanse. Appropriate, huh?
> I can't believe this whole HUUUGE thread is dedicated to trying to
> persuade a troll!
Hey now, it's dedicated to trying to persuade *two* trolls.
Cheers,
Pillsy
On May 22, 3:26 pm, Pillsy <·········@gmail.com> wrote:
> [c.l.j.p stripped from 'froups.]
How dishonest of you, badmouthing me and trying to do it behind my
back.
> On May 22, 3:00 pm, namekuseijin <············@gmail.com> wrote:
> > Series Expansion escreveu:
> > [snip crap]
I did not write "crap".
> One of the Google "Sponsored Links" I saw for this thread advertises a
> free colon cleanse. Appropriate, huh?
Yes; yours definitely could use a very thorough cleaning. It's
dribbling crap into comp.lang.lisp.
> > I can't believe this whole HUUUGE thread is dedicated to trying to
> > persuade a troll!
> Hey now, it's dedicated to trying to persuade *two* trolls.
No, it is not. I can't speak for Seamus (who I assume is the other
target of your petty name-calling) but I am not one.
Regardless, these tiresome personal attacks do not constitute rational
arguments in favor of either Lisp or Java, Pillsy.
On May 22, 3:00 pm, namekuseijin <············@gmail.com> wrote:
> Series Expansion escreveu:
> [snip crap]
No, I did not excrete crap. I posted a rational argument against the
assertion that Lisp was superior to Java.
Furthermore, my bodily functions are irrelevant here. Additionally,
they constitute a vulgar topic inappropriate for public discussion.
Please make no further reference to them.
> I can't believe this whole HUUUGE thread is dedicated to trying to
> persuade a troll!
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, namekuseijin.
On 17 maio, 02:29, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:24 pm, gugamilare <··········@gmail.com> wrote:
>
> > On 16 maio, 16:51, Series Expansion <·······@gmail.com> wrote:
> > > On May 16, 1:36 am, Adlai <·········@gmail.com> wrote:
> > > > On May 16, 8:10 am, Series Expansion <·······@gmail.com> wrote:
> > > > > Text editors don't do syntactic analysis. They deal strictly in ASCII
> > > > > strings.
>
> > > > Yeah, and you read the ASCII string and do syntactic analysis on it!
>
> > > No, YOU read the ASCII string and do syntactic analysis on it. I
> > > prefer to have tools that will do that sort of crap for me.
>
> > 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.
>
> > > > Emacs has this power for two reasons (that I know of off the top of my
> > > > head):
> > > > 1) It's written in a dialect of Lisp
>
> > > To you guys, Lisp is like some magic elixir that grants lifelike
> > > behavior and extraordinary properties to anything infused with it,
> > > isn't it?
>
> > 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.
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, I've got news for you. Here in the real world, there ain't no
> > > silver bullet. No philosopher's stone. No magic spell a wizard can
> > > cast to make brooms come to life and carry water or whatever. Instead,
> > > we have this thing called "engineering". We actually have to figure
> > > something out and then build it to run on ordinary electricity or
> > > gasoline. And if something is impossible, it just plain won't work.
>
> > 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.
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.)
>
> > > > Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
> > > > SOURCE CODE.
>
> > > Apparently, gugamilare disagrees.
>
> > 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.
Okay, we have a deal then.
>
> > > > When you test a macro using the MACROEXPAND form, you evaluate that
> > > > separately, in a Lisp prompt, or in a separate prompt opened by slime,
> > > > the way a normal IDE does.
>
> > > Prompts are so 1985. And wouldn't you need an MDI window system to
> > > have anywhere else for it to expand into BESIDES your source file?
>
> > 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.
So does Emacs + Slime.
>
> > 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.
But you invoke make from the command line. Or at least this is the way
that it is done many times.
>
> > 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.
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.
>
> > > > Defining dependencies is ... something that macros do for you.
>
> > > 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.
Another very good argument!!! I can't respond to that.
>
> > > SLIME must be magic, then, if it can grant the editor the knowledge
> > > that SuperVGA has been invented from *inside its internal script
> > > interpreter* without even a droplet of native C code to actually talk
> > > to the display hardware. It's amazing! It's fantastic! It makes
> > > Windows Plug'n'Pray obsolete! It's ... slime!
>
> > 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,
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.
>
> > 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!
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.
>
> > 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?
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.
>
> > > Well, it's that or someone was wrong about SLIME being written
> > > entirely in an editor's scripting language, or you're wrong about what
> > > it can do, or (least plausible of all) someone's definition of
> > > "powerful IDE" allows the possibility of one being a prompt-driven
> > > terminal-mode archaism from the 80s.
>
> > 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...
So why is it so hard to believe that Emacs + Slime also can?
gugamilare wrote:
Series Expansion wrote:
>> NEVER order me around like I'm your personal slave again.
Series! Shut up! Go away! And close the door on your way out, boy!
>> 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.
Apparently you don't need drugs in order to mimic psychosis.
--
Lew
On May 17, 1:22 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > Series Expansion wrote:
> >> NEVER order me around like I'm your personal slave again.
>
> Series! Shut up! Go away! And close the door on your way out, boy!
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
Furthermore, nothing gives you the right to demand people shut up,
either in comp.lang.java.programmer or comp.lang.lisp. Neither
newsgroup is moderated, in particular, and I reside in a country with
strong guarantees of freedom of speech.
So no, I will not shut up.
> >> 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.
>
> Apparently you don't need drugs in order to mimic psychosis.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
N.B. You posted this miserable excuse for a news article as a response
to a post by gugamilare, but the only line of his you even quoted was
the line in which he had attributed some quoted text to me, and you
did not respond to anything written by gugamilare. It seems your post
was intended as a reply to the same post of mine that gugamilare had
replied to, rather than to gugamilare's reply. Please try to be more
careful in the future.
gugamilare <··········@gmail.com> writes:
> 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.
But emacs can also show "balloons": (tooltip-show "Hello world"). But
I don't like when it does, I prefer it to use the mini-buffer or split
a new window.
--
__Pascal Bourguignon__
On 17 maio, 10:41, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> gugamilare <··········@gmail.com> writes:
> > 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.
>
> But emacs can also show "balloons": (tooltip-show "Hello world"). But
> I don't like when it does, I prefer it to use the mini-buffer or split
> a new window.
I agree, the mini-buffer is the best. It does not take your attention
from what you are doing like "balloons", but it still provides the
information anyway.
On May 17, 9:50 am, gugamilare <··········@gmail.com> wrote:
> I agree, the mini-buffer is the best. It does not take your attention
> from what you are doing like "balloons", but it still provides the
> information anyway.
Tray notifications or a status bar can be used in GUIs to achieve the
same effect. GUIs present the application designer with an additional
option, though, which is to pop up urgent information, or almost-
certainly-desired information, right near where the user's eyes are
probably looking. It won't sometimes accidentally go unnoticed for
hours.
As with any feature, overuse or misuse of it can irritate and detract
from usability.
A further thing that software designed to run (only) on modern
hardware can use is sound, for example a gentle and nonobtrusive chime
to announce possibly-useful but non-urgent events (e.g. you have mail,
or a download has finished, or there's a tip displayed in the status
area), versus a loud buzz to warn of imminent danger (e.g. a delete is
too large to undo, are you sure?).
On May 17, 9:41 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> gugamilare <··········@gmail.com> writes:
> > 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.
>
> But emacs can also show "balloons": (tooltip-show "Hello world").
How, like this?
___________________
| balloon text here |
~~~~~~~~~~~~~~~~~~~
The problem with that sort of thing is that it cannot, at a glance, be
identified; the same pattern of characters on the display could result
if the above box-and-text were literally present in the text being
edited.
A GUI text editor lacks this difficulty, as it can display a proper
balloon with graphical borders and a yellow background, and this can
readily be distinguished from anything that could ever be present in
text.
(The problem rearises with image-editing software, when users edit
screenshots of GUIs: the GUI features shown in the screen shot may
look the same as actual GUI features of the system on which the
editing is being done. The usual effect is to slow the user down
somewhat and have little effect otherwise, though, so it doesn't seem
to be severe.)
> I prefer it to use the mini-buffer or split a new window.
How cumbersome.
On May 17, 2:03 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 02:29, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 4:24 pm, gugamilare <··········@gmail.com> wrote:
> > > 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.
>
> 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.
> > 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.
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.
> > 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.
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.)
> > 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.
Well, there you go, then.
> > > 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.
>
> 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.
> > > 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.
>
> 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.
> > > 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.
>
> Emacs + Slime also does that.
Emacs is physically incapable of providing one-click anything, unless
you mean a key-click.
> > 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.
Perhaps. I maintain that one would not wish to actually enter the bulk
of one's code at it.
> > > > SLIME must be magic, then, if it can grant the editor the knowledge
> > > > that SuperVGA has been invented from *inside its internal script
> > > > interpreter* without even a droplet of native C code to actually talk
> > > > to the display hardware. It's amazing! It's fantastic! It makes
> > > > Windows Plug'n'Pray obsolete! It's ... slime!
>
> > > 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,
>
> 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.
> > > 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!
>
> 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.
> > > 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?
>
> 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.
> > > 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...
>
> 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.
On 17 maio, 02:29, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:24 pm, gugamilare <··········@gmail.com> wrote:
> > 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.
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.
>
> > 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.
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.
On May 17, 9:13 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 02:29, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 4:24 pm, gugamilare <··········@gmail.com> wrote:
> > > 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.
>
> 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.
>
>
>
> > > 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.
>
> 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.
Adlai wrote:
> 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.
And yet it continues.
--
Lew
Thank you all for participation in this thread! Including our good
friends Series and Seamus, without whom this marvellous trip to the
zoo would never have happened, and Lew, for pointing out the 'DO NOT
FEED THE TROLL' sign.
I really hope you have a good day. Even you, Mr Expansion. I hope you
have a very mind-opening, consiousness-raising day, because you need
it.
Over and out.
- Adlai
Adlai wrote:
> Thank you all for participation in this thread! Including our good
> friends Series and Seamus, without whom this marvellous trip to the
> zoo would never have happened
Comparing your opponent to a zoo animal is not a valid debating tactic.
Please hang up and try your call again.
> [rest deleted]
On May 17, 1:25 pm, Lew <·····@lewscanon.com> wrote:
> Adlai wrote:
> > 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.
>
> And yet it continues.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Adlai.
Series Expansion wrote:
> On May 17, 1:25 pm, Lew <·····@lewscanon.com> wrote:
>> Adlai wrote:
>>> 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.
>> And yet it continues.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew" and Adlai.
That was not a personal attack, but noting a fact.
Arne
On May 20, 9:45 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 17, 1:25 pm, Lew <·····@lewscanon.com> wrote:
> >> Adlai wrote:
> >>> 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.
> >> And yet it continues.
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, "Lew" and Adlai.
>
> That was not a personal attack, but noting a fact.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne, "Lew", and Adlai.
On May 17, 2:28 am, Adlai <·········@gmail.com> wrote:
> On May 17, 9:13 am, gugamilare <··········@gmail.com> wrote:
> > 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.
The above personal attack, directed at me, is addressed in more detail
in my direct response to gugamilare.
> > 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.
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.
gugamilare wrote:
> 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.
This whole thread was cross-posted to begin with. You are mistaken. It's
shown up in clj.programmer from before it devolved into a Lisp flamewar.
--
Lew
On May 17, 1:24 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > 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.
>
> This whole thread was cross-posted to begin with. You are mistaken. It's
> shown up in clj.programmer from before it devolved into a Lisp flamewar.
Unmentioned, but noteworthy, is the fact that you, "Lew", had posted
by far the majority of the personal attacks in this thread at this
point. In all probability, then, *you* are singlehandedly responsible
for it having "devolved into a flamewar".
On May 17, 2:13 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 02:29, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 4:24 pm, gugamilare <··········@gmail.com> wrote:
> > > 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.
>
> 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.
> > > 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.
>
> 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
<·················@Yahoo.Com>, 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.
From: I V
Subject: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <4a0fa4f6@news.x-privat.org>
On Sat, 16 May 2009 22:29:31 -0700, Series Expansion wrote:
> 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
Just like Emacs!
> simply cannot do (and sometimes cannot even fake in a half-assed way)
> with a single undivided, rigid rectangular grid of ASCII-only
> characters.
Just like Emacs!
> 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.
Just like Emacs!
> Well, your suggestion that because a certain terminal-oriented editor's
> internal scripting language is a dialect of Lisp, you can write a script
Nobody's talking about a terminal-oriented editor. They're talking about
Emacs, which has been a window-based application since the mid-1980s.
> 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.
Nobody's talking about a curses-based unix editor from the seventies.
They're talking about Emacs, which is a working modern GUI program with
multiple overlapping windows and menus.
Series Expansion wrote:
>> Well, your suggestion that because a certain terminal-oriented editor's
>> internal scripting language is a dialect of Lisp, you can write a script
I V wrote:
> Nobody's talking about a terminal-oriented editor. They're talking about
> Emacs, which has been a window-based application since the mid-1980s.
Paul is infamous for this intentional misapprehension of emacs, among other
things.
>> 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.
> Nobody's talking about a curses-based unix editor from the seventies.
> They're talking about Emacs, which is a working modern GUI program with
> multiple overlapping windows and menus.
Clearly "Series" is goading you by lying about emacs.
--
Lew
On May 17, 1:20 pm, Lew <·····@lewscanon.com> wrote:
[attributions fixed up]
> I V wrote:
> > Series Expansion wrote:
> >> Well, your suggestion that because a certain terminal-oriented editor's
> >> internal scripting language is a dialect of Lisp, you can write a script
> > Nobody's talking about a terminal-oriented editor. They're talking about
> > Emacs, which has been a window-based application since the mid-1980s.
>
> Paul is infamous for this intentional misapprehension of emacs, among other
> things.
Paul Foley has written little, if anything, in this thread about
emacs. No other Pauls are in evidence. This remark seems to be
confused.
Furthermore, these tiresome personal attacks do not constitute
rational arguments in favor of either emacs or Eclipse, "Lew" and I
V.
Last but not least, emacs is a terminal-mode editor. I should know --
I've used it, extensively during the 90s on one particular remote
system and occasionally before and since.
> >> 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.
> > Nobody's talking about a curses-based unix editor from the seventies.
>
> Clearly "Series" is goading you by lying about emacs.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew" and I V.
And emacs is a curses-based unix editor from the seventies. A tiny bit
of Web research will reveal that the first version was written between
January 1, 1970 and December 31, 1979 (inclusive) and that it is now
primarily used on unix systems; its source code #includes something
whose name contains "curses" just to round things out.
Series Expansion wrote:
> On May 17, 1:20 pm, Lew <·····@lewscanon.com> wrote:
> [attributions fixed up]
>> I V wrote:
>>> Series Expansion wrote:
>>>> Well, your suggestion that because a certain terminal-oriented editor's
>>>> internal scripting language is a dialect of Lisp, you can write a script
>>> Nobody's talking about a terminal-oriented editor. They're talking about
>>> Emacs, which has been a window-based application since the mid-1980s.
>> Paul is infamous for this intentional misapprehension of emacs, among other
>> things.
>
> Paul Foley has written little, if anything, in this thread about
> emacs. No other Pauls are in evidence. This remark seems to be
> confused.
Read the thread more careful and you would see that he is referring
to Paul Derbyshire.
> Last but not least, emacs is a terminal-mode editor. I should know --
> I've used it, extensively during the 90s on one particular remote
> system and occasionally before and since.
Nope.
It is an editor that supports both text and GUI mode.
There is this great thing called Wikipedia where you can
learn about think that you do not know about. Lisp is
likely to be too big a topic to learn about via Wikipedia,
but Emacs is OK:
http://en.wikipedia.org/wiki/Emacs
The fact that you did not have access to X display or were
not aware that Emacs supported X does not prove anything
(except maybe lack of HW or lack of skills).
> And emacs is a curses-based unix editor from the seventies. A tiny bit
> of Web research will reveal that the first version was written between
> January 1, 1970 and December 31, 1979 (inclusive) and that it is now
> primarily used on unix systems; its source code #includes something
> whose name contains "curses" just to round things out.
If *YOU* do the web research (link given above) then you would
see that Emacs contains a lot more than it did when it was
implemented on top of TECO.
Arne
On May 20, 9:44 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 17, 1:20 pm, Lew <·····@lewscanon.com> wrote:
> > [attributions fixed up]
> >> I V wrote:
> >>> Series Expansion wrote:
> >>>> Well, your suggestion that because a certain terminal-oriented editor's
> >>>> internal scripting language is a dialect of Lisp, you can write a script
> >>> Nobody's talking about a terminal-oriented editor. They're talking about
> >>> Emacs, which has been a window-based application since the mid-1980s.
> >> Paul is infamous for [calls Paul a liar]
>
> > Paul Foley has written little, if anything, in this thread about
> > emacs. No other Pauls are in evidence. This remark seems to be
> > confused.
>
> Read the thread more careful and you would see that he is referring
> to Paul Derbyshire.
As explained previously, I find it necessary to assume that all
insults aimed at "Paul D." here are actually intended for me, and
respond in both of our defense. To set the record straight:
* I am not Paul.
* None of the nasty things that you have said or implied are
true of me.
* I don't know whether the insults are true of Paul, but I
very much doubt that he'd appreciate you insulting him behind
his back.
> [rest deleted]
On May 22, 6:20 am, Jerry Gerrone <·········@gmail.com> wrote:
> On May 20, 9:44 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> > Read the thread more careful and you would see that he is referring
> > to Paul Derbyshire.
This remark by Arne is unsupported by any evidence.
> As explained previously, I find it necessary to assume that all
> insults aimed at "Paul D." here are actually intended for me, and
> respond in both of our defense.
Explained where? This does not seem logical.
> To set the record straight:
>
> * I am not Paul.
> * None of the nasty things that you have said or implied are
> true of me.
> * I don't know whether the insults are true of Paul, but I
> very much doubt that he'd appreciate you insulting him behind
> his back.
Fascinating, but hardly relevant to the matter of Lisp vs. Java.
On May 20, 9:44 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 17, 1:20 pm, Lew <·····@lewscanon.com> wrote:
> > [attributions fixed up]
> >> I V wrote:
> >>> Series Expansion wrote:
> >>>> Well, your suggestion that because a certain terminal-oriented editor's
> >>>> internal scripting language is a dialect of Lisp, you can write a script
> >>> Nobody's talking about a terminal-oriented editor. They're talking about
> >>> Emacs, which has been a window-based application since the mid-1980s.
> >> Paul is infamous for this intentional misapprehension of emacs, among other
> >> things.
>
> > Paul Foley has written little, if anything, in this thread about
> > emacs. No other Pauls are in evidence. This remark seems to be
> > confused.
>
> Read the thread more careful and
Fascinating. More unprovoked rudeness.
> you would see that he is referring to Paul Derbyshire.
There have been two Pauls in the thread: Paul Foley, whom I had
already noticed, and Paul Donnelly. I have not seen a Paul Derbyshire.
> > I've used it, extensively during the 90s on one particular remote
> > system and occasionally before and since.
>
> Nope.
I HAVE used it, extensively during the 90s on one particular remote
system and occasionally before and since.
> There is this great thing called Wikipedia where you can
> learn about think that you do not know about.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
> or lack of skills).
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
> > And emacs is a curses-based unix editor from the seventies. A tiny bit
> > of Web research will reveal that the first version was written between
> > January 1, 1970 and December 31, 1979 (inclusive) and that it is now
> > primarily used on unix systems; its source code #includes something
> > whose name contains "curses" just to round things out.
>
> If *YOU* do the web research (link given above) then
Why repeat it?
> you would see that Emacs contains a lot more than it did when
> it was implemented on top of TECO.
Well, yes; when it was ported to C as GOSMACS Gosling had to basically
reimplement half of TECO to do it, since C's facilities (especially
the C they used back then!) are so primitive.
On May 17, 1:47 am, I V <·······@gmail.com> wrote:
> On Sat, 16 May 2009 22:29:31 -0700, Series Expansion wrote:
> > 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
>
> 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.
> > Well, your suggestion that because a certain terminal-oriented editor's
> > internal scripting language is a dialect of Lisp, you can write a script
>
> 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.
> > 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.
>
> 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.
Series Expansion wrote:
>> Emacs
>
> It's a text editor. A text editor won't know Lisp source from Java
> source, or either from a letter to Grandma.
And you don't know your butt from a hole in the ground. You've proven nothing.
> I am not trolling. Lispers fired the first shots in this little teapot-
Yes, you are, you liar.
> 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.
Nothing in your diatribes suggests reason.
> I don't know if anyone here is trolling,
Look in the mirror.
> aside from the OP with his umpteenth joblessness whine, to be honest.
You, honest? That's a laugh!
--
Lew
On May 17, 1:18 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
[an attribution is missing here, presumably deleted by "Lew"]
> >> Emacs
>
> > It's a text editor. A text editor won't know Lisp source from Java
> > source, or either from a letter to Grandma.
>
> And you don't know your butt from a hole in the ground.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".
> > I am not trolling. Lispers fired the first shots in this little teapot-
>
> Yes, you are, you liar.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".
> > 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.
>
> Nothing in your diatribes suggests reason.
There is little in my posts *but* reason, liar.
> > I don't know if anyone here is trolling,
>
> Look in the mirror.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".
> > aside from the OP with his umpteenth joblessness whine, to be honest.
>
> You, honest? That's a laugh!
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".
Series Expansion <·······@gmail.com> writes:
> On May 16, 4:24�pm, gugamilare <··········@gmail.com> wrote:
>> On 16 maio, 16:51, Series Expansion <·······@gmail.com> wrote:
>> > On May 16, 1:36�am, Adlai <·········@gmail.com> wrote:
>> > > On May 16, 8:10�am, Series Expansion <·······@gmail.com> wrote:
>> > > > Text editors don't do syntactic analysis. They deal strictly in ASCII
>> > > > strings.
>>
>> > > Yeah, and you read the ASCII string and do syntactic analysis on it!
>>
>> > No, YOU read the ASCII string and do syntactic analysis on it. I
>> > prefer to have tools that will do that sort of crap for me.
>>
>> 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.
LOL
--
__Pascal Bourguignon__
On May 17, 9:23 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > It's a text editor. A text editor won't know Lisp source from Java
> > source, or either from a letter to Grandma.
>
> LOL
Non-sequitur. Your response is irrational and does not constitute an
argument in favor of Lisp or against Java.
Series Expansion wrote:
>>> Text editors don't do syntactic analysis. They deal strictly in ASCII
>>> strings.
Man, your text editor must be a dinosaur! How can you program in Java with
that obsolete piece of crap?
My text editors, including emacs, BTW, are capable of handling far more than
ASCII characters. Given that Java requires more than ASCII to work, that's a
necessity.
> I don't tend to comply with requests that are asked of me as rudely as
> that.
No surprise there. You didn't comply with requests that were phrased
politely, either.
> Another personal attack, this time accusing me of lacking integrity
> and intellectual honesty?
You do lack those attributes. You are utterly devoid of integrity or
intellectual honesty.
> I quoted and responded to it right there, you dipshit!
What a potty-mouth response from someone who got up on the high horse of "no
personal attacks". The name you called is the thing you are, "Series Expansion".
> Please read up on etiquette, polite society, civilization, and Emily
> Post before you continue posting personal attacks!
What a hypocrite thou art. How dare you call others to account for behaviors
you exceed for nastiness and unworthiness? Fie on you, "Series". Fie! Thou
blackguard, thou poltroon. Thou infamous blot on the name of humanity, and
programmers in particular. Fie!
You wouldn't know etiquette or polite society if it bit you, "Series
Expansion", and I am certain you've never read Emily Post yourself, you worm.
You are completely unqualified to speak of civilization, you vomitous slime.
Now go away, or I shall taunt you a second time.
What a maroon.
--
Lew
A Java programmer
On May 16, 5:31 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> >>> Text editors don't do syntactic analysis. They deal strictly in ASCII
> >>> strings.
>
> Man, your text editor must be a dinosaur! How can you program in Java with
> that obsolete piece of crap?
As I have already indicated, my IDE is NetBeans, which is hardly an
"obsolete piece of crap". The sentence quoted above was in reference
to the tools used by some of the Lispers, as described in their own
admissions earlier in this thread. Therefore they are the ones using
what you so eloquently describe as an "obsolete piece of crap".
> > I don't tend to comply with requests that are asked of me as rudely as
> > that.
>
> No surprise there. You didn't comply with requests that were phrased
> politely, either.
I am under no obligation to comply with any requests posted to usenet
newsgroups by random, mostly pseudonymous users who lack any plausible
claim of authority over me.
However, it is certainly the case that the less work a request
involves, and the more politely it is phrased, the more likely I am to
choose to comply with it. The requests I have explicitly refused here
have largely had at least one of the following traits:
* Request was phrased rudely, for instance as a demand;
* Request was to install large pieces of software, sometimes even
software whose requirements would entail my altering or
replacing my machine's operating system;
* Request was to read a lengthy document, or otherwise perform a
task that would take hours or even days;
* Request was to obtain a document probably unavailable to me
without payment, and therefore for me to part with some money.
It is rather unlikely that I will part with money or replace my
operating system at the whim of the author of a possibly-fraudulent
message transmitted over a notoriously insecure network protocol. It
is even less likely that I will comply with any request phrased as a
demand, particularly one carrying an implied threat (for instance, any
ending with "or else") or accompanied by personal attacks or similarly
hostile verbiage (for instance, "please read this web page, idiot"
followed by a URL).
> > Another personal attack, this time accusing me of lacking integrity
> > and intellectual honesty?
>
> You do lack those attributes. You are utterly devoid of integrity or
> intellectual honesty.
Your argument is self-refuting, and rather ironic as well. Any idiot
can plainly see that you have not managed to provide one shred of
evidence in furtherance of the claims made regarding Lisp here. As far
as the debate is concerned, what you've just written is null and void.
However, your proffering it here as somehow evidence of Lisp's
superiority is an indication that the statements you made about me,
while erroneous, would be true if applied to yourself. Hence the
irony.
> > I quoted and responded to it right there, you dipshit!
>
> What a potty-mouth response from someone who got up on the high horse of "no
> personal attacks".
You'll forgive the outburst. It is ... frustrating ... when someone is
so blatantly either blinkered or outright dishonest. A slightly
cleverer person would have trimmed the portion of the quoted text that
refuted their erroneous statement. A truly intelligent one would not
have made that statement in the first place, knowing that it could
still be readily refuted, for instance using Google's archive.
> The name you called is the thing you are, "Series Expansion".
Here is another dose of irony. Immediately after accusing me of being
a "potty-mouth" you use the very same insult on me that I used on
gugamilare. You have apparently lost control of yourself and allowed
emotion to overrule reason.
I find it perplexing that people can get so worked up over an obscure
technical point regarding programming-language features. It is as
though livelihoods, lives, even whole nations might rise or fall
depending upon the outcome of the debate, though logic suggests that
the outcome will in fact have little or no effect on even the software
industry; tomorrow it will in all likelihood be business as usual,
with roughly the same market shares among Java, Lisp, C, and other
languages as prevailed a week ago.
> > Please read up on etiquette, polite society, civilization, and Emily
> > Post before you continue posting personal attacks!
>
> What a hypocrite thou art.
Certainly no more than you are.
> How dare you call others to account for behaviors you exceed for nastiness
> and unworthiness?
Exceed? I find that difficult to believe. Whereas I have had the one
outburst of "dipshit", you have had at least a dozen posts veritably
foaming at the mouth with personal attacks directed at not only myself
but numerous personages. Many of the comp.lang.lispers have also
produced at least two substantial flames during the course of this
thread. Yet you assert that my single, one-word flame exceeds this
rather voluminous outpouring of vitriol?
One should probably refrain from programming computers that has
difficulty grasping the ordering of the real numbers. Or at least
refrain from implementing java.util.Comparator.
> Fie on you, "Series". Fie! Thou blackguard, thou poltroon.
> Thou infamous blot on the name of humanity, and programmers
> in particular. Fie!
Fascinating. Hyperbole, a clear failure of perspective, and apparently
a confusion of a Lisp vs. Java debate for a Shakespearean stage, all
in one single paragraph. Absolutely fascinating.
> You wouldn't know etiquette or polite society if it bit you, "Series
> Expansion", and I am certain you've never read Emily Post yourself, you worm.
> You are completely unqualified to speak of civilization, you vomitous slime.
> Now go away, or I shall taunt you a second time.
>
> What a maroon.
Though the errors in the above are numerous, I shall make explicit
note of only one: that the above, in particular, makes your earlier
accusations of hypocrisy, hypocrisy. Your credibility has thus been
lowered inestimably; a grave strategic blunder in these circumstances.
Your errors of fact pale into insignificance compared to that.
Series Expansion <·······@gmail.com> writes:
> Prompts are so 1985.
Notice that in 1985, GUI existed and were commercialized already for a
few years.
However, your comment seem to show that you think that GUI are better
than CLI.
I agree that GUI are generaly nice. Unfortunately they're also less
productive than CLI.
The main point here is that the theory behind GUI is that it's the
user who is working, the GUI presents to the user objects that he can
manipulate with the mouse and menus.
On the contrary, CLI are means to give orders to the computer, to let
the computer do the work.
Emacs, even when working in a GUI, shows almost only characters in its
windows, because first it's not a picture editor but a text editor,
and the point is not to let the user manipulate himself the texts, but
as much as possible to direct emacs to do the editing instead of the
user. That's why there's this mini-buffer where the user is
constantly giving commands to emacs, and that's why emacs includes a
lisp system so the user can program text modification procedures
instead of repeatitively doing them himself.
Almost all Lisp implementations contain also such a CLI, Command Line
Interface (called REPL in Lisp since it's implemented by calling the
operators READ, EVAL, PRINT and LOOP). So instead of clicking on
buttons on menues, we can give commands, and add and improve the
commands we may give to your lisp systems. This way, instead of doing
the work yourself, you can just give commands to the computer and it
will work for you.
--
__Pascal Bourguignon__
On May 16, 4:42 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > Prompts are so 1985.
>
> Notice that in 1985, GUI existed and were commercialized already for a
> few years.
They weren't commonplace, aside from the clunky old black-and-white
Macs.
> However, your comment seem to show that you think that GUI are better
> than CLI.
Doesn't that kind of go without saying? The progression has been:
toggle switches, punched cards, teletype-and-keyboard, line-oriented
monitor-and-keyboard, curses-based interfaces and their equivalents,
GUIs.
Or just look at the interfaces of personal computers:
1980 - BASIC interpreter acting as command prompt and as line editor
for BASIC code.
1990 - MS-DOS command prompt, but with Edit providing a full-screen
text-mode editor.
2000 - Windows ME with a GUI file manager and graphical Notepad text
editor.
This is called "progress".
It is notable that the older interfaces tend to remain available in
some form. In 1990, MS-DOS also had EDLIN, an "ed"-style line editor,
as well as the command prompt itself being line-oriented and in 2000,
Windows ME had the ability to spawn MS-DOS prompts and applications in
terminal emulator windows.
Unix systems have followed a similar progression, from command prompt
and ed to command prompt and emacs, vi, and ed to X Window System
workstations with graphical editors, other tools, and xterm, within
which you can run bash and ed and vi.
This is called "progress, combined with backwards compatibility".
> I agree that GUI are generaly nice. Unfortunately they're also less
> productive than CLI.
You mean, more productive. GUIs provide a lot of productivity
benefits:
* Increased screen real-estate for text. Instead of a smallish rigid
rectangular grid of ASCII characters you can have quite a large
grid, and you can use a proportional font and ditch the grid
constraint.
* Ability to display much larger character sets, foreign characters
for instance. The best pre-graphics systems could display sometimes
several of the European languages, though only one at a time, by
supporting a choice of code pages. GUIs can display the whole of
Unicode, including the very large character sets used in
far-Eastern languages, and mix them all seamlessly (modulo
reading-order differences).
* A picture is worth a thousand words. GUIs can display symbols like
a dangling plug instead of taking up much more space with the
slower-to-comprehend word "disconnected", allowing more compact and
informative status areas.
* The same thing lets GUIs put a dangling plug symbol onto a
push-button to clearly and concisely do all of these at once:
- tell you you can disconnect
- tell you one way of doing so
- provide that way of doing so
In a terminal you're stuck putting the first item in a status line
at the bottom (say, the word "connected"), the second buried in a
long help file somewhere out of immediate view, and the third bound
to some probably unguessable hotkey without browsing the help
(screen-oriented) or by typing "disconnect" and enter at some
prompt (line-oriented). The latter can still be subject to
usability problems:
- guess-the-verb, if there are several synonyms; a common culprit
is when exactly one of "quit" and "exit" works, or worse,
neither, and different ones don't work in different apps, with
none working in all
- it takes eleven input actions to type "disconnect" and hit enter
versus two, a flick of the mouse and a click, to hit a button.
For frequently-used commands the difference adds up rapidly.
- fixing the second problem worsens the first drastically. If you
make the disconnect command "dis", you solve the second problem,
but make guess-the-verb a hell of a lot worse. If you allow both
synonyms, hardly anybody is going to discover that the
abbreviation "dis" works so you fail to solve the second problem
in practice, though you do solve it in principle.
* Flexibility of workflow. The user can open and arrange various
windows to suit, move data around via copy and paste, and the like.
A terminal constrains the user to using a linear sequence of
applications, and of screens within an application, and working out
some cumbersome system of scratch files to move data around.
Copy/paste doesn't work across applications and only one screen of
one application can be used at a time.
* Web access. The web is largely unusable with lynx nowadays. With a
window system and a reasonably modern browser, you can make full
use of the world's largest free library, and you can easily
alternate between doing so and using your other software. For
instance, if you hit a snag with something and get an unusual and
cryptic diagnostic from your compiler, you can select it in the
IDE's compiler-output window or pane, alt-tab to a pre-existing
Firefox, click in the google box at top right, paste in the error
message, hit enter, click a link, and probably be reading some
useful information about the error in a matter of mere *seconds*,
if you're proficient with modern user interfaces, modern web
browsers, and your IDE. It takes significantly more time to
memorize a part of an error message on your screen, type lynx and
enter, tab a bit, type http://www.google.com, type what you can
remember of the error message, hit enter, arrow down, etc., and
eventually exit Lynx and fire up your editor to go back to your
makefile or source code. Moreover, this presupposes that the
helpful site with information on the error message is readable or
navigable at all in Lynx. (And you can thank your lucky stars that
Google itself is, or you'd really be stuck.)
* A GUI can place your current actions and work in context in various
ways. For example, a file list can be accompanied by a directory
tree, and the image files in formats your file manager recognizes
can be displayed as thumbnails, so you can find images by what you
remember them looking like and not just by what you remember their
filenames to be. Every additional way to view or find things helps,
and a lot of ways are inherently incompatible with displaying in an
ASCII terminal.
* Similarly, it can provide cues for navigating the space of
available next steps in your work, for example in the form of
buttons and menus. These can appear and disappear as they become
available or not depending on your actions, so edit/cut appears in
editable text and not in read-only text or browsing a class
hierarchy or the source code directory's file listing. This beats
the heck out of having an assortment of control-this keys or a
prompt to type verbal commands into, and, somewhere else, a long
help file listing all the commands that are ever available
anywhere, anytime. Users want to write code, fix the red-eye in
their photos, or whatever, not play guess-the-verb like it was an
Infocom text adventure game ("Oops! All of your data has just been
erased. Play again? Y/N") or play the 101-key piano (which
invariably not only results in recurrent trips to the online help,
if there even is any, but leads to other problems too, such as
typing something and suddenly the application does something wacky
with no obvious way to undo it, because you typo'd in something it
apparently finds meaningful).
* A window system also supports *user* multitasking. For example, if
you get email, it can chime or show a tray notification or both,
and if you decide to check it, you can tab to it right away
instead of having to drop everything, fire up an email client, and
poke around in a cryptic interface to make it connect, download
the new message, and display it. Indeed, it can be downloading
your mail as it arrives, quietly, and even classifying and
discarding much of the spam for you, only alerting you when
something it thinks is legitimate shows up, and having that
already displayed by the time you alt-tab to its window from your
work. All of this is doubly useful if you're waiting for a
task-related email, such as a reply to a post on a project
mailing list that you expect to carry information you can use.
Often the balloon help in the tray will show the subject of the
incoming email, too -- if it's "[foo-dev-l] Re: file status API"
you're golden, and if it's "EN1ARG3 YU0R P3N15 T0DAY!!!" you
can safely ignore it.
If point-by-point arguments bore you, here's the nutshell,
metaphorical version too: after using a GUI, using anything more
primitive feels like flying a plane with no instruments, a keyhole-
sized cockpit window to peer out of, and a control stick you have to
talk to rather than simply pull, push, and turn with your hands.
At night.
In fog.
> The main point here is that the theory behind GUI is that it's the
> user who is working, the GUI presents to the user objects that he can
> manipulate with the mouse and menus.
>
> On the contrary, CLI are means to give orders to the computer, to let
> the computer do the work.
Yes. This means:
The GUI is most useful when the user is doing creative tasks, such as
writing novel code, or doing image, 3D, or similar tasks that
absolutely require graphics to show the user their work and that
benefit extremely from having a pointing device as one input tool.
The CLI is most useful for firing off commands that do something
noninteractive, such as building the source tree and generating the
distribution zipfile, or bundling up the source tarball, or things
like that, or doing batch file renames or other such filesystem
administrivia.
Even then a GUI can be useful. For example, a GUI editor to edit the
makefile before the build, or an IDE with a built-in debugger with a
debugging prompt in its debugger window (a CLI inside a GUI!), or a
file manager that lets you grab files and mass-manipulate them by
mouse for when you just want to "take all these and move them here"
rather than do anything sophisticated like "move all the files dated
before July whose names contain foo to the directory whose name is
their modification date", which requires some kind of wildcard
trickery.
Oh, wait -- even then a GUI can sometimes be better! If it has a good
multi-criteria search tool, your graphical filemanager can be made to
display just the files with the appropriate criteria, and you can grab
them and drag them about. The added advantage is that while it's
displaying the results and before you do anything to them, you can
glance at them and see if there's anything that shouldn't be there, or
anything missing that should be there. So another GUI point:
* More visual feedback on the work being performed and its
progress can help reduce errors as well as provide richer
feedback as to whether, and how quickly, a task is
proceeding.
It can be quite disconcerting to tell a CLI to move some files and
just have the prompt reappear: did it even do anything? Even more so
to tell it to move some files and have it appear to hang.
Versus seeing the files appear one by one in the destination folder,
and if it's taking long enough, a clock counting down the estimated
time remaining until the job's done. And being easily able to do
something else (except if it involves those files) in the meantime.
> and the point is not to let the user manipulate himself the texts, but
> as much as possible to direct emacs to do the editing instead of the
> user.
This is problematical. Writing program code is a largely un-
automatable task, aside from generating parser skeletons from grammars
and GUI code from forms. We have bison for the former, and if you're
generating GUI code you're generally doing it from an actual GUI!
So your dream of being able to just type "write the implementation of
the Foo.bar() method for me" and enter at a prompt and get useful code
out if it is not likely to be fulfilled anytime soon.
So much for directing the editor to do the editing; you'll just have
to type "public void bar () {" and figure out and type in the logic
all on your own. A smart IDE will generate the declaration and the
line with the close brace for you and position the cursor in the
middle with one mouse click -- no need for typing in keyboard commands
-- but that's as far as it will go. And that only if the class
implements an interface or it can otherwise infer the need for this
method.
There's one major exception: NetBeans can generate getters and setters
for a private field, with the appropriate names derived from the name
of the field. Some other predictable boilerplate sorts of code it can
likewise generate for you. You lispers claim to do the equivalent in
Lisp code using Lisp macros, so all of the Lisp code you actually
edit, in theory, is non-automatically-generatable, and thus no code
generation features in your editor or IDE seem useful or necessary.
Whereas the NetBeans ones that are useful for Java development clearly
are not incompatible with the editor being a GUI one instead of a
command line one.
> So instead of clicking on buttons on menues, we can give commands, and
> add and improve the commands we may give to your lisp systems.
Many major GUI applications provide equivalent capabilities. In Word
for example you can write VBScript to do something novel to a document
and then give it an icon and add it to your toolbar, or bind it to a
control-shift-foo type hotkey, or both. NetBeans has a templating
language for customizing its code generation, and is open source, so
you can hack NetBeans itself if hacking in the templating language
won't suffice. New templates appear in appropriate places in the
menus. Eclipse is even more modular and reprogrammable, using Java and
SWT. It can even be turned into a non-IDE tool such as a word
processor.
> This way, instead of doing the work yourself, you can just
> give commands to the computer and it will work for you.
If the Lisp code you're editing can be generated automatically,
shouldn't you be using a Lisp macro instead of having your editor
churn it out? Then you can just change the macro later instead of
every spot where the editor did whatever it did.
Your arguments in favor of a command-driven editor instead of a normal
one appear to contradict your arguments in favor of Lisp macros. I'm
afraid you'll have to pick exactly one of those to continue to
support, or else lose credibility in both debates.
On 17 maio, 03:55, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:42 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Series Expansion <·······@gmail.com> writes:
> > > Prompts are so 1985.
>
> > Notice that in 1985, GUI existed and were commercialized already for a
> > few years.
>
> They weren't commonplace, aside from the clunky old black-and-white
> Macs.
>
> > However, your comment seem to show that you think that GUI are better
> > than CLI.
>
> Doesn't that kind of go without saying? The progression has been:
> toggle switches, punched cards, teletype-and-keyboard, line-oriented
> monitor-and-keyboard, curses-based interfaces and their equivalents,
> GUIs.
>
> Or just look at the interfaces of personal computers:
> 1980 - BASIC interpreter acting as command prompt and as line editor
> for BASIC code.
> 1990 - MS-DOS command prompt, but with Edit providing a full-screen
> text-mode editor.
> 2000 - Windows ME with a GUI file manager and graphical Notepad text
> editor.
>
> This is called "progress".
>
> It is notable that the older interfaces tend to remain available in
> some form. In 1990, MS-DOS also had EDLIN, an "ed"-style line editor,
> as well as the command prompt itself being line-oriented and in 2000,
> Windows ME had the ability to spawn MS-DOS prompts and applications in
> terminal emulator windows.
>
> Unix systems have followed a similar progression, from command prompt
> and ed to command prompt and emacs, vi, and ed to X Window System
> workstations with graphical editors, other tools, and xterm, within
> which you can run bash and ed and vi.
>
> This is called "progress, combined with backwards compatibility".
>
> > I agree that GUI are generaly nice. Unfortunately they're also less
> > productive than CLI.
>
> You mean, more productive. GUIs provide a lot of productivity
> benefits:
>
> * Increased screen real-estate for text. Instead of a smallish rigid
> rectangular grid of ASCII characters you can have quite a large
> grid, and you can use a proportional font and ditch the grid
> constraint.
Emacs can also have a large grid. It has windows.
> * Ability to display much larger character sets, foreign characters
> for instance. The best pre-graphics systems could display sometimes
> several of the European languages, though only one at a time, by
> supporting a choice of code pages. GUIs can display the whole of
> Unicode, including the very large character sets used in
> far-Eastern languages, and mix them all seamlessly (modulo
> reading-order differences).
Don't you think Emacs has Unicode support? Emacs is not a frozen
ancient application, it has evolved, and that is why it still exists.
> * A picture is worth a thousand words. GUIs can display symbols like
> a dangling plug instead of taking up much more space with the
> slower-to-comprehend word "disconnected", allowing more compact and
> informative status areas.
Emacs is not different.
> * The same thing lets GUIs put a dangling plug symbol onto a
> push-button to clearly and concisely do all of these at once:
> - tell you you can disconnect
> - tell you one way of doing so
> - provide that way of doing so
> In a terminal you're stuck putting the first item in a status line
> at the bottom (say, the word "connected"), the second buried in a
> long help file somewhere out of immediate view, and the third bound
> to some probably unguessable hotkey without browsing the help
> (screen-oriented) or by typing "disconnect" and enter at some
> prompt (line-oriented). The latter can still be subject to
> usability problems:
> - guess-the-verb, if there are several synonyms; a common culprit
> is when exactly one of "quit" and "exit" works, or worse,
> neither, and different ones don't work in different apps, with
> none working in all
> - it takes eleven input actions to type "disconnect" and hit enter
> versus two, a flick of the mouse and a click, to hit a button.
> For frequently-used commands the difference adds up rapidly.
> - fixing the second problem worsens the first drastically. If you
> make the disconnect command "dis", you solve the second problem,
> but make guess-the-verb a hell of a lot worse. If you allow both
> synonyms, hardly anybody is going to discover that the
> abbreviation "dis" works so you fail to solve the second problem
> in practice, though you do solve it in principle.
> * Flexibility of workflow. The user can open and arrange various
> windows to suit, move data around via copy and paste, and the like.
Wow! Emacs does that. You don't need multiple windows to copy and
paste code, but Emacs provide them if you ask.
> A terminal constrains the user to using a linear sequence of
> applications, and of screens within an application, and working out
> some cumbersome system of scratch files to move data around.
> Copy/paste doesn't work across applications and only one screen of
> one application can be used at a time.
You clearly didn't ever use Emacs. This can be done without multiple
windows. But, still, Emacs can have multiple windows.
> * Web access. The web is largely unusable with lynx nowadays. With a
> window system and a reasonably modern browser, you can make full
> use of the world's largest free library, and you can easily
> alternate between doing so and using your other software. For
> instance, if you hit a snag with something and get an unusual and
> cryptic diagnostic from your compiler, you can select it in the
> IDE's compiler-output window or pane, alt-tab to a pre-existing
> Firefox, click in the google box at top right, paste in the error
> message, hit enter, click a link, and probably be reading some
> useful information about the error in a matter of mere *seconds*,
> if you're proficient with modern user interfaces, modern web
> browsers, and your IDE. It takes significantly more time to
> memorize a part of an error message on your screen, type lynx and
> enter, tab a bit, typehttp://www.google.com, type what you can
> remember of the error message, hit enter, arrow down, etc., and
> eventually exit Lynx and fire up your editor to go back to your
> makefile or source code. Moreover, this presupposes that the
> helpful site with information on the error message is readable or
> navigable at all in Lynx. (And you can thank your lucky stars that
> Google itself is, or you'd really be stuck.)
Emacs have even an extension that is a browser inside Emacs. And, yes,
Emacs can display pictures that the webpages have. (Someone already
said that he uses Emacs to surf on the web, but, conveniently, you
just ignored him).
> * A GUI can place your current actions and work in context in various
> ways. For example, a file list can be accompanied by a directory
> tree, and the image files in formats your file manager recognizes
> can be displayed as thumbnails, so you can find images by what you
> remember them looking like and not just by what you remember their
> filenames to be. Every additional way to view or find things helps,
> and a lot of ways are inherently incompatible with displaying in an
> ASCII terminal.
> * Similarly, it can provide cues for navigating the space of
> available next steps in your work, for example in the form of
> buttons and menus. These can appear and disappear as they become
> available or not depending on your actions, so edit/cut appears in
> editable text and not in read-only text or browsing a class
> hierarchy or the source code directory's file listing. This beats
> the heck out of having an assortment of control-this keys or a
> prompt to type verbal commands into, and, somewhere else, a long
> help file listing all the commands that are ever available
> anywhere, anytime. Users want to write code, fix the red-eye in
> their photos, or whatever, not play guess-the-verb like it was an
> Infocom text adventure game ("Oops! All of your data has just been
> erased. Play again? Y/N") or play the 101-key piano (which
> invariably not only results in recurrent trips to the online help,
> if there even is any, but leads to other problems too, such as
> typing something and suddenly the application does something wacky
> with no obvious way to undo it, because you typo'd in something it
> apparently finds meaningful).
> * A window system also supports *user* multitasking.
For the thousandth time, Emacs have a window system.
> For example, if
> you get email, it can chime or show a tray notification or both,
> and if you decide to check it, you can tab to it right away
> instead of having to drop everything, fire up an email client, and
> poke around in a cryptic interface to make it connect, download
> the new message, and display it. Indeed, it can be downloading
> your mail as it arrives, quietly, and even classifying and
> discarding much of the spam for you, only alerting you when
> something it thinks is legitimate shows up, and having that
> already displayed by the time you alt-tab to its window from your
> work. All of this is doubly useful if you're waiting for a
> task-related email, such as a reply to a post on a project
> mailing list that you expect to carry information you can use.
> Often the balloon help in the tray will show the subject of the
> incoming email, too -- if it's "[foo-dev-l] Re: file status API"
> you're golden, and if it's "EN1ARG3 YU0R P3N15 T0DAY!!!" you
> can safely ignore it.
>
> If point-by-point arguments bore you, here's the nutshell,
> metaphorical version too: after using a GUI, using anything more
> primitive feels like flying a plane with no instruments, a keyhole-
> sized cockpit window to peer out of, and a control stick you have to
> talk to rather than simply pull, push, and turn with your hands.
>
> At night.
>
> In fog.
>
> > The main point here is that the theory behind GUI is that it's the
> > user who is working, the GUI presents to the user objects that he can
> > manipulate with the mouse and menus.
>
> > On the contrary, CLI are means to give orders to the computer, to let
> > the computer do the work.
>
> Yes. This means:
>
> The GUI is most useful when the user is doing creative tasks, such as
> writing novel code, or doing image, 3D, or similar tasks that
> absolutely require graphics to show the user their work and that
> benefit extremely from having a pointing device as one input tool.
>
> The CLI is most useful for firing off commands that do something
> noninteractive, such as building the source tree and generating the
> distribution zipfile, or bundling up the source tarball, or things
> like that, or doing batch file renames or other such filesystem
> administrivia.
>
> Even then a GUI can be useful. For example, a GUI editor to edit the
> makefile before the build, or an IDE with a built-in debugger with a
> debugging prompt in its debugger window (a CLI inside a GUI!), or a
> file manager that lets you grab files and mass-manipulate them by
> mouse for when you just want to...
>
> mais »
On May 17, 1:26 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > For the thousandth time, Emacs have a window system.
>
> You should've quit before the tenth time.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew" and gugamilare.
I'd like to add that these days, anytime I feel the urge to look at a
bletcherous ASCII excuse for a "window system" I now bash myself over
the head repeatedly with my keyboard until those unnatural and
disgusting urges go away.
On May 17, 3:09 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 03:55, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 4:42 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > > I agree that GUI are generaly nice. Unfortunately they're also less
> > > productive than CLI.
>
> > You mean, more productive. GUIs provide a lot of productivity
> > benefits:
>
> > * Increased screen real-estate for text. Instead of a smallish rigid
> > rectangular grid of ASCII characters you can have quite a large
> > grid, and you can use a proportional font and ditch the grid
> > constraint.
>
> 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.
> > * Ability to display much larger character sets, foreign characters
> > for instance. The best pre-graphics systems could display sometimes
> > several of the European languages, though only one at a time, by
> > supporting a choice of code pages. GUIs can display the whole of
> > Unicode, including the very large character sets used in
> > far-Eastern languages, and mix them all seamlessly (modulo
> > reading-order differences).
>
> 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.
> > * A picture is worth a thousand words. GUIs can display symbols like
> > a dangling plug instead of taking up much more space with the
> > slower-to-comprehend word "disconnected", allowing more compact and
> > informative status areas.
>
> 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.
> > * Flexibility of workflow. The user can open and arrange various
> > windows to suit, move data around via copy and paste, and the like.
>
> 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.
> > A terminal constrains the user to using a linear sequence of
> > applications, and of screens within an application, and working out
> > some cumbersome system of scratch files to move data around.
> > Copy/paste doesn't work across applications and only one screen of
> > one application can be used at a time.
>
> 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.
> > * Web access. The web is largely unusable with lynx nowadays. With a
> > window system and a reasonably modern browser, you can make full
> > use of the world's largest free library, and you can easily
> > alternate between doing so and using your other software. For
> > instance, if you hit a snag with something and get an unusual and
> > cryptic diagnostic from your compiler, you can select it in the
> > IDE's compiler-output window or pane, alt-tab to a pre-existing
> > Firefox, click in the google box at top right, paste in the error
> > message, hit enter, click a link, and probably be reading some
> > useful information about the error in a matter of mere *seconds*,
> > if you're proficient with modern user interfaces, modern web
> > browsers, and your IDE. It takes significantly more time to
> > memorize a part of an error message on your screen, type lynx and
> > enter, tab a bit, typehttp://www.google.com, type what you can
> > remember of the error message, hit enter, arrow down, etc., and
> > eventually exit Lynx and fire up your editor to go back to your
> > makefile or source code. Moreover, this presupposes that the
> > helpful site with information on the error message is readable or
> > navigable at all in Lynx. (And you can thank your lucky stars that
> > Google itself is, or you'd really be stuck.)
>
> 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.
> > * A window system also supports *user* multitasking.
>
> 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.
> > If point-by-point arguments bore you, here's the nutshell,
> > metaphorical version too: after using a GUI, using anything more
> > primitive feels like flying a plane with no instruments, a keyhole-
> > sized cockpit window to peer out of, and a control stick you have to
> > talk to rather than simply pull, push, and turn with your hands.
>
> > At night.
>
> > In fog.
[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 wrote:
> On May 17, 3:09 am, gugamilare <··········@gmail.com> wrote:
>> On 17 maio, 03:55, Series Expansion <·······@gmail.com> wrote:
>>> On May 16, 4:42 pm, ····@informatimago.com (Pascal J. Bourguignon)
>>>> I agree that GUI are generaly nice. Unfortunately they're also less
>>>> productive than CLI.
>>> You mean, more productive. GUIs provide a lot of productivity
>>> benefits:
>>> * Increased screen real-estate for text. Instead of a smallish rigid
>>> rectangular grid of ASCII characters you can have quite a large
>>> grid, and you can use a proportional font and ditch the grid
>>> constraint.
>> 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.
Emacs has been running on X for 20 years (give or take a few).
>>> * Ability to display much larger character sets, foreign characters
>>> for instance. The best pre-graphics systems could display sometimes
>>> several of the European languages, though only one at a time, by
>>> supporting a choice of code pages. GUIs can display the whole of
>>> Unicode, including the very large character sets used in
>>> far-Eastern languages, and mix them all seamlessly (modulo
>>> reading-order differences).
>> Don't you think Emacs has Unicode support?
>
> Of course not. An ASCII editor lacks Unicode support by definition.
Wrong on two counts:
* Emacs is not (entirely) an a text mode editor
* A text mode editor can support Unicode fine vi UTF-8
[and the rest is just as wrong]
Arne
Series Expansion wrote:
>> 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.
Arne Vajhøj wrote:
> Emacs has been running on X for 20 years (give or take a few).
Forget it. Series McShameUs has been down this road before. The facts have
never convinced him, and they never will.
>>> Don't you think Emacs has Unicode support?
El Stupido embarrassed himself with:
>> Of course not. An ASCII editor lacks Unicode support by definition.
Arne bravely attempted to correct the misconceptions with:
> Wrong on two counts:
> * Emacs is not (entirely) an a text mode editor
> * A text mode editor can support Unicode fine vi UTF-8
>
> [and the rest is just as wrong]
I'm pretty convinced that Series Expansion, being a shameful liar, knows the
facts and is just goading us. Every couple of years he pops out with this
crap, gets people to attempt to educate him through facts and reason, which he
assiduously ignores, and counts the messages gloatingly, imagining in his
bi-cellular neural net that somehow this is winning and the message count is
his score. His "emacs is an ASCII, non-GUI editor" spiel is the same old
tired crap he's pulled before, just as wrong now and just as indisputably
refuted as it was the other times, but he continues nonetheless.
Series ExPaulsion is just a troll, and not even a good one at that.
--
Lew
On May 18, 10:17 pm, Lew <·····@lewscanon.com> wrote:
> Arne Vajhøj wrote:
> > Series Expansion wrote:
> >> 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.
> > Emacs has been running on X for 20 years (give or take a few).
Because there have been xterms for 20 years (give or take a few).
> Forget it. Series McShameUs has been down this road before.
Please spell my name correctly. Thank you.
> The facts have never convinced him, and they never will.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".
> >>> Don't you think Emacs has Unicode support?
>
> El Stupido
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".
> >> Of course not. An ASCII editor lacks Unicode support by definition.
>
> Arne bravely attempted to correct the misconceptions with
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".
Arne "bravely" did nothing; he launched a personal attack on an
innocent target from behind a veil of online anonymity. Such an act is
ordinarily considered one of cowardice.
> > Wrong
>
> I'm pretty convinced that Series Expansion, being a shameful liar, [rest
> deleted]
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew" and Arne.
> Every couple of years he pops out with this crap
This remark is as illogical as it is incorrect. How can someone who
has only been present for a few weeks possibly be known to do
something "every couple of years"? It is speculation in a vacuum,
devoid of any significant probability of turning out to be accurate.
> [a very large volume of nonsense]
> Series ExPaulsion
Please spell my name correctly. Thank you.
> is just a troll, and not even a good one at that.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".
Series Expansion wrote:
> On May 18, 10:17 pm, Lew <·····@lewscanon.com> wrote:
>> Arne Vajh�j wrote:
> Arne "bravely" did nothing; he launched a personal attack on an
> innocent target from behind a veil of online anonymity. Such an act is
> ordinarily considered one of cowardice.
I completely agree that anonymous posters are cowards.
The types that uses motzarella and the like to post!
Arne
On May 22, 10:35 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > Arne "bravely" did nothing; he launched a personal attack on an
> > innocent target from behind a veil of online anonymity. Such an act is
> > ordinarily considered one of cowardice.
>
> I completely agree that anonymous posters are cowards.
>
> The types that uses motzarella and the like to post!
I do not use Motzarella to post. As can be easily determined from my
post headers, I use Google Groups.
On May 18, 9:38 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 17, 3:09 am, gugamilare <··········@gmail.com> wrote:
> >> 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.
>
> Emacs has been running on X for 20 years (give or take a few).
I'm sure it's been running on X for as long as there've been xterms to
run it in.
> > An ASCII editor lacks Unicode support by definition.
>
> Wrong
[snip]
Fascinating. Arne appears to believe that Unicode is a subset of
ASCII. This is unusual and will require further investigation.
Series Expansion wrote:
> On May 18, 9:38 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>> Series Expansion wrote:
>>> On May 17, 3:09 am, gugamilare <··········@gmail.com> wrote:
>>>> 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.
>> Emacs has been running on X for 20 years (give or take a few).
>
> I'm sure it's been running on X for as long as there've been xterms to
> run it in.
Running in an xterm is not considered running on X.
Emacs has been running as a true GUI app for 20 years (give or
take a few).
>>> An ASCII editor lacks Unicode support by definition.
>>Wrong on two counts:
>>* Emacs is not (entirely) an a text mode editor
>>* A text mode editor can support Unicode fine vi UTF-8
>
> Fascinating. Arne appears to believe that Unicode is a subset of
> ASCII.
Fascinating that someone is so dumb that he can not distinguish between
the strings "UTF-8" and "ASCII" but are still capable of posting to
usenet.
Arne
On May 22, 10:33 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 18, 9:38 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Series Expansion wrote:
> >>> On May 17, 3:09 am, gugamilare <··········@gmail.com> wrote:
> >>>> 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.
> >> Emacs has been running on X for 20 years (give or take a few).
>
> > I'm sure it's been running on X for as long as there've been xterms to
> > run it in.
>
> Running in an xterm is not considered running on X.
That was precisely my point. Running in an xterm does not really
qualify you to claim to be graphical, contrary to what several other
people have implied.
> >>> An ASCII editor lacks Unicode support by definition.
> >>Wrong on two counts:
> >>* Emacs is not (entirely) an a text mode editor
> >>* A text mode editor can support Unicode fine vi UTF-8
>
> > Fascinating. Arne appears to believe that Unicode is a subset of
> > ASCII.
>
> Fascinating that someone is so dumb [rest deleted]
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, Arne.
Hand-editing UTF-8 (where it includes some double-wide characters) in
an ASCII editor is not a recommended way to edit text.
Graphics hardware, and software that acknowledges its existence, is
needed in order to display the full Unicode character set at one time.
On May 23, 10:17 pm, Series Expansion <·······@gmail.com> wrote:
> On May 22, 10:33 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
>
> > Series Expansion wrote:
> > > On May 18, 9:38 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> > >> Series Expansion wrote:
> > >>> On May 17, 3:09 am, gugamilare <··········@gmail.com> wrote:
> > >>>> 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.
> > >> Emacs has been running on X for 20 years (give or take a few).
>
> > > I'm sure it's been running on X for as long as there've been xterms to
> > > run it in.
>
> > Running in an xterm is not considered running on X.
>
> That was precisely my point. Running in an xterm does not really
> qualify you to claim to be graphical, contrary to what several other
> people have implied.
>
> > >>> An ASCII editor lacks Unicode support by definition.
> > >>Wrong on two counts:
> > >>* Emacs is not (entirely) an a text mode editor
> > >>* A text mode editor can support Unicode fine vi UTF-8
>
> > > Fascinating. Arne appears to believe that Unicode is a subset of
> > > ASCII.
>
> > Fascinating that someone is so dumb [rest deleted]
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either emacs or Eclipse, Arne.
>
> Hand-editing UTF-8 (where it includes some double-wide characters) in
> an ASCII editor is not a recommended way to edit text.
>
> Graphics hardware, and software that acknowledges its existence, is
> needed in order to display the full Unicode character set at one time.
This is a screenshot of Emacs on my machine taken right now:
http://img219.imageshack.us/img219/3889/thisisemacs.png
As you can see, it is a GUI app, and not because it's running in xterm.
On May 23, 7:18 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 23, 10:17 pm, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 22, 10:33 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
>
> > > Series Expansion wrote:
> > > > On May 18, 9:38 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> > > >> Series Expansion wrote:
> > > >>> On May 17, 3:09 am, gugamilare <··········@gmail.com> wrote:
> > > >>>> 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.
> > > >> Emacs has been running on X for 20 years (give or take a few).
>
> > > > I'm sure it's been running on X for as long as there've been xterms to
> > > > run it in.
>
> > > Running in an xterm is not considered running on X.
>
> > That was precisely my point. Running in an xterm does not really
> > qualify you to claim to be graphical, contrary to what several other
> > people have implied.
>
> > > >>> An ASCII editor lacks Unicode support by definition.
> > > >>Wrong on two counts:
> > > >>* Emacs is not (entirely) an a text mode editor
> > > >>* A text mode editor can support Unicode fine vi UTF-8
>
> > > > Fascinating. Arne appears to believe that Unicode is a subset of
> > > > ASCII.
>
> > > Fascinating that someone is so dumb [rest deleted]
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either emacs or Eclipse, Arne.
>
> > Hand-editing UTF-8 (where it includes some double-wide characters) in
> > an ASCII editor is not a recommended way to edit text.
>
> > Graphics hardware, and software that acknowledges its existence, is
> > needed in order to display the full Unicode character set at one time.
>
> This is a screenshot of Emacs on my machine taken right now:http://img219.imageshack.us/img219/3889/thisisemacs.png
For this, we have only your word, versus the overwhelming common-sense
evidence against.
On May 24, 6:32 am, Series Expansion <·······@gmail.com> wrote:
> On May 23, 7:18 pm, Alessio Stalla <·············@gmail.com> wrote:
> > This is a screenshot of Emacs on my machine taken right now:http://img219.imageshack.us/img219/3889/thisisemacs.png
>
> For this, we have only your word, versus the overwhelming common-sense
> evidence against.
Oh, of course you're right. This is actually a shot of NetBeans with
the fonts and colors changed, the text pane fully expanded, a fake
menu that explicitly mentions Emacs and a superimposed Emacs-like mode
line and minibuffer. That's the only possible rational explanation...
that doesn't go against your religious dogma that Emacs has no GUI.
Alessio
On May 24, 6:03 am, Alessio Stalla <·············@gmail.com> wrote:
> On May 24, 6:32 am, Series Expansion <·······@gmail.com> wrote:
>
> > On May 23, 7:18 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > This is a screenshot of Emacs on my machine taken right now:http://img219.imageshack.us/img219/3889/thisisemacs.png
>
> > For this, we have only your word, versus the overwhelming common-sense
> > evidence against.
>
> Oh, of course you're right.
On 24 maio, 14:31, Series Expansion <·······@gmail.com> wrote:
> On May 24, 6:03 am, Alessio Stalla <·············@gmail.com> wrote:
>
> > On May 24, 6:32 am, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 23, 7:18 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > > This is a screenshot of Emacs on my machine taken right now:http://img219.imageshack.us/img219/3889/thisisemacs.png
>
> > > For this, we have only your word, versus the overwhelming common-sense
> > > evidence against.
>
> > Oh, of course you're right.
>
>
Ah! And here is the ultimate proof of what I said in the last post.
He's just misquoted you, just like that. Why would he do this? To make
you angry, that's why!
On May 25, 5:02 pm, gugamilare <··········@gmail.com> wrote:
> On 24 maio, 14:31, Series Expansion <·······@gmail.com> wrote:
>
> > On May 24, 6:03 am, Alessio Stalla <·············@gmail.com> wrote:
>
> > > On May 24, 6:32 am, Series Expansion <·······@gmail.com> wrote:
>
> > > > On May 23, 7:18 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > > > This is a screenshot of Emacs on my machine taken right now:http://img219.imageshack.us/img219/3889/thisisemacs.png
>
> > > > For this, we have only your word, versus the overwhelming common-sense
> > > > evidence against.
>
> > > Oh, of course you're right.
>
> Ah! And here is the ultimate proof of what I said in the last post.
> He's just misquoted you, just like that. Why would he do this? To make
> you angry, that's why!
Yes, I know he does like that only to make me angry. Unfortunately,
it's hard to make me angry, I'm very stubborn, and I can't stand
people telling blatant lies and presenting them as objective truth.
(Though being Italian I'm very accustomed to that kind of behavior).
That said, I'm getting tired of this thread, and probably now it's so
huge that no one will ever want to read it, so no one has any chance
to become convinced by Series and Seamus' lies... so, mission
accomplished! :D
On May 25, 2:51 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 25, 5:02 pm, gugamilare <··········@gmail.com> wrote:
>
> > Ah! And here is the ultimate proof of what I said in the last post.
> > He's just misquoted you, just like that. Why would he do this? To make
> > you angry, that's why!
Errors or outright lies.
> Yes, I know he does like that only to make me angry.
Another one.
> Unfortunately, it's hard to make me angry, I'm very stubborn, and I
> can't stand people telling blatant lies and presenting them as
> objective truth.
Looked in a mirror?
> That said, I'm getting tired of this thread, and probably now it's so
> huge that no one will ever want to read it, so no one has any chance
> to become convinced by Series and Seamus' lies... so, mission
> accomplished! :D
I have told no lies.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Alessio and gugamilare.
On May 25, 11:02 am, gugamilare <··········@gmail.com> wrote:
> Ah! And here is the ultimate proof of what I said in the last post.
> He's just misquoted you, just like that. Why would he do this? To make
> you angry, that's why!
Lies and errors. These tiresome personal attacks do not constitute
rational arguments in favor of either Lisp or Java, gugamilare.
On 24 maio, 07:03, Alessio Stalla <·············@gmail.com> wrote:
> On May 24, 6:32 am, Series Expansion <·······@gmail.com> wrote:
>
> > On May 23, 7:18 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > This is a screenshot of Emacs on my machine taken right now:http://img219.imageshack.us/img219/3889/thisisemacs.png
>
> > For this, we have only your word, versus the overwhelming common-sense
> > evidence against.
This is impossible.
> Oh, of course you're right. This is actually a shot of NetBeans with
> the fonts and colors changed, the text pane fully expanded, a fake
> menu that explicitly mentions Emacs and a superimposed Emacs-like mode
> line and minibuffer. That's the only possible rational explanation...
> that doesn't go against your religious dogma that Emacs has no GUI.
I've already posted screenshoots of Emacs, and not some windows
running on my machine, but rather the official ones, taken from the
official Emacs page. And Series Expansion only deleted them when he
replied. He also deleted wikipedia's links to places that say that
Emacs runs on X since 198*.
Any reasonable computer user (not even a programmer) who had thought
that Emacs is still terminal-based application and who read your post
(or any post that says otherwise - and there has been lots of them)
would either believe on what you are saying or look for Emacs official
web page or, in worst scenario, he would install Emacs to see it with
his own eyes. Obviously, he has done neither. And note that he
explicitly called you a liar while he does not even allow someone to
say that he is wrong about something without accusing that person of
making a "personal attack". He's been doing this forever.
The only explanation I can conclude from this is that he is indeed
doing this on purpose. There isn't another explanation. He must have a
very strange obsession on posting lies to make people angry. Now I am
glad I quit this thread long ago (with exception of one or two very
small posts).
On May 25, 10:54 am, gugamilare <··········@gmail.com> wrote:
> On 24 maio, 07:03, Alessio Stalla <·············@gmail.com> wrote:
>
> > On May 24, 6:32 am, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 23, 7:18 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > > This is a screenshot of Emacs on my machine taken right now:http://img219.imageshack.us/img219/3889/thisisemacs.png
>
> > > For this, we have only your word, versus the overwhelming common-sense
> > > evidence against.
>
> This is impossible.
Exactly my point.
> [lots snipped; talks about me in third person, insults me, several
> other gross breaches of etiquette; even calls me a liar]
I am not.
On May 25, 10:02 pm, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> gugamilare <··········@gmail.com> writes:
> > The only explanation I can conclude from this is that he is indeed
> > doing this on purpose. There isn't another explanation. He must have a
>
> He's pretty clearly insane.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul and gugamilare.
On May 25, 7:02 pm, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
[Hey, Paul, How's it going? I like your argumentation, and the fact
that you've kept a level head this last week or two with your answers,
despite the challenges.]
> gugamilare <··········@gmail.com> writes:
> > The only explanation I can conclude from this is that he is indeed
> > doing this on purpose. There isn't another explanation. He must have a
>
> He's pretty clearly insane.
No, he's pretty clearly playing a game. The object of the game is to
keep the thread going as long as possible. He gives himself points
(i.e. the thread is still alive) for answering every post that looks
like they might be taken as a slight, and even some that can't (I love
the way he played the answer "42"... :-) And he's not going to get
tired, because he doesn't have to think of clever twists to every
answer; he just plays the same tired recording over and over again in
order to drive others insane enough to send just one more answer
(which keeps the game going). Sprinkle that with a little on-topic
but flawed logic and you have yourself a very impressive volley.
The only way he loses his game is to lose his audience, which will
happen when everyone stops answering his posts, no matter how insane
and in need of an answer they seem to be. (Or, even more insidious,
no matter how sane but slightly flawed they seem to be - this catches
the ones who are sincerely trying to help him to understand; they
answer and keep the game going).
Duane
On May 26, 3:34 am, ·····@franz.com wrote:
> On May 25, 7:02 pm, Paul Foley <····@below.invalid> (http://
>
> public.xdi.org/=pf) wrote:
>
> [Hey, Paul, How's it going? I like your argumentation, and the fact
> that you've kept a level head this last week or two with your answers,
> despite the challenges.]
He has not. Many of his posts have been laced with personal attacks,
at least implied ones.
> > gugamilare <··········@gmail.com> writes:
> > > The only explanation I can conclude from this is that he is indeed
> > > doing this on purpose. There isn't another explanation. He must have a
>
> > He's pretty clearly insane.
>
> No, he's pretty clearly playing a game.
c) None of the above.
> The object of the game is to keep the thread going as long as possible.
Actually, were it to end tomorrow, I would not be displeased, so long
as no attack on my character, expressed or implied, has gone
unrebutted.
> He gives himself points (i.e. the thread is still alive) for answering
> every post that looks like they might be taken as a slight, and even
> some that can't (I love the way he played the answer "42"... :-)
As is so commonly the case with speculations made in a vacuum, this is
incorrect. Regarding specifically the post with the 42, there was also
an alteration to the quoted material in that post that suggested that
I was crazy, a "fuckhead", or similarly -- I don't recall exactly. It
was that, not the number, to which I was responding. Though now that
you mention it, the number was rather lacking in obvious relevance,
and appeared to constitute a non sequitur.
> And he's not going to get tired, because he doesn't have to think of
> clever twists to every answer;
On the contrary, I put a great deal of thought into my
counterarguments, when presented with things reasonably approximating
rational arguments. It is only when presented with an obviously
logically void "argument" such as "Series Expansion is an idiot" that
I have responded with an uncreative copy-and-paste reply, and that
because there is nothing really to say in response to such an
"argument" except to point out that it fails to logically support the
conclusion that you wish people to draw.
> Sprinkle that with a little on-topic but flawed logic and you have
> yourself a very impressive volley.
Nothing is flawed about my logic, unlike, for instance, that of those
people who see an ad hominem argument as a valid one in support of
Lisp over Java.
> The only way he loses his game is to lose his audience, which will
> happen when everyone stops answering his posts, no matter how insane
> and in need of an answer they seem to be.
None of them are either insane or, with the exception of those that
ask a question, in need of an answer.
> (Or, even more insidious, no matter how sane but slightly flawed
> they seem to be
None of them are flawed, either.
On May 26, 10:04 pm, Series Expansion <·······@gmail.com> wrote:
> On May 26, 3:34 am, ·····@franz.com wrote:
>
> > On May 25, 7:02 pm, Paul Foley <····@below.invalid> (http://
>
> > public.xdi.org/=pf) wrote:
>
> > [Hey, Paul, How's it going? I like your argumentation, and the fact
> > that you've kept a level head this last week or two with your answers,
> > despite the challenges.]
>
> He has not. Many of his posts have been laced with personal attacks,
> at least implied ones.
>
I suppose claiming things that aren't personal attacks as personal
attacks doesn't constitute a personal attack?
> > > gugamilare <··········@gmail.com> writes:
> > > > The only explanation I can conclude from this is that he is indeed
> > > > doing this on purpose. There isn't another explanation. He must have a
>
> > > He's pretty clearly insane.
>
> > No, he's pretty clearly playing a game.
>
> c) None of the above.
>
logically, would you admit to it if you were?
> > The object of the game is to keep the thread going as long as possible.
>
> Actually, were it to end tomorrow, I would not be displeased, so long
> as no attack on my character, expressed or implied, has gone
> unrebutted.
>
The only one doing damage to your public image is you. Replying with
the same copy-paste response does more to validate the flames than
ignoring them would.
> > He gives himself points (i.e. the thread is still alive) for answering
> > every post that looks like they might be taken as a slight, and even
> > some that can't (I love the way he played the answer "42"... :-)
>
> As is so commonly the case with speculations made in a vacuum, this is
> incorrect. Regarding specifically the post with the 42, there was also
> an alteration to the quoted material in that post that suggested that
> I was crazy, a "fuckhead", or similarly -- I don't recall exactly. It
> was that, not the number, to which I was responding. Though now that
> you mention it, the number was rather lacking in obvious relevance,
> and appeared to constitute a non sequitur.
>
To some extent, it is crazy to argue so vigorously about something of
which you know very little...
> > And he's not going to get tired, because he doesn't have to think of
> > clever twists to every answer;
>
> On the contrary, I put a great deal of thought into my
> counterarguments, when presented with things reasonably approximating
> rational arguments. It is only when presented with an obviously
> logically void "argument" such as "Series Expansion is an idiot" that
> I have responded with an uncreative copy-and-paste reply, and that
> because there is nothing really to say in response to such an
> "argument" except to point out that it fails to logically support the
> conclusion that you wish people to draw.
>
Your time would be better spent learning than counter-arguing.
> > Sprinkle that with a little on-topic but flawed logic and you have
> > yourself a very impressive volley.
>
> Nothing is flawed about my logic, unlike, for instance, that of those
> people who see an ad hominem argument as a valid one in support of
> Lisp over Java.
>
The problem is that this thread has not been about 'Arguments favoring
lisp over java'.
It has been about correcting yours and Seamus MacRae's misconceptions
(which you state as fact) about Common Lisp.
And it has started appear to some, that these misconceptions may be
deliberate.
(To others it was apparent /literally/ weeks ago).
On May 26, 10:22 pm, ··················@gmail.com wrote:
[snip]
Please do not lie in wait refreshing your view of the newsgroup every
few minutes and then immediately follow up to my new posts to attack
them.
> On May 26, 10:04 pm, Series Expansion <·······@gmail.com> wrote:> On May 26, 3:34 am, ·····@franz.com wrote:
> > public.xdi.org/=pf) wrote:
>
> > > [Hey, Paul, How's it going? I like your argumentation, and the fact
> > > that you've kept a level head this last week or two with your answers,
> > > despite the challenges.]
>
> > He has not. Many of his posts have been laced with personal attacks,
> > at least implied ones.
>
> I suppose claiming things that aren't personal attacks as personal
> attacks doesn't constitute a personal attack?
I wouldn't know. And since I have done nothing of the sort, it is not
relevant anyway.
> > > > > The only explanation I can conclude from this is that he is indeed
> > > > > doing this on purpose. There isn't another explanation. He must have a
>
> > > > He's pretty clearly insane.
>
> > > No, he's pretty clearly playing a game.
>
> > c) None of the above.
>
> logically, would you admit to it if you were?
Are you calling me a liar?
> > > The object of the game is to keep the thread going as long as possible.
>
> > Actually, were it to end tomorrow, I would not be displeased, so long
> > as no attack on my character, expressed or implied, had gone
> > unrebutted.
>
> The only one doing damage to your public image is you. Replying with
> the same copy-paste response does more to validate the flames than
> ignoring them would.
Based on your behavior, I conclude that your motives in offering the
above "advice" are suspect, and therefore that what you say cannot be
trusted.
Regardless, there is nothing whatsoever wrong with my behavior. I have
nothing to be ashamed of, unlike the numerous persons rudely
speculating about me as if I were absent, calling me names, and
otherwise engaged in petty and vindictive behavior because they
couldn't convince me to convert to their religious beliefs regarding
Lisp.
> > > He gives himself points (i.e. the thread is still alive) for answering
> > > every post that looks like they might be taken as a slight, and even
> > > some that can't (I love the way he played the answer "42"... :-)
>
> > As is so commonly the case with speculations made in a vacuum, this is
> > incorrect. Regarding specifically the post with the 42, there was also
> > an alteration to the quoted material in that post that suggested that
> > I was crazy, a "fuckhead", or similarly -- I don't recall exactly. It
> > was that, not the number, to which I was responding. Though now that
> > you mention it, the number was rather lacking in obvious relevance,
> > and appeared to constitute a non sequitur.
>
> To some extent, it is crazy to argue so vigorously about something of
> which you know very little...
I know enough about myself to know that having one of my posts
misquoted as "> [brain fuck]" is an incorrect assessment of me.
> > > And he's not going to get tired, because he doesn't have to think of
> > > clever twists to every answer;
>
> > On the contrary, I put a great deal of thought into my
> > counterarguments, when presented with things reasonably approximating
> > rational arguments. It is only when presented with an obviously
> > logically void "argument" such as "Series Expansion is an idiot" that
> > I have responded with an uncreative copy-and-paste reply, and that
> > because there is nothing really to say in response to such an
> > "argument" except to point out that it fails to logically support the
> > conclusion that you wish people to draw.
>
> Your time would be better spent learning than counter-arguing.
Ignoring for the time being the factually-incorrect implied insult
contained in your remark, if you honestly believe this, and you
honestly have my best intentions at heart, then you should desist from
harassing me online and thereby free up some time from "counter-
arguing" to expend pursuing another activity, such as learning.
Quite clearly, the more you publicly argue for my mistreatment by
others, the more time I must spend in counter-arguing.
So while your words say one thing, your actions say quite the
opposite.
> > > Sprinkle that with a little on-topic but flawed logic and you have
> > > yourself a very impressive volley.
>
> > Nothing is flawed about my logic, unlike, for instance, that of those
> > people who see an ad hominem argument as a valid one in support of
> > Lisp over Java.
>
> The problem is that this thread has not been about 'Arguments favoring
> lisp over java'.
Yes, it has, although it was originally about someone's job search.
> It has been about correcting yours and Seamus MacRae's misconceptions
> [rest of post deleted unread]
I have no misconceptions.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, anonymous.c.lisper.
On May 26, 10:46 pm, Series Expansion <·······@gmail.com> wrote:
> On May 26, 10:22 pm, ··················@gmail.com wrote:
> [snip]
>
> Please do not lie in wait refreshing your view of the newsgroup every
> few minutes and then immediately follow up to my new posts to attack
> them.
I had no idea I was the one making hundreds of posts.
> > On May 26, 10:04 pm, Series Expansion <·······@gmail.com> wrote:> On May 26, 3:34 am, ·····@franz.com wrote:
> > > public.xdi.org/=pf) wrote:
>
> > > > [Hey, Paul, How's it going? I like your argumentation, and the fact
> > > > that you've kept a level head this last week or two with your answers,
> > > > despite the challenges.]
>
> > > He has not. Many of his posts have been laced with personal attacks,
> > > at least implied ones.
>
> > I suppose claiming things that aren't personal attacks as personal
> > attacks doesn't constitute a personal attack?
>
> I wouldn't know. And since I have done nothing of the sort, it is not
> relevant anyway.
>
> > > > > > The only explanation I can conclude from this is that he is indeed
> > > > > > doing this on purpose. There isn't another explanation. He must have a
>
> > > > > He's pretty clearly insane.
>
> > > > No, he's pretty clearly playing a game.
>
> > > c) None of the above.
>
> > logically, would you admit to it if you were?
>
> Are you calling me a liar?
>
No, I'm saying that your opinion on the matter doesn't have any
weight.
> > > > The object of the game is to keep the thread going as long as possible.
>
> > > Actually, were it to end tomorrow, I would not be displeased, so long
> > > as no attack on my character, expressed or implied, had gone
> > > unrebutted.
>
> > The only one doing damage to your public image is you. Replying with
> > the same copy-paste response does more to validate the flames than
> > ignoring them would.
>
> Based on your behavior, I conclude that your motives in offering the
> above "advice" are suspect, and therefore that what you say cannot be
> trusted.
>
Which behavior?
I've tried to either a.) be civil, or b.) stay out of it.
> Regardless, there is nothing whatsoever wrong with my behavior. I have
> nothing to be ashamed of, unlike the numerous persons rudely
Well, aside from the hundreds of misinformed posts.
> speculating about me as if I were absent, calling me names, and
> otherwise engaged in petty and vindictive behavior because they
> couldn't convince me to convert to their religious beliefs regarding
> Lisp.
I honestly couldn't care less if you like any language.
Posting incorrect information to a public forum is malicious, however.
>
> > > > He gives himself points (i.e. the thread is still alive) for answering
> > > > every post that looks like they might be taken as a slight, and even
> > > > some that can't (I love the way he played the answer "42"... :-)
>
> > > As is so commonly the case with speculations made in a vacuum, this is
> > > incorrect. Regarding specifically the post with the 42, there was also
> > > an alteration to the quoted material in that post that suggested that
> > > I was crazy, a "fuckhead", or similarly -- I don't recall exactly. It
> > > was that, not the number, to which I was responding. Though now that
> > > you mention it, the number was rather lacking in obvious relevance,
> > > and appeared to constitute a non sequitur.
>
> > To some extent, it is crazy to argue so vigorously about something of
> > which you know very little...
>
> I know enough about myself to know that having one of my posts
> misquoted as "> [brain fuck]" is an incorrect assessment of me.
>
Welp!
> > > > And he's not going to get tired, because he doesn't have to think of
> > > > clever twists to every answer;
>
> > > On the contrary, I put a great deal of thought into my
> > > counterarguments, when presented with things reasonably approximating
> > > rational arguments. It is only when presented with an obviously
> > > logically void "argument" such as "Series Expansion is an idiot" that
> > > I have responded with an uncreative copy-and-paste reply, and that
> > > because there is nothing really to say in response to such an
> > > "argument" except to point out that it fails to logically support the
> > > conclusion that you wish people to draw.
>
> > Your time would be better spent learning than counter-arguing.
>
> Ignoring for the time being the factually-incorrect implied insult
> contained in your remark,
Which insult? That you don't know about common lisp?
That isn't implied and it isn't an insult.
It is a very apparent state of affairs.
> if you honestly believe this, and you
> honestly have my best intentions at heart, then you should desist from
> harassing me online and thereby free up some time from "counter-
> arguing" to expend pursuing another activity, such as learning.
So by being polite in responding to you I am harassing you online?
An interesting definition of harassment indeed.
> Quite clearly, the more you publicly argue for my mistreatment by
> others, the more time I must spend in counter-arguing.
Huh? Someone is mistreating you?
> So while your words say one thing, your actions say quite the
> opposite.
>
I've only posted words...
> > > > Sprinkle that with a little on-topic but flawed logic and you have
> > > > yourself a very impressive volley.
>
> > > Nothing is flawed about my logic, unlike, for instance, that of those
> > > people who see an ad hominem argument as a valid one in support of
> > > Lisp over Java.
>
> > The problem is that this thread has not been about 'Arguments favoring
> > lisp over java'.
>
> Yes, it has, although it was originally about someone's job search.
>
Maybe for you.
> > It has been about correcting yours and Seamus MacRae's misconceptions
> > [rest of post deleted unread]
>
> I have no misconceptions.
>
You're not stubborn either.
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, anonymous.c.lisper.
Well shit, that was about as nice as I get!
On May 27, 12:24 am, ··················@gmail.com wrote:
> On May 26, 10:46 pm, Series Expansion <·······@gmail.com> wrote:
> > Please do not lie in wait refreshing your view of the newsgroup every
> > few minutes and then immediately follow up to my new posts to attack
> > them.
>
> I had no idea I was the one making hundreds of posts.
I never made any claim as to how many posts you'd made. I only noted
that you followed up to one of mine within a very few minutes of my
having posted it, which indicates that you are, at least, READING my
posts very obsessively, even if replying only to a very few of them.
> > > > > > > The only explanation I can conclude from this is that he is indeed
> > > > > > > doing this on purpose. There isn't another explanation. He must have a
>
> > > > > > He's pretty clearly insane.
>
> > > > > No, he's pretty clearly playing a game.
>
> > > > c) None of the above.
>
> > > logically, would you admit to it if you were?
>
> > Are you calling me a liar?
>
> No
Yes, you were. You clearly indicated distrust.
> > > The only one doing damage to your public image is you. Replying with
> > > the same copy-paste response does more to validate the flames than
> > > ignoring them would.
>
> > Based on your behavior, I conclude that your motives in offering the
> > above "advice" are suspect, and therefore that what you say cannot be
> > trusted.
>
> Which behavior?
Your hostility. You have posted numerous personal attacks against me
in a public forum. From this I infer a high probability that your
goals include to convince others to regard me or treat me in a hostile
manner. Such goals would indicate that you do not have my best
interests at heart. It is likely that any "advice" you gave me is in
furtherance of your own goals, and given that those goals apparently
include ones harmful to me, it is reasonable to suspect that following
your "advice" might therefore have adverse consequences to me, making
ignoring it the safer course of action.
> I've tried to either a.) be civil, or b.) stay out of it.
Then you've failed.
> > Regardless, there is nothing whatsoever wrong with my behavior. I have
> > nothing to be ashamed of, unlike the numerous persons rudely
>
> Well, aside from the hundreds of misinformed posts.
I have posted no misinformed posts.
> > speculating about me as if I were absent, calling me names, and
> > otherwise engaged in petty and vindictive behavior because they
> > couldn't convince me to convert to their religious beliefs regarding
> > Lisp.
>
> I honestly couldn't care less if you like any language.
> Posting incorrect information to a public forum is malicious, however.
Since I have not done that, this statement is apropos of nothing.
> > > > > He gives himself points (i.e. the thread is still alive) for answering
> > > > > every post that looks like they might be taken as a slight, and even
> > > > > some that can't (I love the way he played the answer "42"... :-)
>
> > > > As is so commonly the case with speculations made in a vacuum, this is
> > > > incorrect. Regarding specifically the post with the 42, there was also
> > > > an alteration to the quoted material in that post that suggested that
> > > > I was crazy, a "fuckhead", or similarly -- I don't recall exactly. It
> > > > was that, not the number, to which I was responding. Though now that
> > > > you mention it, the number was rather lacking in obvious relevance,
> > > > and appeared to constitute a non sequitur.
>
> > > To some extent, it is crazy to argue so vigorously about something of
> > > which you know very little...
>
> > I know enough about myself to know that having one of my posts
> > misquoted as "> [brain fuck]" is an incorrect assessment of me.
>
> Welp!
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, anonymous.c.lisper.
> > > > > And he's not going to get tired, because he doesn't have to think of
> > > > > clever twists to every answer;
>
> > > > On the contrary, I put a great deal of thought into my
> > > > counterarguments, when presented with things reasonably approximating
> > > > rational arguments. It is only when presented with an obviously
> > > > logically void "argument" such as "Series Expansion is an idiot" that
> > > > I have responded with an uncreative copy-and-paste reply, and that
> > > > because there is nothing really to say in response to such an
> > > > "argument" except to point out that it fails to logically support the
> > > > conclusion that you wish people to draw.
>
> > > Your time would be better spent learning than counter-arguing.
>
> > Ignoring for the time being the factually-incorrect implied insult
> > contained in your remark,
>
> Which insult?
Your implication of incompetence.
> > if you honestly believe this, and you
> > honestly have my best intentions at heart, then you should desist from
> > harassing me online and thereby free up some time from "counter-
> > arguing" to expend pursuing another activity, such as learning.
>
> So by being polite in responding to you I am harassing you online?
No, by being impolite in responding to me, and particularly by
continuing to publicly promulgate undesirable notions about me, you
are harassing me and wasting my time.
> > Quite clearly, the more you publicly argue for my mistreatment by
> > others, the more time I must spend in counter-arguing.
>
> Huh? Someone is mistreating you?
You, for one, by arguing implicitly that others should do so, by
calling me names and making other negative assertions about me in a
public place.
> > So while your words say one thing, your actions say quite the
> > opposite.
>
> I've only posted words...
Posting words is an action.
> > > > > Sprinkle that with a little on-topic but flawed logic and you have
> > > > > yourself a very impressive volley.
>
> > > > Nothing is flawed about my logic, unlike, for instance, that of those
> > > > people who see an ad hominem argument as a valid one in support of
> > > > Lisp over Java.
>
> > > The problem is that this thread has not been about 'Arguments favoring
> > > lisp over java'.
>
> > Yes, it has, although it was originally about someone's job search.
>
> Maybe for you.
My job is secure, thanks.
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, anonymous.c.lisper.
>
> Well shit, that was about as nice as I get!
Then you should seek remedial lessons in politeness, particularly
regarding decorum in public.
Series Expansion <·······@gmail.com> writes:
> On May 26, 10:22��pm, ··················@gmail.com wrote:
> >
> > The problem is that this thread has not been about 'Arguments favoring
> > lisp over java'.
>
> Yes, it has, although it was originally about someone's job search.
>
> > It has been about correcting yours and Seamus MacRae's misconceptions
> > [rest of post deleted unread]
>
> I have no misconceptions.
Well, I'm not sure this is the best response. You have at several
points in this thread stated things about how lisp works or how it must
work that are objectively and patently false. Reference to the Common
Lisp specification often backs up that observation.
Now if you truly have no misconceptions and yet continue to make
statements that are untrue, what is the only logical conclusion that
observers can make? It seems that the force of logic would then require
that we conclude that you are knowingly making false statements rather
than making them out of ignorance of the truth.
So is that the conclusion you wish us to derive?
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, anonymous.c.lisper.
Commenting on incorrect technical arguments is not a personal attack.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 27, 5:40 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 26, 10:22 pm, ··················@gmail.com wrote:
> > > It has been about correcting yours and Seamus MacRae's misconceptions
> > > [rest of post deleted unread]
>
> > I have no misconceptions.
>
> Well, I'm not sure this is the best response.
Indeed, your sneaky attempt to badmouth me behind my back by not
posting this to cljp was not a very good idea at all.
> [calls me a liar]
No, you're the liar.
> So is that the conclusion you wish us to derive?
No. The conclusion I wish you to derive is that I am an okay guy and
should be left in peace and NOT badmouthed in public.
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, anonymous.c.lisper.
>
> [calls me a liar]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
Series Expansion wrote:
> On May 27, 5:40 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> So is that the conclusion you wish us to derive?
>
> No. The conclusion I wish you to derive is that I am an okay guy
If that is your wish, then you should change strategy - the
current one is not working !
Arne
On Jul 11, 2:18 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 27, 5:40 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> >> So is that the conclusion you wish us to derive?
>
> > No. The conclusion I wish you to derive is that I am an okay guy
>
> If that is your wish, then you should change strategy - the
> current one is not working !
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
On May 27, 7:11 pm, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> ·····@franz.com writes:
> >> gugamilare <··········@gmail.com> writes:
> >> > The only explanation I can conclude from this is that he is indeed
> >> > doing this on purpose. There isn't another explanation. He must have a
>
> >> He's pretty clearly insane.
>
> > No, he's pretty clearly playing a game. The object of the game is to
> > keep the thread going as long as possible. He gives himself points
>
> Sure, but i think it takes a certain kind of insanity to play these
> games, and to keep it up for weeks at a time.
Beware, such insanity is contagious.
Duane
On 2009-05-28 05:12:26 -0400, ·····@franz.com said:
>> Sure, but i think it takes a certain kind of insanity to play these
>> games, and to keep it up for weeks at a time.
>
> Beware, such insanity is contagious.
Duane speaks from experience here; an experience I share. At some point
you have to let the other guy have the last word, even when that last
word is misinformation, otherwise your Usenet battle will eat your
life. I'm not complaining about the length of the thread (in fact, from
a purely selfish standpoint I find it entertaining, and sometimes
informative); I'm just concerned for the time and mental health of the
lisp posters.
I appreciate that the lisp people here have been acting in good faith,
trying to set the record straight, and they are to be commended for
that. But at this point, anyone lurking who can't see the pattern
(misinformation/falshood/unwarranted assumptions and their consequent
correction by the lisp posters) will never see it, no matter how many
corrections are posted. The result is that the lisp posters, though
well intentioned, are throwing good time after bad. Best to let those
who willfully post misinformation have the last word and use your time
for something productive or just to relax and spend time with your
loved ones.
just my $.02
--
Raffael Cavallaro, Ph.D.
On May 28, 3:33 pm, Raffael Cavallaro
<················@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-05-28 05:12:26 -0400, ·····@franz.com said:
>
> >> Sure, but i think it takes a certain kind of insanity to play these
> >> games, and to keep it up for weeks at a time.
> > Beware, such insanity is contagious.
>
> Duane speaks from experience here; an experience I share. At some point
> you have to let the other guy have the last word, even when that last
> word is misinformation [further paragraphs of calling me a liar deleted]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Raffael, Duane, and Paul.
On 2009-07-12 08:36:40 +0100, Series Expansion <·······@gmail.com> said:
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, Raffael, Duane, and Paul.
I think this person (and perhaps the other noisy person in this thread)
might be some kind of variant on parry/aliza. If you look at the
responses they certainly have that
superficially-there-is-someone-there-but-actually-it's-just-a-machine
thing about them. the above quoted text (with the names varying) has
been posted about 10x in a row, which I also remember as a
characteristic of these things.
I think we may have been taken for a ride here.
Tim Bradshaw <···@cley.com> writes:
> On 2009-07-12 08:36:40 +0100, Series Expansion <·······@gmail.com> said:
>
>> These tiresome personal attacks do not constitute rational arguments
>> in favor of either Lisp or Java, Raffael, Duane, and Paul.
>
> I think this person (and perhaps the other noisy person in this
> thread) might be some kind of variant on parry/aliza. If you look at
> the responses they certainly have that
> superficially-there-is-someone-there-but-actually-it's-just-a-machine
> thing about them. the above quoted text (with the names varying) has
> been posted about 10x in a row, which I also remember as a
> characteristic of these things.
>
> I think we may have been taken for a ride here.
That poster's nature has been clear for quite a while, yet you choose to
respond anyway. Why does it make a difference if it's a machine wasting
your time rather than a human?
On 2009-07-12 20:18:33 +0100, Paul Donnelly <·············@sbcglobal.net> said:
> That poster's nature has been clear for quite a while, yet you choose to
> respond anyway. Why does it make a difference if it's a machine wasting
> your time rather than a human?
It makes no difference. I have time to waste in either case.
Paul Donnelly wrote:
> Tim Bradshaw <···@cley.com> writes:
>
>> On 2009-07-12 08:36:40 +0100, Series Expansion <·······@gmail.com> said:
>>
>>> These tiresome personal attacks do not constitute rational arguments
>>> in favor of either Lisp or Java, Raffael, Duane, and Paul.
>> I think this person (and perhaps the other noisy person in this
>> thread)
Nope.
lors wrote:
> Paul Donnelly <·············@sbcglobal.net> wrote:
>
>> Tim Bradshaw <···@cley.com> writes:
>>
>>> On 2009-07-12 08:36:40 +0100, Series Expansion <·······@gmail.com> said:
>>>
>>>> These tiresome personal attacks do not constitute rational arguments
>>>> in favor of either Lisp or Java, Raffael, Duane, and Paul.
>>> I think this person (and perhaps the other noisy person in this
>>> thread)
Nope.
>>> might be some kind of variant on parry/aliza. If you look at
>>> the responses they certainly have that
>>> superficially-there-is-someone-there-but-actually-it's-just-a-machine
>>> thing about them. the above quoted text (with the names varying) has
>>> been posted about 10x in a row, which I also remember as a
>>> characteristic of these things.
>>>
>>> I think we may have been taken for a ride here.
> I am fskn sure of it.
> The asshole has trashed a whole froup where
> we all go to look for free NNTP services.
If you are referring to the newsgroup I think you are, Series Expansion
is definitely not posting there at all. There is an ongoing invasion of
that newsgroup by alt.usenet.kooks, which is trashing the group, but
neither Series Expansion nor I have anything to do with that. The
culprits in that case are Bob Larter and Sarah Ehret, along with Sn!pe,
phlatArse, Hu Flung Dung, China Blue, and a number of similarly
"creative" (by a 10-year-old's standards) pseudonyms, all of whom are
probably used collectively by a grand total of about three people with
way too much free time and way too little sense.
On Jul 12, 3:18 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> Tim Bradshaw <····@cley.com> writes:
> > I think this person (and perhaps the other noisy person in this
> > thread) might be some kind of variant on parry/aliza.
No.
> > If you look at the responses they certainly have that
> > superficially-there-is-someone-there-but-actually-it's-just-a-machine
> > thing about them.
>
> > I think we may have been taken for a ride here.
>
> That poster's nature has been clear for quite a while, yet you choose to
> respond anyway. Why does it make a difference if it's a machine wasting
> your time rather than a human?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul and Tim.
Tim Bradshaw wrote:
> On 2009-07-12 08:36:40 +0100, Series Expansion <·······@gmail.com> said:
>
>> These tiresome personal attacks do not constitute rational arguments
>> in favor of either Lisp or Java, Raffael, Duane, and Paul.
>
> I think this person (and perhaps the other noisy person in this thread)
Nope.
On Sun, 12 Jul 2009 12:08:01 +0100, Tim Bradshaw <···@cley.com> said:
> I think this person (and perhaps the other noisy person in this
> thread) might be some kind of variant on parry/aliza. If you look at
> the responses they certainly have that
> superficially-there-is-someone-there-but-actually-it's-just-a-machine
> thing about them. the above quoted text (with the names varying) has
> been posted about 10x in a row, which I also remember as a
> characteristic of these things.
> I think we may have been taken for a ride here.
These tireless rational arguments do not constitute effective
group defense against either Parry or Eliza, Tim.
---Vassil.
P.S. I have received the following reply to the above:
These tiresome personal attacks do not constitute rational arguments
in favor of or against either artificial or natural intelligence,
Vassil.
---Prof. Higgins.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
On Jul 12, 7:08 am, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-12 08:36:40 +0100, Series Expansion <·······@gmail.com> said:
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, Raffael, Duane, and Paul.
>
> I think this person (and perhaps the other noisy person in this thread)
> might be some kind of variant on parry/aliza.
Then you think wrong.
> If you look at the responses they certainly have that
> superficially-there-is-someone-there-but-actually-it's-just-a-machine
> thing about them.
>
> I think we may have been taken for a ride here.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim.
On May 28, 5:12 am, ·····@franz.com wrote:
> On May 27, 7:11 pm, Paul Foley <····@below.invalid> (http://
> public.xdi.org/=pf) wrote:
> > ·····@franz.com writes:
> > >> gugamilare <··········@gmail.com> writes:
> > >> > The only explanation I can conclude from this is that he is indeed
> > >> > doing this on purpose. There isn't another explanation. He must have a
>
> > >> He's pretty clearly insane.
>
> > > No, he's pretty clearly playing a game. The object of the game is to
> > > keep the thread going as long as possible. He gives himself points
>
> > Sure, but i think it takes a certain kind of insanity to play these
> > games, and to keep it up for weeks at a time.
>
> Beware, such insanity is contagious.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Duane, Paul, and gugamilare.
Series Expansion <·······@gmail.com> writes:
> On May 22, 10:33 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
>> Series Expansion wrote:
>> > On May 18, 9:38 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
>> >> Series Expansion wrote:
>> >>> On May 17, 3:09 am, gugamilare <··········@gmail.com> wrote:
>> >>>> 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.
>> >> Emacs has been running on X for 20 years (give or take a few).
>>
>> > I'm sure it's been running on X for as long as there've been xterms to
>> > run it in.
>>
>> Running in an xterm is not considered running on X.
>
> That was precisely my point. Running in an xterm does not really
> qualify you to claim to be graphical, contrary to what several other
> people have implied.
>
>> >>> An ASCII editor lacks Unicode support by definition.
>> >>Wrong on two counts:
>> >>* Emacs is not (entirely) an a text mode editor
>> >>* A text mode editor can support Unicode fine vi UTF-8
>>
>> > Fascinating. Arne appears to believe that Unicode is a subset of
>> > ASCII.
>>
>> Fascinating that someone is so dumb [rest deleted]
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either emacs or Eclipse, Arne.
>
> Hand-editing UTF-8 (where it includes some double-wide characters) in
> an ASCII editor is not a recommended way to edit text.
>
> Graphics hardware, and software that acknowledges its existence, is
> needed in order to display the full Unicode character set at one time.
Series, you have said on numerous occasions that your here to debate
matters and are not interested in personal attacks. Thats all good and I
hope you can accept the following as an attempt to correct your
misunderstanding of emacs and not as a personal attack.
I suspect some of the confusion is due to the terminology used by emacs,
which unfortunately is different to what has become the 'norm'. However,
this is understandable when you consider that emacs was often the first
to have certain features. As an example, emacs uses the terms window and
frame in ways that are different to what most people think of when they
see those terms. However, they seemed very naturaul when they first
adopted them. Some have argued that emacs should revise its terminology
to be more in line with common usage. Regardless of where someone stands
on that argument, it doesn't change what functionality the software has.
Emacs uses the term 'window' in a similar way to what other systems may
refer to as a 'pane' and uses the term 'frame' for what other systems
would call a window.
Emacs has had native support for X windows for over 20 years. By native
support, I do not mean running in an X term. I mean full native X
support with the ability to open new frames (aka windows), move frames
to different virtual desktops, stack frames on top of each other, tile
frames, iconify frames etc. Unlike other editors, I also get the added
benefit of being able to run under non-graphics environments, such as
the linux console. In fact, I can open multiple console frames on the
multiple console terminals you have under Linux - this means even if I
don't have X installed I can run emacs with multiple frames and have
each of those frames split into multiple windows. If I used the advanced
features of the Linux console, I can even have more sophisticated
fonts than the default 'fixed' version.
You are correct when you state that emacs is not a fully graphical
application. However, you are incorrect when you state that it is just
an ascii editor. Emacs has had support for a much wider range of
character sets for quite a long time. The version I'm using right now
has full UTF-8 support as well as support for a number of
asian and western european character ses. It also support true type and
anti-aliased fonts, GTK widgets for pop-ups and GTK menus, full mouse
support, tooltips (with different fonts, colors and borders to the
buffer text), toolbars with icons etc. I can use proportionally spaced,
condensed or fixed width fonts. I have italic, bold, underlined,
supersubscripts etc. I can have fonts of varying sizes, font families
etc.
Emacs also has built-in support for numerous graphics types, including
GIF, TIFF, SVGA, JPG etc and built-in support for playing sounds. You
can even display PDF, PostScript and DVI documents inside an emacs
buffer as they would look in a dedicated viewer (not as translated into
text, but graphically) and you can search those documents.
Out of the box, Emacs is not what would be considered a modern fully
integrated development environment in the same way Eclipse or a purpose
built system, such as SQL Developer or NetBeans is. However, the
components are there, they just need someone to put them together. This
can result in a far more productive environment, because it is built to
fit the individuals needs and their preferred way of working. However,
not everyone wants to go through that process and thats fine - different
strokes for different folks.
In some cases, such as with Slime, the IDE that has been put together
using basic Emacs facilities and some elisp code to glue it all together
is far superior to the support provided by the well known IDEs such as
Eclipse (which has very poor support for CL BTW).
When new languages come along, Emacs is often the first to provide any
form of IDE. For example, When I programmed in Java (from about 1995 -
1999), there simply wasn't any decent Java IDEs available. Those that
did exist tended to be extremely slow and somewhat unreliable. However,
a couple of smart people put together JDEE (The Java Development
Environment for Emacs). At the time, it was just miles in front of
anything else on offer. Compared to dedicated Java IDE's or IDEs that
have a strong Java orientation, it can look quite outdated now. However,
often the early emacs implementations are the prototypes of what will
follow and many of the good ideas found in dedicated IDEs can be traced
bak to emacs. In a similar way, if CL became more widely adopted, you
would probably eventually see CL IDEs that would make Slime look pretty
tired, but the new dedicated CL IDE would likely borrow many of the
ideas currently in Slime and it would have to do a hell of a lot to make
it much better than it already is.
You made a number of references to your use of emacs in the 90s, over a
remote connection and running it under an xterm. Rather than seeing this
as the limitation of emacs, you should actually view it as one of its
strengths as you were able to run it at all. If it had been eclipse, you
couldn't run it at all.
Running it under an xterm severely limits what Emacs can
do. Its not a limitation of emacs, but rather a limitation of how it is
being run. You should not use your experiences in running Emacs in this
limited mode as the basis for determining what it can and cannot do.In
fact, I'm somewhat confused as to why, if you were running it in an
xterm, you couldn't run it in native X mode. I'll assume it was due to
bandwidth limitations rather than due to a poorly configured
environment.
During the 90s, I administered a number of remote sites. I ran Emacs
remotely, but instead of running it in an xterm, I ran it as a native X
application. To improve performance (we are talking about 56K dial-up at
this time), I used a differential X compression utility. The performance
wasn't fantastic, but it meant I had full windowing support, mouse
support, menus, popups, tooltips etc etc.
There has been at least 1, if not two major releases of Emacs since you
used it in the 90s, emacs 21 and emacs 22. A third one, Emacs 23 is
currently under active development and probably not that far from being
released as its very stable. Each of these releases has brought
improvements and updates. From your apparent experiences with emacs, I'm
guessing the version you used was Emacs 19. There is a world of
difference between that emacs and the one you will find being used by
most people today. It is similar to the world of difference between the
first versions of Java (the ones I coded in) and the version available
today. Consider what would be your response if I stated that Java was a
poor language due to the way dates, time and locales are handled and
made reference to the classes that were part of version 1.02 and all the
problems they had.
The bottom line - your understanding of emacs is outdated and
incorrect. Your experience of emacs has been further skewed due to the
restrictive mode in which it was run. Many of the limitations or missing
features you experienced were due to the environment you were running
the application in and not limitations of the application itself.
Tim
--
tcross (at) rapttech dot com dot au
On May 24, 12:21 am, Tim X <····@nospam.dev.null> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 22, 10:33 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Fascinating that someone is so dumb [rest deleted]
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either emacs or Eclipse, Arne.
>
> > Hand-editing UTF-8 (where it includes some double-wide characters) in
> > an ASCII editor is not a recommended way to edit text.
>
> > Graphics hardware, and software that acknowledges its existence, is
> > needed in order to display the full Unicode character set at one time.
>
> Series, you have said on numerous occasions that your here to debate
> matters and are not interested in personal attacks. Thats all good and I
> hope you can accept the following as an attempt to correct your
> misunderstanding [rest of personal attack, and rest of post, deleted
> unread]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim and Arne.
Series Expansion <·······@gmail.com> writes:
> On May 24, 12:21 am, Tim X <····@nospam.dev.null> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > On May 22, 10:33 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
>> >> Fascinating that someone is so dumb [rest deleted]
>>
>> > These tiresome personal attacks do not constitute rational arguments
>> > in favor of either emacs or Eclipse, Arne.
>>
>> > Hand-editing UTF-8 (where it includes some double-wide characters) in
>> > an ASCII editor is not a recommended way to edit text.
>>
>> > Graphics hardware, and software that acknowledges its existence, is
>> > needed in order to display the full Unicode character set at one time.
>>
>> Series, you have said on numerous occasions that your here to debate
>> matters and are not interested in personal attacks. Thats all good and I
>> hope you can accept the following as an attempt to correct your
>> misunderstanding [rest of personal attack, and rest of post, deleted
>> unread]
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, Tim and Arne.
Yeh, you keep saying that whenever someone points out your errors.
Can't help but notice you cut my text just before the bit where I said
this was *not* a personal attack but rather an attempt to correct your
misunderstanding regarding emacs. I guess leaving it in would have made
your claim of a personal attack even weaker.
Pointing out that you are in error regarding your statements about
something like Emacs is NOT a personal attack. Furthermore, anyone who
wants to verify what I wrote (and others) can easily do so by going to
the Emacs website or by checking out the Emacs wiki or any of a number
of blogs that deal with Emacs. In fact, I wold recommend anyone who is
at all in doubt regarding the facts do so and after having done so,
consider which of the posters to the thread has credibility and which
does not.
It is of little importance to anyone if you wish to continue believing
in Santa, fairies at the bottom of the garden and that emacs is only
capable of ascii editing and has no support for graphics or modern
windowing environments. It may even be true that there is bliss in
ignorance, in which case, you must be a very happy and blissful person.
Tim
--
tcross (at) rapttech dot com dot au
On May 24, 4:19 am, Tim X <····@nospam.dev.null> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 24, 12:21 am, Tim X <····@nospam.dev.null> wrote:
> >> Series, you have said on numerous occasions that your here to debate
> >> matters and are not interested in personal attacks. Thats all good and I
> >> hope you can accept the following as an attempt to correct your
> >> misunderstanding [rest of personal attack, and rest of post, deleted
> >> unread]
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, Tim and Arne.
>
> Yeh, you keep saying that whenever someone points out your errors.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, Tim.
> Can't help but notice you cut my text just before the bit where I said
> this was *not* a personal attack
That was a lie. I have little interest in reading lies. If I ever do
develop an inexplicable urge to read lies, I will visit whitehouse.gov
or a similar politician-run site.
> [remaining personal attacks and other nonsense deleted unread]
Series Expansion <·······@gmail.com> writes:
> On May 24, 4:19 am, Tim X <····@nospam.dev.null> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > On May 24, 12:21 am, Tim X <····@nospam.dev.null> wrote:
>> >> Series, you have said on numerous occasions that your here to debate
>> >> matters and are not interested in personal attacks. Thats all good and I
>> >> hope you can accept the following as an attempt to correct your
>> >> misunderstanding [rest of personal attack, and rest of post, deleted
>> >> unread]
>>
>> > These tiresome personal attacks do not constitute rational arguments
>> > in favor of either Lisp or Java, Tim and Arne.
>>
>> Yeh, you keep saying that whenever someone points out your errors.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either emacs or Eclipse, Tim.
>
>> Can't help but notice you cut my text just before the bit where I said
>> this was *not* a personal attack
>
> That was a lie. I have little interest in reading lies. If I ever do
> develop an inexplicable urge to read lies, I will visit whitehouse.gov
> or a similar politician-run site.
>
OK, I see, its ok for you to personally attack me by claiming I lied,
but to criticise you for being completely wrong in your statements about
emacs is a personal attack. Nice double standard you have there.
have a good life and enjoy your blissful ignorance and I hope it
continues to keep you in your warm comfortable existance of deluded
superiority .
--
tcross (at) rapttech dot com dot au
On May 25, 4:22 am, Tim X <····@nospam.dev.null> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 24, 4:19 am, Tim X <····@nospam.dev.null> wrote:
> >> Can't help but notice you cut my text just before the bit where I said
> >> this was *not* a personal attack
>
> > That was a lie. I have little interest in reading lies. If I ever do
> > develop an inexplicable urge to read lies, I will visit whitehouse.gov
> > or a similar politician-run site.
>
> OK, I see, its ok for you to personally attack me by claiming I lied
Well, it's kind of hard not to when you say something won't be a
personal atatck, and then spend four very long paragraphs telling the
whole world how stupid you think I am.
> [many more personal attacks; rest of post deleted]
Series Expansion <·······@gmail.com> writes:
> On May 25, 4:22 am, Tim X <····@nospam.dev.null> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > On May 24, 4:19 am, Tim X <····@nospam.dev.null> wrote:
>> >> Can't help but notice you cut my text just before the bit where I said
>> >> this was *not* a personal attack
>>
>> > That was a lie. I have little interest in reading lies. If I ever do
>> > develop an inexplicable urge to read lies, I will visit whitehouse.gov
>> > or a similar politician-run site.
>>
>> OK, I see, its ok for you to personally attack me by claiming I lied
>
> Well, it's kind of hard not to when you say something won't be a
> personal atatck, and then spend four very long paragraphs telling the
> whole world how stupid you think I am.
>
Well, it seems you want it both ways. In your first reply, you stated
you didn't read what followed, now your claiming it was 4 paragraphs
of me telling the world how stupid you are. Either you read it or you
did not.
Check it out again. I did NOT state you were stupid even once. In fact,
after the initial paragraph where I stated I was not making a personal
attack, I made only passing references to being mistaken. In fact, I
whent to considerable length not to try and make it appear personal
while at the same time trying to point out why your statements were in
error. The bulk of the e-mail was factural statements regarding the
current state of emacs.
It would seem that your so concerned about people thinking your stupid
that your makeing very basic errors in comprehension. I do not know you
and don't know whether your stupid or not, but the evidence does
indicate your overly defensive - to the point of interpreting any
attempt to correct any misinformation you have as a personal attack.
How would someone have to phrase a correction for you so that it is not
seen as a personal attack or do you never get anything wrong?
Tim
PS. I'm now very glad I didn't also correct your misinformation
concerning blind programmers and graphical UIs.
PPS. FYI I've been a blind programmer for over 10 years and do happen to
know a bit about it
--
tcross (at) rapttech dot com dot au
On May 26, 3:58 am, Tim X <····@nospam.dev.null> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 25, 4:22 am, Tim X <····@nospam.dev.null> wrote:
> >> Series Expansion <·······@gmail.com> writes:
> >> > On May 24, 4:19 am, Tim X <····@nospam.dev.null> wrote:
> >> >> Can't help but notice you cut my text just before the bit where I said
> >> >> this was *not* a personal attack
>
> >> > That was a lie. I have little interest in reading lies. If I ever do
> >> > develop an inexplicable urge to read lies, I will visit whitehouse.gov
> >> > or a similar politician-run site.
>
> >> OK, I see, its ok for you to personally attack me by claiming I lied
>
> > Well, it's kind of hard not to when you say something won't be a
> > personal atatck, and then spend four very long paragraphs telling the
> > whole world how stupid you think I am.
>
> Well, it seems you want it both ways. In your first reply, you stated
> you didn't read what followed, now your claiming it was 4 paragraphs
> of me telling the world how stupid you are. Either you read it or you
> did not.
I did not. I extrapolated its likely content after reading the first
sentence or two.
> Check it out again. I did NOT state you were stupid even once.
No, I expect you merely implied it repeatedly, probably mixed in with
liberal quantities of other forms of irrational behavior.
> In fact, I whent to considerable length not to try and make it appear
> personal while at the same time trying to point out why your statements
> were in error.
In other words, you went to considerable evidence to disguise the fact
that you were severely badmouthing me in public, while severely
badmouthing me in public. Hardly an admirable achievement worthy of
tooting one's own horn in this manner.
> The bulk of the e-mail was factural statements regarding the current
> state of emacs.
I believe you have misspelled "usenet article" and "counterfactual".
> It would seem that your so concerned about people thinking your stupid
> that your makeing very basic errors in comprehension.
These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, Tim.
> I do not know you and don't know whether your stupid or not, but the
> evidence does indicate your overly defensive - to the point of
> interpreting any attempt to correct any misinformation you have as a
> personal attack.
I do not spread misinformation.
Furthermore, I do not agree with your assertions about "overly
defensive". Even if I did, a public forum is not the appropriate place
to be discussing such matters. In a public forum, I must always
present as perfect as possible an appearance, and therefore am
compelled to deny all claims of flaws, regardless of whether or not I
privately think there could be any truth to them. In other words, I
must maintain what is sometimes called "face", and "keep up
appearances". If you have something you wish to discuss with me that
is not appropriate for a public venue such as this, the gmail address
in my news headers is valid. Use it.
> How would someone have to phrase a correction for you so that it is not
> seen as a personal attack
They could do it privately.
> PS. I'm now very glad I didn't also correct your misinformation
I repeat: I do not spread misinformation.
Do not post such a vile accusation again, or I may have to consider
taking legal action. Accusing someone of intentionally corrupt
conduct, where such is not the case, is a violation of defamation laws
in most jurisdictions.
> PPS. FYI I've been a blind programmer for over 10 years
This confirms why your perceptions of the strengths and shortcomings
of various user-interfaces are abnormal. Rest assured that most people
do, and will continue to, find graphical interfaces easier and more
productive to use.
Series Expansion <·······@gmail.com> writes:
> On May 26, 3:58 am, Tim X <····@nospam.dev.null> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > On May 25, 4:22 am, Tim X <····@nospam.dev.null> wrote:
>> >> Series Expansion <·······@gmail.com> writes:
>> >> > On May 24, 4:19 am, Tim X <····@nospam.dev.null> wrote:
>> >> >> Can't help but notice you cut my text just before the bit where I said
>> >> >> this was *not* a personal attack
>>
>> >> > That was a lie. I have little interest in reading lies. If I ever do
>> >> > develop an inexplicable urge to read lies, I will visit whitehouse.gov
>> >> > or a similar politician-run site.
>>
>> >> OK, I see, its ok for you to personally attack me by claiming I lied
>>
>> > Well, it's kind of hard not to when you say something won't be a
>> > personal atatck, and then spend four very long paragraphs telling the
>> > whole world how stupid you think I am.
>>
>> Well, it seems you want it both ways. In your first reply, you stated
>> you didn't read what followed, now your claiming it was 4 paragraphs
>> of me telling the world how stupid you are. Either you read it or you
>> did not.
>
> I did not. I extrapolated its likely content after reading the first
> sentence or two.
So, you attack me by calling me a liar and you didn't even read what I
wrote.
>
>> Check it out again. I did NOT state you were stupid even once.
>
> No, I expect you merely implied it repeatedly, probably mixed in with
> liberal quantities of other forms of irrational behavior.
So, now you are attacking me by saying I'm irrational based on your
'extrapolation' of what I wrote which you did not read. You must have
one hell of an ego to think anyone could be bothered writing anything
about you one way or the other. My post was not about you, it was about
correcting incorrect statements made concerning emacs. You as a person
are totally irrelevant.
>
>> In fact, I whent to considerable length not to try and make it appear
>> personal while at the same time trying to point out why your statements
>> were in error.
>
> In other words, you went to considerable evidence to disguise the fact
> that you were severely badmouthing me in public, while severely
> badmouthing me in public. Hardly an admirable achievement worthy of
> tooting one's own horn in this manner.
You have admitted that you only read the first couple of
sentences. Where in those sentences did I 'bad mouth you'? In reality,
what your saying is that you believe, without any evidence whatever,
that I attacked and bad mouthed you. There is a term for what you have -
paranoia
You didn't read the rest, so you wouldn't know if I bad mouthed you or
not. Just for the record, I did not. Your attack on me is completely
unjustified. All I did was attempt to point out where you were in
error. In fact, the paragraphs that followed did not reference you at
all. It referenced mistakes and it pointed out how emacs could do what
you claimed it could not.
>
>> The bulk of the e-mail was factural statements regarding the current
>> state of emacs.
>
> I believe you have misspelled "usenet article" and "counterfactual".
>
I believe you realise you got things totally wrong and now your trying
to get back face my picking up one error (writing e-mail when I should
have said 'post' or 'article') and a rather poor attempt at wit with
your reference to counterfactual. The ironic part of this is that your
statements about emacs were the ones that were counterfactual. something
that can be easily established by simply reading the NEWS file for Emacs
23.
>> It would seem that your so concerned about people thinking your stupid
>> that your makeing very basic errors in comprehension.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either emacs or Eclipse, Tim.
Talk about pot calling the kettle black
For the record, I don't have any opinion regarding eclipse. I happen to
like emacs, but I don't care if nobody else likes it. As I stated in my
original e-mail, different strokes for different folks. All I was doing
was correcting your errors.
>> I do not know you and don't know whether your stupid or not, but the
>> evidence does indicate your overly defensive - to the point of
>> interpreting any attempt to correct any misinformation you have as a
>> personal attack.
>
> I do not spread misinformation.
>
You have made statements in previous messages that I have lied and I
have bad mouthed you, neither of which are true. Of course I know you
will say otherwise. My challenge to you would be to show actual
instances where I have lied or bad mouthed you.
I used the term misinformation because I thought maybe you would read it
and not consider it a personal attack. The bottom line is that
statements you made about emacs are incorrect. Call it being wrong,
being in error or misinformation, whatever you like.
> Furthermore, I do not agree with your assertions about "overly
> defensive". Even if I did, a public forum is not the appropriate place
> to be discussing such matters. In a public forum, I must always
> present as perfect as possible an appearance, and therefore am
> compelled to deny all claims of flaws, regardless of whether or not I
> privately think there could be any truth to them. In other words, I
> must maintain what is sometimes called "face", and "keep up
> appearances". If you have something you wish to discuss with me that
> is not appropriate for a public venue such as this, the gmail address
> in my news headers is valid. Use it.
>
If that is your aim, I regret to inform you that this has not been the
outcome. You attacked me for doing nothing more than attempt to correct
your mistaken beliefs regarding what emacs could and could not do. My
only criticism of you at that time was to say you were mistaken and in
error. In return, you called me a liar and then later said I bad mouthed
you, which I have not. Again, I challenge you to show me one example of
where I have bad mouthed you. Failing that, I expect a full and sincere
apology.
>> How would someone have to phrase a correction for you so that it is not
>> seen as a personal attack
>
> They could do it privately.
>
If you make a statement of error in a public forum, why is it not also
acceptable for others in that public forum to correct you. If I only
correct you privately, how does that help others who could be led astray
by your error?
I also find this a rather large contradiction. You have stated on more
than one occasion that you cannot let things people have written about
you go without being addressed because they are wrong and could have a
negative impact - what you referred to as keeping face. At the same
time, you don't want anyone to correct your public mistakes in public,
only privately. This seems like a bit of a double standard.
>> PS. I'm now very glad I didn't also correct your misinformation
>
> I repeat: I do not spread misinformation.
>
> Do not post such a vile accusation again, or I may have to consider
> taking legal action. Accusing someone of intentionally corrupt
> conduct, where such is not the case, is a violation of defamation laws
> in most jurisdictions.
>
Are you kidding? Your posts have been chock a block full of errors of
fact, which I would call misinformation. You continue to speak with
authority on matters for which you have at best only a passing
familliarity and refuse to accept correction from others even when the
correction is backed up with verifiable facts.
You have spread misinformation.
Now you threaten me with legal action. Well, come on, bring it on big
mouth. Either put up or shut up! lets go into court. You can enter my
posts in this thread as evidence to support your case and I will enter
yours. The law is an ass, but I'm sure it will spot an even bigger one
once they see the thread of your posts.
I hereby state to all readers of this group to be wary of Series
Expansion. He has a overriding desire to maintain what he believes is
'face' at any cost and will not accept correction on any point in public. He has
failed to recognise that one of the most convincing traits of someone
with good character is the ability to admit when your wrong or have made
a mistake. He will not hesitate to accuse others of being liars and bad
mouthing him with absolutely no evidence. He maintains a double standard
which, in his mind, justifies his personal attacks on others as
reasonable while refusing any criticism of himself as a personal attack
even when that criticism was restricted to the errors in what he has
posted and made no reference to him at a personal level.
In short, his behavior is less than rational, overly defensive and not
what wold be considered normal for a well balanced and mature
individual. He cannot be reasoned with.He is to be avoided.
>> PPS. FYI I've been a blind programmer for over 10 years
>
> This confirms why your perceptions of the strengths and shortcomings
> of various user-interfaces are abnormal. Rest assured that most people
> do, and will continue to, find graphical interfaces easier and more
> productive to use.
Not once did I state a single comment regarding GUIs. I've not made any
judgement call either way, I've not stated emacs is better or worse than
any other editor. All I did was point out the errors you made concerning
what emacs could and could not do. I have made not one reference to the
strengths or weaknesses of GUIs.
Again, find one single reference where I stated GUIs were less
productive or not as good or anything negative. You won't find I made a
single comment. This means your above paragraph is either a deliberate
lie or an honest mistake. either way, it is incorrect information, or as
some would call it misinformation
Just for the record, I've been a blind programmer for 10 years, but I've
been programming for a lot lot longer than that and have used many
graphical GUIs. I've not actually noticed any productivity differences
between a good nonGUI and a good GUI environment. As a touch typist, I
do prefer to use the keyboard over the mouse, but these days, mouse
support is not limited to GUIs anyway.
Are you by any chance suffering from schizophrenia? I use to be a
social worker and a lot of your behavior and delusions are very similar
to how many of my clients would behave. Your obsession over your
reputation is odd to say the least - I mean, what sort of reputation
does 'Series Expansion' have anyway and even if 'Series Expansion' got a
bad reputation, you could just change your childish handle to something
else, like parallel contraction and apart from people wondering if your
going to give birth to twins, nobody would even know it was you. I mean,
its not like you would have to change your identity through legal means
or join the witness protection program or anything - its just a silly
little nickname anyway.
I see no point in continuing this further. My efforts and what I think
of you are now on record. Post as many followups as you like, but don't
expect them to change the facts.
I do hope you find some peace in life because I don't think you will
find it on usernet.
tim
--
tcross (at) rapttech dot com dot au
On May 27, 5:42 am, Tim X <····@nospam.dev.null> wrote:
> Series Expansion <·······@gmail.com> writes:
> > I did not. I extrapolated its likely content after reading the first
> > sentence or two.
>
> So, you attack me by calling me a liar and you didn't even read what I
> wrote.
I read up to the part where it became apparent that the sole purpose
of your post was to publicly lie about me. At that point, it became
apparent that the remainder of it was likely utterly without merit,
and therefore would have been a waste of my time to read.
> >> Check it out again. I did NOT state you were stupid even once.
>
> > No, I expect you merely implied it repeatedly, probably mixed in with
> > liberal quantities of other forms of irrational behavior.
>
> So, now you are attacking me by saying I'm irrational
You have made numerous implausible claims regarding the purported
capabilities of terminal-mode software, and you have viciously
attacked a complete stranger without provocation. Delusional psychoses
are a plausible hypothesis to explain such behavior.
I would respond similarly if I were accosted on the street by a man
haranguing me about black helicopters of highly improbable stealth and
speed, imploring me to beware of government programs of highly
implausible secrecy in the era of Wikileaks, and then, after I had
expressed my skepticism, accusing me loudly of being a CIA agent.
> You must have one hell of an ego to think anyone could be bothered
> writing anything about you one way or the other.
And yet, several people have, though little of it was either
flattering or accurate.
> My post was not about you, it was about correcting incorrect statements
I do not make incorrect statements. This is an excellent example of a
remark about me that is neither flattering nor accurate.
> You as a person are totally irrelevant.
As is this.
You are contradicting yourself every few sentences. This is another
reason for one to call you irrational.
> >> In fact, I whent to considerable length not to try and make it appear
> >> personal while at the same time trying to point out why your statements
> >> were in error.
>
> > In other words, you went to considerable evidence to disguise the fact
> > that you were severely badmouthing me in public, while severely
> > badmouthing me in public. Hardly an admirable achievement worthy of
> > tooting one's own horn in this manner.
>
> You have admitted that you only read the first couple of
> sentences. Where in those sentences did I 'bad mouth you'?
When you accused me of incompetence, if not of outright dishonesty.
> In reality, what your saying is that you believe, without any evidence
> whatever, that I attacked and bad mouthed you.
I have plenty of evidence, as does the Google Groups archive.
> There is a term for what you have - paranoia
This, of course, constitutes one more piece of evidence.
With your every post, you dig yourself into a deeper hole by saying
you have no hostility towards me and no desire to personally attack
me, while simultaneously posting yet more personal attacks.
> You didn't read the rest, so you wouldn't know if I bad mouthed you or
> not.
The part that I did read had already done so, so I did know that you
had.
Did you think it had been just a lucky guess?
> Just for the record, I did not.
This is clearly a lie. The record speaks for itself: you implied
negative things about me, repeatedly.
> Your attack on me is completely unjustified.
On the contrary, it is quite justified. It is your attack on me that
is unjustified.
I posted impersonal statements about computer software. You responded
with counterfactual claims, insults, and other retorts some of them
designed to elicit negative opinions of me in other people. At this
point, I called you on your violent and antisocial behavior. You were
the first to become uncivil.
> All I did was attempt to point out where you were in error.
And that, of course, was yours. Error, that is.
1. I made no error.
2. Even if I had, it would not have been polite for you to publicly
accuse me of having done so, instead of employing a private mode
of communication.
3. Regardless, what you said implied, in public, negative things
about me, which has undesirable side effects I am now endeavoring
to correct.
4. Compounding your error, you are now making containing said side
effects extremely difficult. I suspect you are doing so
intentionally, in which case you cannot claim that this is an
accident and must admit that you have hostile motives and that
these acts of yours constitute deliberate attacks.
> In fact, the paragraphs that followed did not reference you at all.
Not directly. They nonetheless implied certain inaccurate and unwanted
claims about me.
> >> The bulk of the e-mail was factural statements regarding the current
> >> state of emacs.
>
> > I believe you have misspelled "usenet article" and "counterfactual".
>
> I believe you realise you got things totally wrong
I did not.
> and now your trying to get back face
If that were true, it would seem that you are going to a great deal of
effort to deny me that opportunity. And since you apparently believe
your assertions to be true, then you clearly harbor an intent to deny
me that opportunity. Such an intent is clearly a hostile one,
contradicting, once again, your earlier claim to have no hostile
motives toward me.
> a rather poor attempt at wit
Personal attacks like this, of course, furnish further evidence.
Since you have demonstrated clear hostility in multiple ways, while
repeatedly denying harboring any, it is the inescapable conclusion of
logic that you, sir, are a liar, and therefore that none of what you
have written about me should be considered credible by anybody reading
this thread. There are in fact two reasons to disbelieve all negative
claims you have made, or implied, about me: 1. your proven track
record as a liar and 2. your demonstrated hostility, which is an
obvious reason to suspect bias even in the statements you make that
you believe to be true.
> The ironic part of this is that your statements about emacs were the ones
> that were counterfactual.
Calling me a liar is not going to help you much now that you have been
proven to be the liar here. It merely creates the appearance of
projection, a dishonest attempt to deflect blame, and possibly "sour
grapes".
> >> It would seem that your so concerned about people thinking your stupid
> >> that your makeing very basic errors in comprehension.
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either emacs or Eclipse, Tim.
>
> Talk about pot calling the kettle black
The only irony here is that your personal attack, laced with terms
such as "stupid" and accusations of "errors", is laced with multiple
spelling and grammar errors of your own making.
> For the record, I don't have any opinion regarding eclipse. I happen to
> like emacs, but I don't care if nobody else likes it.
Then you have no "horse in this race" and no logical reason to
continue posting, unless, of course, it's personal. Which you've
claimed it's not, a claim already established as being almost
certainly a lie.
> As I stated in my original e-mail, different strokes for different folks.
What e-mail?
> All I was doing was correcting your errors.
I have none for you to correct. What you actually were doing was
publicly smearing a complete stranger. This aggressively hostile act
suggests a need for you to find some alternative outlet for the
frustrations in your life.
> >> I do not know you and don't know whether your stupid or not, but the
> >> evidence does indicate your overly defensive - to the point of
> >> interpreting any attempt to correct any misinformation you have as a
> >> personal attack.
>
> > I do not spread misinformation.
>
> You have made statements in previous messages that I have lied and I
> have bad mouthed you, neither of which are true.
I have just proven that you have, indeed, both lied and bad-mouthed
me. Compounding your moral and strategic errors by telling additional,
easily-refuted lies is not in your best interests, Tim.
> Of course I know you will say otherwise. My challenge to you would
> be to show actual instances where I have lied or bad mouthed you.
I have done so above.
> I used the term misinformation because I thought maybe you would read it
> and not consider it a personal attack.
Accusing someone of spreading misinformation is, of course, a personal
attack.
> The bottom line is that statements you made about emacs are incorrect.
No, they are not. It is the statements you have made about me that are
incorrect, and many of the statements you have made appear now to be
outright lies.
> Call it being wrong, being in error or misinformation, whatever you like.
I call it unwarranted and, at least initially, personal attacks on me
by yourself.
Shame on you.
> > Furthermore, I do not agree with your assertions about "overly
> > defensive". Even if I did, a public forum is not the appropriate place
> > to be discussing such matters. In a public forum, I must always
> > present as perfect as possible an appearance, and therefore am
> > compelled to deny all claims of flaws, regardless of whether or not I
> > privately think there could be any truth to them. In other words, I
> > must maintain what is sometimes called "face", and "keep up
> > appearances". If you have something you wish to discuss with me that
> > is not appropriate for a public venue such as this, the gmail address
> > in my news headers is valid. Use it.
>
> If that is your aim, I regret to inform you that this has not been the
> outcome.
Is that a threat?
> You attacked me for doing nothing more than attempt to correct your
> mistaken beliefs
I have no mistaken beliefs for you to correct.
I attacked you for attacking me in public, which I hope you are now
coming to realize was a grievous error. Perhaps many people roll over
and submit to your particular form of abuse, and allow you to tell the
world what idiots they supposedly are, but you have found, in me, a
person who is unwilling to tolerate that and will fight back.
Next time, choose your target more carefully, or better yet, find a
better method of stress-relief than publicly dumping on random persons
on the Internet.
> My only criticism of you at that time was to say [deleted]
Your error was not in the content of your criticism of me. It was in
the fact of your criticism of me. Do not publicly criticize me.
> In return, you called me a liar and then later said I bad mouthed you
Because you had.
> Again, I challenge you to show me one example of where I have bad mouthed
> you.
Every post to this thread bearing your name, or nearly so.
> Failing that, I expect a full and sincere apology.
Expect what you wish, but as the saying goes, "do not hold your
breath".
> >> How would someone have to phrase a correction for you so that it is not
> >> seen as a personal attack
>
> > They could do it privately.
>
> If you make a statement of error in a public forum, why is it not also
> acceptable for others in that public forum to correct you.
I did not make "a statement of error" in a public forum.
> If I only correct you privately, how does that help others who could
> be led astray by your error?
Your response is yet another vicious accusation. I do not lead people
astray. You will desist from publicly accusing me of that or any other
malfeasance or you will face the consequences. I have already
mentioned, in other posts, that falsely accusing people publicly
without evidence is commonly a tort. That means I can sue you.
> I also find this a rather large contradiction. You have stated on more
> than one occasion that you cannot let things people have written about
> you go without being addressed because they are wrong and could have a
> negative impact - what you referred to as keeping face.
Keeping face is not quite technically accurate, since that would only
be applicable were I guilty, and I am not.
> At the same time, you don't want anyone to correct your public
> mistakes in public, only privately.
I have no public mistakes. Furthermore, there is a difference between
my defending myself when personally badmouthed, and your defending an
unfeeling, inanimate piece of computer software when you feel it is
being badmouthed. The latter certainly is not a situation justifying
badmouthing human beings, even the one that badmouthed your favorite
software.
Human beings have rights, as well as feelings, that software lacks.
Hence the difference, and hence the lack of the symmetry you seem to
be trying to imply.
Another violation of that implied symmetry is that my criticisms of
emacs are valid; your criticisms of me are not.
> > I repeat: I do not spread misinformation.
>
> > Do not post such a vile accusation again, or I may have to consider
> > taking legal action. Accusing someone of intentionally corrupt
> > conduct, where such is not the case, is a violation of defamation laws
> > in most jurisdictions.
>
> Are you kidding?
I do not "kid".
> Your posts have been chock a block full of errors of fact
They have not.
The remaining lies and other pieces of nonsense in your post, of which
there were numerous, have been deleted. This includes a blatant and
probably-illegal attempt to incite hostility in others, multiple
accusations of lying, accusations of various forms of stupidity and
incompetence, and, unsurprisingly, also accusations of mental illness,
as well as such childish namecalling as calling me an "ass" and my
name "childish".
I note that nothing remains after the deletion of all the nonsense.
Your posts seem to have a signal-to-noise ratio of zero. I suggest you
avoid making any more of them.
From: Russell Jackson
Subject: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gvd4np$g42$1@aioe.org>
Tim X wrote:
[much snipped]
> Emacs has had native support for X windows for over 20 years. By native
> support, I do not mean running in an X term. I mean full native X
> support with the ability to open new frames (aka windows), move frames
> to different virtual desktops, stack frames on top of each other, tile
> frames, iconify frames etc. Unlike other editors, I also get the added
> benefit of being able to run under non-graphics environments, such as
> the linux console. In fact, I can open multiple console frames on the
> multiple console terminals you have under Linux - this means even if I
> don't have X installed I can run emacs with multiple frames and have
> each of those frames split into multiple windows. If I used the advanced
> features of the Linux console, I can even have more sophisticated
> fonts than the default 'fixed' version.
>
> There has been at least 1, if not two major releases of Emacs since you
> used it in the 90s, emacs 21 and emacs 22. A third one, Emacs 23 is
> currently under active development and probably not that far from being
> released as its very stable.
I tried using that beast maybe ten years ago myself. It sucked. From the
sounds of this, things may have changed. Has it now got a user interface
a Windows user could get used to and be productive in reasonably
quickly, or does it still require a cheat sheet and weeks of looking
things up in the help to use effectively?
> Emacs also has built-in support for numerous graphics types, including
> GIF, TIFF, SVGA, JPG etc and built-in support for playing sounds.
I confess I don't see how these would be useful in a text editor. Sounds
like bloat.
On the other subject of this unnecessarily long and noisome thread,
thanks, but no thanks. I hope the following remarks will make the
unshakability of my opinion clear:
Lost In Stupid Parentheses.
Lacking In Syntax and Types.
Lots of Irritating and Superfluous Parentheses.
Like I Stubbed Pinkie.
Language that Interests Some Palaeontologists.
Loris Is Slower Predicate? (NIL)
Language Implicated in Shortage of Parentheses.
Lacking Infix Syntax for Plus.
Ludicrously Involuted System for Programming.
Ludicrously Insular Society of Programmers.
Not that other languages don't sometimes try very hard to live down to
it. Smalltalk was also mentioned in this thread: honorable mention for
Lacking In Syntax and Types and Loris Is Slower Predicate? and a
definite contender in the bad-math-syntax department too -- 3 + 2 * 3 =
15, not 9? Wilcox tango foxtrot, interrogative?
I'll stick to Java*, thanks, and probably return to lurking. But I might
be persuaded to dump Eclipse for emacs if it's really improved a lot
since the nineties.
* Jungle of Architectures, Vendors, and Acronyms. (Hibernate, Struts,
Sun, J2EE, JSF, Oracle, JNI, JAXA, IntelliJ, XML, Glassfish, Apache,
Derby, Tomcat, JAI, Java2D, Swing ... gotta learn 'em all! It's the card
collector's programming language! And the collection you've amassed is
looked at in job interviews, too!)
Russell Jackson <······@nospam.gmail.com> writes:
> I tried using that beast maybe ten years ago myself. It sucked. From
> the sounds of this, things may have changed. Has it now got a user
> interface a Windows user could get used to and be productive in
> reasonably quickly, or does it still require a cheat sheet and weeks
> of looking things up in the help to use effectively?
That depends... how good is your memory? Emacs definitely isn't for
people who never want to learn anything, ever.
But if you thought it sucked ten years ago, you'll think it sucks
now. It's got the same mature interface it's had for the last few
decades and will have for the next few.
> Lacking In Syntax and Types.
Hmm, that implies that syntax is a good thing (and also that Lisp isn't
full of types...).
> Language Implicated in Shortage of Parentheses.
That's a good one. ;)
> Lacking Infix Syntax for Plus.
I believe you've misquoted that one. It's, "Lacking Infix Syntax *a* Plus".
Paul Donnelly <·············@sbcglobal.net> writes:
>> Language Implicated in Shortage of Parentheses.
>
> That's a good one. ;)
Only if you forget than most other languages have more parentheses
than Lisp. Java being C-like syntax-wise, I'd bet it uses more
parentheses than Lisp. C does.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> Paul Donnelly <·············@sbcglobal.net> writes:
>>> Language Implicated in Shortage of Parentheses.
>>
>> That's a good one. ;)
>
> Only if you forget than most other languages have more parentheses
> than Lisp. Java being C-like syntax-wise, I'd bet it uses more
> parentheses than Lisp. C does.
Well that's not a fair comparison... it takes so much more code to get
anything done; of course it takes more parens.
Do you count {} and [] as parens?
Paul Donnelly <·············@sbcglobal.net> writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>
>> Paul Donnelly <·············@sbcglobal.net> writes:
>>>> Language Implicated in Shortage of Parentheses.
>>>
>>> That's a good one. ;)
>>
>> Only if you forget than most other languages have more parentheses
>> than Lisp. Java being C-like syntax-wise, I'd bet it uses more
>> parentheses than Lisp. C does.
>
> Well that's not a fair comparison... it takes so much more code to get
> anything done; of course it takes more parens.
>
> Do you count {} and [] as parens?
Yes of course. And < and > in C++.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> Paul Donnelly <·············@sbcglobal.net> writes:
>
>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>
>>> Paul Donnelly <·············@sbcglobal.net> writes:
>>>>> Language Implicated in Shortage of Parentheses.
>>>>
>>>> That's a good one. ;)
>>>
>>> Only if you forget than most other languages have more parentheses
>>> than Lisp. Java being C-like syntax-wise, I'd bet it uses more
>>> parentheses than Lisp. C does.
>>
>> Well that's not a fair comparison... it takes so much more code to get
>> anything done; of course it takes more parens.
>>
>> Do you count {} and [] as parens?
>
> Yes of course. And < and > in C++.
Well, there's where we disagree.
On 2009-05-25, Pascal J. Bourguignon <···@informatimago.com> wrote:
> Paul Donnelly <·············@sbcglobal.net> writes:
>
>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>
>>> Paul Donnelly <·············@sbcglobal.net> writes:
>>>>> Language Implicated in Shortage of Parentheses.
>>>>
>>>> That's a good one. ;)
>>>
>>> Only if you forget than most other languages have more parentheses
>>> than Lisp. Java being C-like syntax-wise, I'd bet it uses more
>>> parentheses than Lisp. C does.
>>
>> Well that's not a fair comparison... it takes so much more code to get
>> anything done; of course it takes more parens.
>>
>> Do you count {} and [] as parens?
>
> Yes of course. And < and > in C++.
Let's not forget all of the other superfluous punctuation in these languages,
like commas and semicolons.
The source code of C, C++ or Java is made up of nested list structures. For
instance, a translation unit is essentially a list of external definitions. A
declaration has a list of declarators. A function call has a list of arguments.
A class definition has a list of base classes, list of members, et cetera.
There are all these lists, and for no good reason at all, they have different
lexical syntax. One is delimited with these parentheses, another one with
others. Some lists are not delimited by parentheses at all. Some strictly
have mandatory separators between their elements, others strictly separators,
yet others still go either way: the final terminator is optional.
In a declaration, the declaration specifiers and the terminating semicolon
should be counted as parentheses, because a declaration looks like this:
<specifiers> <declarator> [ "," <declarator> ] ";"
The specifiers say ``here comes a list'', just like an opening parenthesis, and
the terminating semicolon says ``the list is done'', just like a closing
parenthesis.
On May 25, 2:00 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Paul Donnelly <·············@sbcglobal.net> writes:
> >> Language Implicated in Shortage of Parentheses.
>
> > That's a good one. ;)
>
> Only if you forget than most other languages have more parentheses
> than Lisp. Java being C-like syntax-wise, I'd bet it uses more
> parentheses than Lisp. C does.
Maybe not more, but certainly more wisely. Have a look at
http://www.eecs.berkeley.edu/~fateman/papers/lispfloat.ps and note in
section 3.5 (bottom of p9, top of p10) the discussion about the use of
parens. This was one of our first "fight back" forays into dispelling
some of the myths of Lisp.
Duane
On May 25, 5:00 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Paul Donnelly <·············@sbcglobal.net> writes:
> >> Language Implicated in Shortage of Parentheses.
>
> > That's a good one. ;)
>
> Only if you forget than most other languages have more parentheses
> than Lisp. Java being C-like syntax-wise, I'd bet it uses more
> parentheses than Lisp. C does.
Nonsense -- wherever C uses braces, parentheses, OR brackets for
grouping, the equivalent Lisp code will use parentheses, parentheses,
and more parentheses, so C cannot possibly use more. :)
On May 24, 8:53 pm, Russell Jackson <······@nospam.gmail.com> wrote:
> Lost In Stupid Parentheses.
> [...]
The thing I don't get is this. Lots of people have negative reactions
to Lisp's syntax and aren't shy about saying so. Leaving aside the
fact that these opinions are almost never grounded in substantial
experience, the thing that really weirds me out is that I don't hear
the same obloquy directed towards XML, which is MUCH WORSE than Lisp!
Not only is it full of paired delimiters, these delimiters are much
harder to type than simple parentheses (I'm referring to the strings
like "<element>" and "</element>"; the angle brackets themselves are
not delimiters so much as meta-delimiters). XML-based languages are
far uglier than I could possibly imagine Lisp seeming to anyone.
XSLT, for instance, is just hideous. And yet, I run into more and
more of these things, and hardly anybody seems to complain about
them. It's absolutely unfathomable.
Whatever you think of S-expressions, they're a much better solution to
the problem of representing arbitrary trees than XML, and they existed
decades ago.
-- Scott
P.S. This will be my only post on this topic.
Scott Burson wrote:
> On May 24, 8:53 pm, Russell Jackson <······@nospam.gmail.com> wrote:
>> Lost In Stupid Parentheses.
>> [...]
>
> The thing I don't get is this. Lots of people have negative reactions
> to Lisp's syntax and aren't shy about saying so. Leaving aside the
> fact that these opinions are almost never grounded in substantial
> experience, the thing that really weirds me out is that I don't hear
> the same obloquy directed towards XML, which is MUCH WORSE than Lisp!
"Lots of Stupid Angle Brackets" doesn't quite have the same ring to it,
nor does its initials spell "XML".
But if you insist that an attempt be made:
eXtremely Muddled Language.
> Whatever you think of S-expressions, they're a much better solution to
> the problem of representing arbitrary trees than XML, and they existed
> decades ago.
Perhaps the ability of cons cells to represent, directly, only binary
trees, and cons trees' use of position instead of name as lookup key,
could have something to do with it?
Seamus MacRae <··········@live.ca.nospam> writes:
> Scott Burson wrote:
>> Whatever you think of S-expressions, they're a much better solution to
>> the problem of representing arbitrary trees than XML, and they existed
>> decades ago.
>
> Perhaps the ability of cons cells to represent, directly, only binary
> trees, and cons trees' use of position instead of name as lookup key,
> could have something to do with it?
That likely is what a person who didn't know anything about
s-expressions might think. Good point.
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Scott Burson wrote:
>>> Whatever you think of S-expressions, they're a much better solution to
>>> the problem of representing arbitrary trees than XML, and they existed
>>> decades ago.
>> Perhaps the ability of cons cells to represent, directly, only binary
>> trees, and cons trees' use of position instead of name as lookup key,
>> could have something to do with it?
>
> That likely is what a person who didn't know anything about
> s-expressions might think. Good point.
This looks like a personal attack with no logical purpose.
I shall provide you with a refresher on cons cells: they have two
pointers in them, called the address register and the decrement
register. Lists are implemented as unidirectional linked lists of cons
cells, with the decrement register pointing to the next list and the
address register to the list item. Hence the names -- address register
for the pointer to the list item, and decrement register for the pointer
to walk to get a one-shorter list, and eventually to reach the end of
the list.
Trees can also be represented, by pointing to more cons cells with the
address register, but a cons cell having only the two registers, these
trees are necessarily binary.
Other data structures, including higher-order trees, can be emulated by
various cumbersome means inside of a binary tree, but this is true of
all non-circular data structures. (And since cons cells can be made to
form circularities, in fact circular data structures can be implemented
on them as well -- but still only binary ones, or else emulated ones. A
fully general cons cell graph is a directed graph with unlimited
in-edges and max two out-edges per node.)
Seamus MacRae <··········@live.ca.invalid> writes:
> Paul Donnelly wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>> Perhaps the ability of cons cells to represent, directly, only binary
>>> trees, and cons trees' use of position instead of name as lookup key,
>>> could have something to do with it?
>>
>> That likely is what a person who didn't know anything about
>> s-expressions might think. Good point.
>
> This looks like a personal attack with no logical purpose.
That's a problem on your end. Although the "no logical purpose" part
cuts a little close, I must admit. I can't think of a logical reason I
should be responding to your posts... yet here I am. At least I'm not
stooping to reading them, right?
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>> This looks like a personal attack with no logical purpose.
>
> That's a problem on your end.
No, I can assure you that any potty-mouthedness problem is at your end.
> Although the "no logical purpose" part cuts a little close, I must
> admit. I can't think of a logical reason I should be responding to
> your posts... yet here I am. At least I'm not stooping to reading
> them, right?
And here is another personal attack.
I will, however, note for the record that at 02:38 UCT on May 27, 2009,
you did admit that you reply to posts without even reading them, thus
explaining why many of your posts do not logically refute their
predecessors, or even reference the topic of a debate (such as, say,
Java vs. Lisp), but merely contain an assortment of personal attacks.
Seamus MacRae <··········@live.ca.invalid> writes:
> Paul Donnelly wrote:
>> Although the "no logical purpose" part cuts a little close, I must
>> admit. I can't think of a logical reason I should be responding to
>> your posts... yet here I am. At least I'm not stooping to reading
>> them, right?
>
> And here is another personal attack.
To whom are you writing? *I* know what it is because *I* wrote it all by
myself, so not to me. Certainly I couldn't tarnish your reputation
further, so not to other participants in this "discussion". I don't
think your mother reads Usenet, and even if she did, what would she do?
It seems you're attempting to deflect attention from the substance of
the posts in this thread by frantically pursuing other topics. I would
advise you to debate with substance rather than resorting to that
tactic if you want to get anywhere.
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>> Paul Donnelly wrote:
>>> Although the "no logical purpose" part cuts a little close, I must
>>> admit. I can't think of a logical reason I should be responding to
>>> your posts... yet here I am. At least I'm not stooping to reading
>>> them, right?
>> And here is another personal attack.
>
> To whom are you writing? *I* know what it is because *I* wrote it all by
> myself, so not to me.
Are you claiming it's not a personal attack? Implying that reading my
posts is "stooping" certainly seems to be.
> Certainly I couldn't tarnish your reputation further
This, of course, is another personal attack.
> It seems you're attempting to deflect attention from the substance of
> the posts in this thread by frantically pursuing other topics.
I think you made a spelling error there. It should have read:
> It seems I'm attempting to deflect attention from the substance of
> the posts in this thread by frantically pursuing other topics.
That, I'd agree with -- instead of discussing Lisp vs. Java, you're
frantically pursuing the topic of what a fuckhead you think Seamus
MacRae is, even though it's completely irrelevant.
> I would advise you to debate with substance rather than resorting
> to that tactic if you want to get anywhere.
Follow your own advice. When you have something relevant to Lisp or Java
to say, I will debate it "with substance". Until then, there is nothing
to debate. Whether or not I am whatever nasty things you're thinking of
is non-negotiable -- I am not, and that's the end of it. Is that clear?
Seamus MacRae <··········@live.ca.invalid> writes:
> Paul Donnelly wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>> Paul Donnelly wrote:
>>>> Although the "no logical purpose" part cuts a little close, I must
>>>> admit. I can't think of a logical reason I should be responding to
>>>> your posts... yet here I am. At least I'm not stooping to reading
>>>> them, right?
>>> And here is another personal attack.
>>
>> To whom are you writing? *I* know what it is because *I* wrote it all by
>> myself, so not to me.
>
> Are you claiming it's not a personal attack? Implying that reading my
> posts is "stooping" certainly seems to be.
No, I'm asking why you're whining about it like someone cares. Man up.
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>> Paul Donnelly wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>> Paul Donnelly wrote:
>>>>> Although the "no logical purpose" part cuts a little close, I must
>>>>> admit. I can't think of a logical reason I should be responding to
>>>>> your posts... yet here I am. At least I'm not stooping to reading
>>>>> them, right?
>>>> And here is another personal attack.
>>> To whom are you writing? *I* know what it is because *I* wrote it all by
>>> myself, so not to me.
>> Are you claiming it's not a personal attack? Implying that reading my
>> posts is "stooping" certainly seems to be.
>
> No, I'm asking why you're whining
I am not whining, and your claim otherwise constitutes yet another
personal attack.
Moreover, none of this seems relevant to either Lisp or Java.
Seamus MacRae <··········@live.ca.invalid> writes:
> Paul Donnelly wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>> Paul Donnelly wrote:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>> And here is another personal attack.
>>>> To whom are you writing? *I* know what it is because *I* wrote it all by
>>>> myself, so not to me.
>>> Are you claiming it's not a personal attack? Implying that reading my
>>> posts is "stooping" certainly seems to be.
>>
>> No, I'm asking why you're whining
>
> I am not whining, and your claim otherwise constitutes yet another
> personal attack.
>
> Moreover, none of this seems relevant to either Lisp or Java.
Quite right. Thisi whining is completely irrelevant, and doesn't
constitute an argument in favor of either Java or Seamus MacRae. So why
do you feel so compelled to point out every single perceived slight?
Obviously it's because the argument isn't going your way and you wish to
distract everyone with some unrelated topic.
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>> Paul Donnelly wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>> Paul Donnelly wrote:
>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>> And here is another personal attack.
>>>>> To whom are you writing? *I* know what it is because *I* wrote it all by
>>>>> myself, so not to me.
>>>> Are you claiming it's not a personal attack? Implying that reading my
>>>> posts is "stooping" certainly seems to be.
>>> No, I'm asking why you're whining
>> I am not whining, and your claim otherwise constitutes yet another
>> personal attack.
>>
>> Moreover, none of this seems relevant to either Lisp or Java.
>
> Quite right.
Then please do shut up.
(I've deleted the personal attacks and other nonsense that cluttered
things up after your admission that I was right. It didn't seem worth
keeping or responding to.)
Seamus MacRae <··········@live.ca.invalid> writes:
> Paul Donnelly wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>> Paul Donnelly wrote:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>> Paul Donnelly wrote:
>>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>>> And here is another personal attack.
>>>>>> To whom are you writing? *I* know what it is because *I* wrote it all by
>>>>>> myself, so not to me.
>>>>> Are you claiming it's not a personal attack? Implying that reading my
>>>>> posts is "stooping" certainly seems to be.
>>>> No, I'm asking why you're whining
>>> I am not whining, and your claim otherwise constitutes yet another
>>> personal attack.
>>>
>>> Moreover, none of this seems relevant to either Lisp or Java.
>>
>> Quite right.
>
> Then please do shut up.
>
> (I've deleted the personal attacks and other nonsense that cluttered
> things up after your admission that I was right. It didn't seem worth
> keeping or responding to.)
"Please, everyone pay attention to me! Look how abused I am. :("
You're not fooling anybody, but I do believe you're the most
irredeemably boring troll I've ever seen. Kudos to your tenacity which
has kept me following this thread thus far, but no points for style.
I'll save you some bandwidth and ask everyone to please note the
personal attacks in my post here.
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.invalid> writes:
>> Paul Donnelly wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>> Paul Donnelly wrote:
>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>> Paul Donnelly wrote:
>>>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>>>> And here is another personal attack.
>>>>>>> To whom are you writing? *I* know what it is because *I* wrote it all by
>>>>>>> myself, so not to me.
>>>>>> Are you claiming it's not a personal attack? Implying that reading my
>>>>>> posts is "stooping" certainly seems to be.
>>>>> No, I'm asking why you're whining
>>>> I am not whining, and your claim otherwise constitutes yet another
>>>> personal attack.
>>>>
>>>> Moreover, none of this seems relevant to either Lisp or Java.
>>> Quite right.
>> Then please do shut up.
>>
>> (I've deleted the personal attacks and other nonsense that cluttered
>> things up after your admission that I was right. It didn't seem worth
>> keeping or responding to.)
>
> "Please, everyone pay attention to me! Look how abused I am. :("
>
> You're not fooling anybody
I'm not trying to fool anybody. I'm trying to get one of two things done:
a) Rerail this discussion to be about Java and Lisp again, or else
b) Shut it down entirely.
I do not want the public commentary about me-personally to continue.
Have I made myself clear?
> I do believe you're the most irredeemably boring troll I've ever
> seen. [rest of post deleted unread]
More personal attacks and zero on-topic substance. Please go away.
Seamus MacRae wrote:
> Paul Donnelly wrote:
>> Seamus MacRae <··········@live.ca.invalid> writes:
>>> Paul Donnelly wrote:
>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>> Paul Donnelly wrote:
>>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>>> Paul Donnelly wrote:
>>>>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>>>>> And here is another personal attack.
>>>>>>>> To whom are you writing? *I* know what it is because *I* wrote
>>>>>>>> it all by
>>>>>>>> myself, so not to me.
>>>>>>> Are you claiming it's not a personal attack? Implying that
>>>>>>> reading my
>>>>>>> posts is "stooping" certainly seems to be.
>>>>>> No, I'm asking why you're whining
>>>>> I am not whining, and your claim otherwise constitutes yet another
>>>>> personal attack.
You will not escape those "personal attacks" until you stop writing
ill-informed nonsense, which seems to be never, given your track record.
Your problem with "sizeof *foo" is just one of your most glaring errors.
You have to realize that you do make errors.
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Paul Donnelly wrote:
>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>> Paul Donnelly wrote:
>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>> Paul Donnelly wrote:
>>>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>>>> Paul Donnelly wrote:
>>>>>>>>> Seamus MacRae <··········@live.ca.invalid> writes:
>>>>>>>>>> And here is another personal attack.
>>>>>>>>> To whom are you writing? *I* know what it is because *I* wrote
>>>>>>>>> it all by
>>>>>>>>> myself, so not to me.
>>>>>>>> Are you claiming it's not a personal attack? Implying that
>>>>>>>> reading my
>>>>>>>> posts is "stooping" certainly seems to be.
>>>>>>> No, I'm asking why you're whining
>>>>>> I am not whining, and your claim otherwise constitutes yet another
>>>>>> personal attack.
>
> You will not escape those "personal attacks" until you stop writing
> [rest of threatening and insulting post deleted]
Why are you butting in, and with more off-topic nonsense? Let's get back
to discussing Java and Lisp please.
Series Expansion <·······@gmail.com> writes:
> On May 16, 4:42�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > Prompts are so 1985.
>>
>> Notice that in 1985, GUI existed and were commercialized already for a
>> few years.
>
> They weren't commonplace, aside from the clunky old black-and-white
> Macs.
And the Lisa, and Amiga, and the Apollo, Xerox Alto, Lisp Machines,
Xerox Star, Three Rivers PERQ workstations.
>> I agree that GUI are generaly nice. �Unfortunately they're also less
>> productive than CLI.
>
> You mean, more productive. GUIs provide a lot of productivity
> benefits:
No, they're much less productive.
> * Increased screen real-estate for text. Instead of a smallish rigid
> rectangular grid of ASCII characters you can have quite a large
> grid, and you can use a proportional font and ditch the grid
> constraint.
Text.
> * Ability to display much larger character sets, foreign characters
> for instance. The best pre-graphics systems could display sometimes
> several of the European languages, though only one at a time, by
> supporting a choice of code pages. GUIs can display the whole of
> Unicode, including the very large character sets used in
> far-Eastern languages, and mix them all seamlessly (modulo
> reading-order differences).
Text.
> * A picture is worth a thousand words. GUIs can display symbols like
> a dangling plug instead of taking up much more space with the
> slower-to-comprehend word "disconnected", allowing more compact and
> informative status areas.
In reality this is wrong. Notably in the case of pictures you find in
GUIs.
> * The same thing lets GUIs put a dangling plug symbol onto a
> push-button to clearly and concisely do all of these at once:
> - tell you you can disconnect
> - tell you one way of doing so
> - provide that way of doing so
> In a terminal you're stuck putting the first item in a status line
> at the bottom (say, the word "connected"), the second buried in a
> long help file somewhere out of immediate view, and the third bound
> to some probably unguessable hotkey without browsing the help
> (screen-oriented) or by typing "disconnect" and enter at some
> prompt (line-oriented). The latter can still be subject to
> usability problems:
> - guess-the-verb, if there are several synonyms; a common culprit
> is when exactly one of "quit" and "exit" works, or worse,
> neither, and different ones don't work in different apps, with
> none working in all
Here you are explaining that GUI are good for people with poor
vocabulary. There are even some people who think that watching
pictures all day long (eg on TV) dumbs the watchers down.
Well, it's not me who said it...
> - it takes eleven input actions to type "disconnect" and hit enter
> versus two, a flick of the mouse and a click, to hit a button.
> For frequently-used commands the difference adds up rapidly.
Yes. But then you can says:
disconnect when no work done in 15 minutes
or at 18:00
or when downloading porn.
Try to say such a thing by clicking on icons.
And once you can say textual commands, you can easily put them in
script, in programs. Try to do the same with GUI!
And once you've found a system to do it with GUI (there exist some),
compare the speed and expressiveness of the GUI and CLI scripting.
> * Flexibility of workflow. The user can open and arrange various
> windows to suit, move data around via copy and paste, and the like.
> A terminal constrains the user to using a linear sequence of
> applications, and of screens within an application, and working out
> some cumbersome system of scratch files to move data around.
> Copy/paste doesn't work across applications and only one screen of
> one application can be used at a time.
CLI and text based interfaces can do the same.
> * Web access. The web is largely unusable with lynx nowadays.
There are other text based browser.
The web usability question is not relative to the text or CLI aspects,
but on the support for things such as Flash or Javascript.
> * A GUI can place your current actions and work in context in various
> ways. For example, a file list can be accompanied by a directory
> tree, and the image files in formats your file manager recognizes
> can be displayed as thumbnails, so you can find images by what you
> remember them looking like and not just by what you remember their
> filenames to be. Every additional way to view or find things helps,
> and a lot of ways are inherently incompatible with displaying in an
> ASCII terminal.
Who talked of ASCII terminals?
Did you even watch the URI I gave showing how lisp REPL may output
both graphics and texts?
> [...] Users want to write code, fix the red-eye in
> their photos, or whatever, [...]
This user doesn't want to write code, fix the red-eye in my photo, or
whatever. I want the computer to do that for me, so I can go to the
beach.
> * A window system also supports *user* multitasking.
No, it's the operating system that supports multi-tasking.
> If point-by-point arguments bore you, here's the nutshell,
> metaphorical version too: after using a GUI, using anything more
> primitive feels like flying a plane with no instruments, a keyhole-
> sized cockpit window to peer out of, and a control stick you have to
> talk to rather than simply pull, push, and turn with your hands.
Well after using GUIs for a few years, I came back to more textual
user interfaces, because I lose less time with them.
> It can be quite disconcerting to tell a CLI to move some files and
> just have the prompt reappear: did it even do anything? Even more so
> to tell it to move some files and have it appear to hang.
If you want feed back you can always order it.
But I don't see what's disconcerting in having the computer execute
the orders you give it...
> Versus seeing the files appear one by one in the destination folder,
> and if it's taking long enough, a clock counting down the estimated
> time remaining until the job's done. And being easily able to do
> something else (except if it involves those files) in the meantime.
In any case, I don't spend my time watching clocks counting down.
When I give a command that will take time to complete, I order the
computer to do it in background and go on with the rest of my tasks.
>> and the point is not to let the user manipulate himself the texts, but
>> as much as possible to direct emacs to do the editing instead of the
>> user.
>
> This is problematical. Writing program code is a largely un-
> automatable task,
We've spent the last two days explaining you how you automate writting
code with lisp macros. You still don't get it.
> aside from generating parser skeletons from grammars
> and GUI code from forms. We have bison for the former, and if you're
> generating GUI code you're generally doing it from an actual GUI!
It's more efficient if you let the computer generate the GUI code,
from commands.
> So your dream of being able to just type "write the implementation of
> the Foo.bar() method for me" and enter at a prompt and get useful code
> out if it is not likely to be fulfilled anytime soon.
Metafor Interactive Natural Language Programming
http://www.lehigh.edu/~amsp/2005/03/metafor-natural-language-programming.html
http://web.media.mit.edu/%7Ehugo/demos/metafor-bartender-simple.mov
http://web.media.mit.edu/~hugo/publications/
http://web.media.mit.edu/~hugo/publications/papers/IUI2005-metafor.pdf
Notice how it's a text based user inteface!
>> So instead of clicking on buttons on menues, we can give commands, and
>> add and improve the commands we may give to your lisp systems.
>
> Many major GUI applications provide equivalent capabilities. In Word
> for example you can write VBScript to do something novel to a document
> and then give it an icon and add it to your toolbar, or bind it to a
> control-shift-foo type hotkey, or both. NetBeans has a templating
> language for customizing its code generation, and is open source, so
> you can hack NetBeans itself if hacking in the templating language
> won't suffice. New templates appear in appropriate places in the
> menus. Eclipse is even more modular and reprogrammable, using Java and
> SWT. It can even be turned into a non-IDE tool such as a word
> processor.
Good for them, they copied the feature from emacs.
>>�This way, instead of doing the work yourself, you can just
>> give commands to the computer and it will work for you.
>
> If the Lisp code you're editing can be generated automatically,
> shouldn't you be using a Lisp macro instead of having your editor
> churn it out? Then you can just change the macro later instead of
> every spot where the editor did whatever it did.
>
> Your arguments in favor of a command-driven editor instead of a normal
> one appear to contradict your arguments in favor of Lisp macros. I'm
> afraid you'll have to pick exactly one of those to continue to
> support, or else lose credibility in both debates.
We're not always editing lisp code...
--
__Pascal Bourguignon__
On May 17, 10:26 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > They weren't commonplace, aside from the clunky old black-and-white
> > Macs.
>
> And the Lisa, and Amiga, and the Apollo, Xerox Alto, Lisp Machines,
> Xerox Star, Three Rivers PERQ workstations.
None of those were commonplace. The home computer market share at that
time was about 90% MS-DOS, 9% Mac, and 1% Amiga, if not even more
tilted towards MS-DOS. The other machines you named had essentially
zero market share in home and office-cubicle settings.
> >> I agree that GUI are generaly nice. Unfortunately they're also less
> >> productive than CLI.
>
> > You mean, more productive. GUIs provide a lot of productivity
> > benefits:
>
> No, they're much less productive.
That is incorrect, as I have already explained in detail.
> > * Increased screen real-estate for text. Instead of a smallish rigid
> > rectangular grid of ASCII characters you can have quite a large
> > grid, and you can use a proportional font and ditch the grid
> > constraint.
>
> Text.
Rendered onto a bitmapped display using a graphics card, often with
nice features like antialiasing that improve readability, rather than
directly rendered in a single chunky 8x16 pixelated fixed-pitch font
by the hardware.
This makes all the difference in the world. The system can display
more text, text that's more comfortable (and faster!) to read, and
text in arbitrary languages using arbitrary combinations of the tens
of thousands of characters in worldwide use, rather than less text
that's less comfortable (and slower) to read, from only one at a time
of a handful of 256-character code pages.
You're just not getting it are you, Pascal?
There is a single class of people for whom none of this applies,
though they are by far in the minority: blind people. GUIs are going
to be nearly unusable for them, and text-based interfaces (with an
appropriate screen reader or Braille-based display monitor, and speech
recognition software) only marginally worse than for sighted people.
Text-based interfaces might come out ahead; basically all of the
advantages of GUIs disappear, and the nonlinear nature of GUIs turns
from advantage to disadvantage when everything has to be serialized
through a screen reader or a moving fingertip anyway.
If you are blind, it would explain your attitude, but not your failure
to explain at the time that your assertions about which interfaces are
more productive were from the point of view (so to speak) of a blind
person. Instead you simply made those assertions as if they were
universal truths, equally applicable to all human beings, and stated
as such, those assertions are factually incorrect.
If you are not, then your remarks here are completely inexplicable.
> Text.
Got a stutter, too?
> > * A picture is worth a thousand words. GUIs can display symbols like
> > a dangling plug instead of taking up much more space with the
> > slower-to-comprehend word "disconnected", allowing more compact and
> > informative status areas.
>
> In reality this is wrong.
No, it is not. Once again you have responded to detailed reasoning
with unsupported assertions, strongly implied personal attacks, and a
complete lack of any evidence or actual argumentation to support your
claims.
> > - guess-the-verb, if there are several synonyms; a common culprit
> > is when exactly one of "quit" and "exit" works, or worse,
> > neither, and different ones don't work in different apps, with
> > none working in all
>
> Here you are explaining that GUI are good for people with poor
> vocabulary.
No, I am explaining that GUIs are good for people, period. The purpose
of using a productivity application is to do useful work, not to play
guessing games with it. A large vocabulary does not even boost the
odds of accurately guessing the synonym much, since the synonym
chosen, in cases where there were plausible alternatives, is usually
one of a few very widely known English words rather than anything
truly obscure. The problem, though, is with having to guess at all;
being more likely to succeed, or faster at doing so, won't beat the
success-chance and speed advantage of not having to even try.
This is part of a more general difference: usability boils down to
"the interface gets out of your way and lets you focus on actually
doing your job instead of being distracted by having to consciously
manage the mechanics of using the interface". Hands-on interfaces are
good at getting out of the way and letting you forget, consciously,
their mechanics. Talk-to interfaces are bad at this, as well as (and
partly because of) simply being slower to use. Why do you think that
voice command, while perfectly feasible now (and commonly used by
blind people), has still not taken off for use by the general
population? Because by the time you can say (or type) "delete foobar"
a sighted user with a modern interface could have already deleted
foobar themselves, and two or three other things too (if nearby).
> There are even some people who think that watching
> pictures all day long (eg on TV) dumbs the watchers down.
The argument actually hinges on the noninteractive nature of TV-
watching, not on the it-has-pictures aspect.
Furthermore, it has not stood up to scientific scrutiny.
> > - it takes eleven input actions to type "disconnect" and hit enter
> > versus two, a flick of the mouse and a click, to hit a button.
> > For frequently-used commands the difference adds up rapidly.
>
> Yes. But then you can says:
>
> disconnect when no work done in 15 minutes
> or at 18:00
> or when downloading porn.
The latter are undesirable; if you don't want to download porn, don't
click on download links for any, and telling it to disconnect at 18:00
will sooner or later result in you losing a 90%-done, large-file
download someday because the download would have taken until 18:01.
Disconnect-if-idle is far better if you want to avoid it staying
connected overnight by accident.
And GUIs can do disconnect-if-idle. Many have for instance an options
dialog with something like this in it:
[x] Disconnect if idle for [15 ] minutes
where one checks the box and types in a number. Often there's a drop-
down menu for the most likely values, such as the first few even
multiples of 15 minutes.
> Try to say such a thing by clicking on icons.
A classic example of a straw-man argument, assuming that the ONLY
means of interaction in a GUI would be by clicking on icons. Anyone
who has used a real actual GUI system would know that this is not
true, and indeed that GUIs are capable of providing every kind of
interaction text-based interfaces can provide, though not, of course,
vice-versa.
This is what really destroys your arguments here: there is nothing a
text-based interface can do that a GUI can't do, so it is simply not
logically possible for text-based interfaces, as a class, to be
superior to GUIs, as a class. (Except maybe for blind users.) And
since that particular impossible thing was your claim, your claim was
wrong.
> And once you can say textual commands, you can easily put them in
> script, in programs.
Why, so that the system can run amok deleting things without user
confirmation or intervention?
And no, you can't "easily" do anything of the sort. 99.999% of the
population are not computer programmers, and therefore cannot do that
at all. The remainder can program an application to do whatever they
want done, whether text-based or GUI, either by modifying an open-
source program or by writing a whole new one.
> And once you've found a system to do it with GUI (there exist some),
> compare the speed and expressiveness of the GUI and CLI scripting.
GUIs are faster and more expressive than CLIs, except on sufficiently
mediocre hardware. (Then GUIs are slower and more expressive.)
> > * Flexibility of workflow. The user can open and arrange various
> > windows to suit, move data around via copy and paste, and the like.
> > A terminal constrains the user to using a linear sequence of
> > applications, and of screens within an application, and working out
> > some cumbersome system of scratch files to move data around.
> > Copy/paste doesn't work across applications and only one screen of
> > one application can be used at a time.
>
> CLI and text based interfaces can do the same.
No, they cannot. There is no way to put email notification in the
bottom right corner of the screen, a program-launch menu in the lower
left, a text editor open to some file at top left, a file system
browser open to a particular directory at top right, one open to a
different directory center-right, and a small browser window left
parked at google center-left, in a CLI-based interface, and although
it's not quite *impossible* in a curses-based interface, it could not
be done well. The results would be infinitely more cumbersome to use
than a real GUI and would also have problems displaying very much when
a small grid of ASCII was subdivided into six even smaller chunks.
> > * Web access. The web is largely unusable with lynx nowadays.
>
> There are other text based browser.
All of which will suffer from the same problem: the vast majority of
web sites are designed for viewing in a GUI. Without a GUI:
1. Frames won't work in any acceptable fashion. The problems
described above and elsewhere in this thread with dividing a
curses screen into "windows" will all apply.
2. Tables will have problems, potentially severe depending on how
wide they'd have to be. Tables with wrapped lines are *ugly*, and
very difficult to parse.
3. Forms are obviously out of the question, since Web forms are GUIs
with command buttons, input fields, and the like.
4. You could maybe fudge a form submission with a manually-typed
www-form-url-encoded URL. This would be like using a hex editor
to edit a text file instead of a text editor. On top of that
pain, if the form requires a captcha be solved, you still can't
do it.
5. Most sites organize their pages using graphical dividers. Without
these, everything jumbles together and gets mixed in with
[IMAGE][IMAGE][IMAGE] and the like.
6. Links that are images all appear as [LINK]. Which of several
[LINK]s is the link to the sports pages? Hell if I know!
7. The above two items are not materially altered if the browser
uses different text to indicate non-link and link images. The fact
that it can only use text suffices to cause these problems
wherever sites use images that lack "alt" attributes.
8. Obviously flash-based sites are out of the question.
9. Ditto Java-based sites, sites that require Javascript, and so
forth.
For example, where a graphical browser aimed at a new site might show
three columns, with a photograph at the top of one with an embedded
(part of the image file) caption, and in all three a headline followed
by some story details corresponding to that headline, and a link for
further information consisting of a right-facing triangle with no alt
text, viewing this same site in a text browser will get you:
[IMAGE] Headline2 Headline3 Headline1 [IMAGE] [IMAGE] [IMAGE] Story1
Story2 Story3 [LINK] [LINK] [LINK].
Good luck figuring out what's going on there.
What causes this? First, the layout is done with tables. Second,
though the data is arranged in columns, tables are row-major in HTML.
So there's the image for story 1, then the headlines for stories 2 and
3, in the top row; the first story's headline in the next row,
followed by two empty cells; then a row of alt-text-less horizontal-
line images used as dividers; then a row of story summaries; and
finally a row of links. When output linearly by a text-based browser
lacking any support for tables, you get the above. With support for
tables you get something arguably slightly better:
[IMAGE] Headline2 Hea
dline3
Headline1
[IMAGE] [IMAGE] [IMAGE]
Story1 Story2 St
ory3
[LINK] [LINK] [LINK]
Ugly, but serviceable. Barely.
Still slower and more cumbersome to read, due to the formatting (the
line wrap is simulated here, based on the likely real lengths of the
headlines and summaries exceeding what will fit on one line of a
primitive display terminal), and also cumbersome to use by arrowing
everywhere and hitting enter. No mouse pointer, no scrollbars, no back
button, no amenities.
> The web usability question is not relative to the text or CLI aspects,
> but on the support for things such as Flash or Javascript.
Actually, no, it's relative to both.
> > * A GUI can place your current actions and work in context in various
> > ways. For example, a file list can be accompanied by a directory
> > tree, and the image files in formats your file manager recognizes
> > can be displayed as thumbnails, so you can find images by what you
> > remember them looking like and not just by what you remember their
> > filenames to be. Every additional way to view or find things helps,
> > and a lot of ways are inherently incompatible with displaying in an
> > ASCII terminal.
>
> Who talked of ASCII terminals?
You did. You were discussing the supposed lack of advantage of GUIs
over the text-based interfaces on pre-graphics software like Unix's
command shells and text editors.
So I am comparing the usability of a modern graphical workstation with
the usability of a Unix mainframe remotely accessed using a (real or
emulated) VT320 over a reasonably-low-latency connection.
The interfaces of the programs you are championing were designed to be
presented on precisely that kind of hardware configuration, and so
their capabilities will be constrained by the capabilities of such
hardware. I have used several of the programs named recently and so I
also know this by direct experience, but I bolster that eyewitness
testimony with a logical explanation why it cannot be otherwise.
If you think the comparison is somehow unfair, then you should
probably not have entered a donkey into the Kentucky Derby.
> Did you even watch the URI I gave showing how lisp REPL may output
> both graphics and texts?
Obviously no URI with the stated properties exists, since a VT320 is
incapable of displaying graphics, and a Lisp REPL will have been
designed for use with precisely that sort of hardware.
Your implicit claim otherwise is as absurd as a suggestion that
ADVENTURE had Quake-style graphics.
In actual practice, I've run into exactly two CLI-driven applications
with graphics: Maple V and Mathematica. Both have something similar to
a Lisp REPL in a GUI window with a display area above it that shows
results. Neither have especially stellar usability, either.
Importantly, neither predates modern graphics hardware or was designed
for potential use remotely via a VT320.
(I don't count games like Quake with drop-down consoles as "CLI-
driven" because entering commands into their consoles is not their
sole, or even primary, means of user interaction.)
> > [...] Users want to write code, fix the red-eye in
> > their photos, or whatever, [...]
>
> This user doesn't want to write code, fix the red-eye in my photo, or
> whatever. I want the computer to do that for me, so I can go to the
> beach.
Tough. The computer can fix the red-eye in your photo, but it has to
know you want this done and to which files. So you'll need to use a
computer program with a user interface of some sort to make it happen.
If you want to actually be able to see what's going on it will have to
be a graphical interface.
The computer cannot write your code for you. The day a computer exists
that can is about four years before the arguable end of the world[1].
> > * A window system also supports *user* multitasking.
>
> No
Yes.
> it's the operating system that supports multi-tasking.
The operating system supports *program* multitasking. A window system
supports *user* multitasking. Pre-X-Window-System Unix workstations
supported program multitasking but the user could only work with one
at a time, and switching among them was extremely cumbersome, so the
user would tend to spend a long time in program 1, then a long time in
program 2, and so forth. The modern, fluid flow of user work among
several different open programs, with notifications of events like
incoming instant messages and mail, could not easily exist in that
environment, and even if it somehow occurred, could not have been
efficient compared to modern user workflows.
You might argue that users were more productive by being less
distracted, but it's not so; some work might be faster to perform that
involves using many different tools instead of just one, because the
user can more easily move their attention among those different tools,
and can more easily move data among them. Furthermore, if the user has
two tasks, one urgent and one non-urgent, and the urgent one is stuck
until an email bearing important information arrives:
* On a text-only system the user must sit in the mail program and
wait. If the user tries to work on the less-urgent task, they have
to stop frequently to manually check mail, which will slow them
down at the less-urgent task, and will miss the arrival of the
mail by, on average, half the time between mail checks, which will
slow them down at the more-urgent task. More frequent checking
reduces the latter delay at the expense of the former, and
vice-versa.
* On a GUI system the user can just work on the less-urgent task
until the you-have-mail chime, save, alt-tab, read the mail,
alt-tab-tab, resume the more urgent task, and have spent zero time
checking mail except when the mail had just arrived, and have seen
the mail almost instantly when it did arrive, for a potential gain
of up to several tens of minutes of productive work that day.
Of course, you might argue that constant chimes and glances at the
bottom right every few minutes when a spam arrives will waste time,
but a mail client is theoretically possible that lets you suppress
tray notification except for mail matching some filter criterion, such
as From: contains ···@bar.com or Subject: contains undefined symbol
error in foo.c make'ing FooLib on Suse 6.3 w/ glibc 2.1.1. You could
set this and forget it until the urgent mail (which would match the
filter, and be the only thing likely to do so) arrived.
> > If point-by-point arguments bore you, here's the nutshell,
> > metaphorical version too: after using a GUI, using anything more
> > primitive feels like flying a plane with no instruments, a keyhole-
> > sized cockpit window to peer out of, and a control stick you have to
> > talk to rather than simply pull, push, and turn with your hands.
>
> Well after using GUIs for a few years, I came back to more textual
> user interfaces, because I lose less time with them.
This statement is implausible unless you are visually impaired to at
least some extent. It becomes quite plausible if you use screen-
reading software and voice-recognition software.
So I will charitably interpret your remarks as equivalent to "I am
blind" rather than as meaning "I am a nut, idiot, or liar". :)
> > It can be quite disconcerting to tell a CLI to move some files and
> > just have the prompt reappear: did it even do anything? Even more so
> > to tell it to move some files and have it appear to hang.
>
> If you want feed back you can always order it.
Maybe I don't want to *have* to order it. Maybe I want what you claim
*you* want: the computer to anticipate my needs and do more in
response to less explicit input from me.
> But I don't see what's disconcerting in having the computer execute
> the orders you give it...
No, what's disconcerting is not knowing whether it succeeded or
silently failed, and not knowing whether it's working or hung.
Of course, silent failure is, by itself, a usability blunder of
considerable severity. It is also unfortunately rather common.
> > Versus seeing the files appear one by one in the destination folder,
> > and if it's taking long enough, a clock counting down the estimated
> > time remaining until the job's done. And being easily able to do
> > something else (except if it involves those files) in the meantime.
>
> In any case, I don't spend my time watching clocks counting down.
Neither do I. I'd do something else, but maybe glance at it from time
to time. If I were somehow to wind up stuck with text-based
interfaces, I would not only not have such information in my
software's interface anymore, I would not even have the ability to
glance at something from time to time in the world inside the
computer.
> When I give a command that will take time to complete, I order the
> computer to do it in background and go on with the rest of my tasks.
As do I. But it's useful to be able to check on its progress easily
and quickly from time to time. If it gives estimates of when it will
be done, or you can glean one from the movement of a progress bar, you
can even judge when to check it again. If it's unreliable for whatever
reason (e.g. a web download) you can check it for not having hung/
failed and retry it fairly promptly if it had, not wait three hours,
then check only to find it failed during the first five minutes of
those three hours. Better still, it might be able to quietly alert you
when it had either finished or failed, without being too distracting
but also without needing you to switch to it from time to time to find
out about its progress.
One GUI Web browser (Google Chrome) displays a popup in its lower left
corner with progress bars for active downloads. It's not visible
unless that part of the Chrome window is uncovered, but it is visible
if you're surfing while you wait for the downloads, and you can do
other work (if it's web-based work) in the browser while keeping an
eye on the progress, and rate of progress in your peripheral vision.
You can't do, or have, anything like this with Lynx or any other text-
based software!
> >> and the point is not to let the user manipulate himself the texts, but
> >> as much as possible to direct emacs to do the editing instead of the
> >> user.
>
> > This is problematical. Writing program code is a largely un-
> > automatable task,
>
> We've spent the last two days explaining you how you automate writting
> code with lisp macros.
This remark both fails to address the above comment by myself and
contains an implied personal attack. Most illogical.
Your Lisp macros actually demolish your argument in favor of having
your text editor automate code generation tasks: it is far preferable
to have the Lisp compiler do this instead. Therefore the Lisp code you
edit in the editor will ideally consist entirely of non-machine-
generatable code, that is, only code that a human has to think
creatively about and then type. Whereupon the editor need not provide
any kind of code generation or refactoring tools. Macros should be
used to do those jobs instead! And the editor can't write those for
you either, or you'd want to use macros to do *that*, and so on ad
infinitum.
However, your comments about automatic code generation are not
arguments against GUIs. In fact they argue in favor of GUIs. You see,
not only can a GUI editor (or better yet, IDE) do these things, but it
can present these features to the user in a manner that will be far
less cumbersome to use. For example, in NetBeans one can type "private
int foo;" in a Java class's source code, right click, and see a
context-dependent list of likely useful actions including, in this
case (cursor on a field declaration), "generate getter and setter".
Another click and boom! Two methods. If you don't want the setter, a
quick click and drag and DEL keypress makes it go away, or (I think)
you can generate only the getter.
In a text-based application, by way of contrast, you'd have to type
"private int foo;", then type control-shift-alt-meta-I-sure-hope-I-
remember-this-long-and-cumbersome-keyboard-"shortcut"-F1, and then
type "foo" at a prompt. Then to delete the setter, hit down-arrow 17
times, shift-down-arrow four times, and DEL.
> > aside from generating parser skeletons from grammars
> > and GUI code from forms. We have bison for the former, and if you're
> > generating GUI code you're generally doing it from an actual GUI!
>
> It's more efficient if you let the computer generate the GUI code,
> from commands.
To edit the GUI form you need a GUI, of course. (If the form's state
is saved in some format other than as the actual GUI code that is the
desired final result, a text-based tool could conceivably be used to
read that saved data and output the actual GUI code. However there
seems no need for the extra layer of indirection here and the form
editor tool, which must be graphical, should be able to do this
itself.)
> > So your dream of being able to just type "write the implementation of
> > the Foo.bar() method for me" and enter at a prompt and get useful code
> > out if it is not likely to be fulfilled anytime soon.
>
> Metafor Interactive Natural Language Programming
> http://www.lehigh.edu/~amsp/2005/03/metafor-natural-language-programm...
> http://web.media.mit.edu/%7Ehugo/demos/metafor-bartender-simple.mov
> http://web.media.mit.edu/~hugo/publications/
> http://web.media.mit.edu/~hugo/publications/papers/IUI2005-metafor.pdf
>
> Notice how it's a text based user inteface!
Notice how it's essentially vaporware. As I stated above, the day a
computer can program without human assistance is about four days
before the end of the world as we know it[1].
> > Many major GUI applications provide equivalent capabilities. In Word
> > for example you can write VBScript to do something novel to a document
> > and then give it an icon and add it to your toolbar, or bind it to a
> > control-shift-foo type hotkey, or both. NetBeans has a templating
> > language for customizing its code generation, and is open source, so
> > you can hack NetBeans itself if hacking in the templating language
> > won't suffice. New templates appear in appropriate places in the
> > menus. Eclipse is even more modular and reprogrammable, using Java and
> > SWT. It can even be turned into a non-IDE tool such as a word
> > processor.
>
> Good for them, they copied the feature from emacs.
The point being, the feature is not inherently exclusive to a text-
based application.
In fact, they were able to improve on it. A text-based application can
only let you bind such scripts to hotkeys and/or to typed commands at
a prompt (M-x doctor, for example, to invoke the "doctor" script that
comes with emacs). Word enabled the user to bind scripts (and in
earlier incarnations, macros) to toolbar buttons added to the GUI. The
latest version replaces the toolbar with a ribbon-bar that can also
have custom commands added to it. This means one-click access to user-
defined scripts! No need for any monkeying around with an escape
sequence and then typing (and possibly misspelling or forgetting) some
(possibly long) name.
> >> This way, instead of doing the work yourself, you can just
> >> give commands to the computer and it will work for you.
>
> > If the Lisp code you're editing can be generated automatically,
> > shouldn't you be using a Lisp macro instead of having your editor
> > churn it out? Then you can just change the macro later instead of
> > every spot where the editor did whatever it did.
>
> > Your arguments in favor of a command-driven editor instead of a normal
> > one appear to contradict your arguments in favor of Lisp macros. I'm
> > afraid you'll have to pick exactly one of those to continue to
> > support, or else lose credibility in both debates.
>
> We're not always editing lisp code...
Well, when you're removing red-eye from photos, you are going to need
an image editor rather than a text editor, and in fact will need a
GUI.
When you're writing mail or news, you are going to need Thunderbird or
something similar.
In fact, I can't think of anything else emacs might be good for
besides editing code or freestanding text documents, and I can't think
of a single thing it can do that other things can't do better.
There once was an exception: confusing and frustrating a newbie. But
I've since seen some Flash-based websites that would turn you white...
Regardless, you have not refuted my claims. Nor could you ever refute
my own personal experience, which is that the user interfaces of text-
based applications, especially Unix tools of any vintage, are
invariably either enormous messes of awkward chord sequences, or else
simply vomit-inducing.
[1] The argument goes as follows: once a software program exists that
is smart enough to understand computer programming and thus able to
automate computer programming, such a program can, and likely will,
decide to improve itself. At that point, such software largely
replaces human engineers, in the usual pattern with automation. Only
now the entities designing computer technology double in speed
whenever computers double in speed. If humans can double computer
speed every two years, and at some point in time an intelligent
software entity can do the same job at the same speed, in two years it
can do that job twice as fast and computer speed will double again in
only one more year. At the end of that year, it will be twice as fast
again and the next doubling will take only half a year. The next will
take only 3 months, the next six weeks, ... The geometric series
converges on T plus four years. Towards the end of that time, software
at least as smart as humans and enormously faster exists, and it
outcompetes humans. As Homo erectus gave way to H. neanderthalensis,
and H. neanderthalensis gave way to H. sapiens, H. sapiens will then
give way to H. cyberneticus. I leave whether that constitutes the end
of the world or not, and whether H. cyberneticus replacing us is like
our kids one day replacing us, or not, to philosophers to decide.
On 16 maio, 02:10, Series Expansion <·······@gmail.com> wrote:
> On May 15, 6:25 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > Why would we do that? That would mean shooting in one's foot. Nobody
> > would do that.
>
> Apparently, gugamilare would.
Stop saying that already! I wouldn't! What I wrote was just
misinterpreted, 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! 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.
Sorry to make this personal, but you really look like a stubborn 6
years old kid on your argumentation because you don't have a CLUE
about how Lisp works. 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!
On May 16, 2:22 pm, gugamilare <··········@gmail.com> wrote:
> On 16 maio, 02:10, Series Expansion <·······@gmail.com> wrote:
>
> > On May 15, 6:25 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > > Why would we do that? That would mean shooting in one's foot. Nobody
> > > would do that.
>
> > Apparently, gugamilare would.
>
> 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 wrote:
> I'm not interested in getting into an insult-hurling contest, sorry.
Liar.
> You'll have to find someone else to participate in that sort of
> silliness.
Yet you keep hurling insults, hypocrite.
> You keep posting anti-Java rants into comp.lang.java.programmer, you
You keep posting anti-everything rants, you psycho.
> 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
And I question your sanity, "Series".
> rationally suggested that macros, CLOS, and some other particular
> things have their downsides, but I have not "ranted".
You've done nothing but rant, you liar.
--
Lew
On May 17, 1:27 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > I'm not interested in getting into an insult-hurling contest, sorry.
>
> Liar.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > You'll have to find someone else to participate in that sort of
> > silliness.
>
> Yet you keep hurling insults, hypocrite.
No, you do. I've hurled approximately three at this point --
"dipshit", then "fuckwad", and then "liar". You've hurled how many?
About three hundred? And counting.
Furthermore, those hundreds of tiresome personal attacks do not
constitute rational arguments in favor of either Lisp or Java, "Lew".
> > You keep posting anti-Java rants into comp.lang.java.programmer, you
>
> You keep posting anti-everything rants, you psycho.
You are the only one here who seems to be a) anti-everything and b)
ranting. To support a), I observe that you have flamed both pro-Java
and pro-Lisp people. To support b), I note the tone of your posts and
their low ratio of argumentation to personal attacks and other such
nonsense.
I, on the other hand, have clearly promoted Java, Eclipse, and
NetBeans. The Lispers have promoted Lisp and a few have promoted
emacs. None of them, nor I, therefore seem to be "anti-everything".
Most of them have at least a few civil posts that attempt to make
their case for Lisp using some semblance of reason, and the vast
majority of my posts are reasoned arguments from my side. Almost none
of mine and few of theirs qualify as rants. Certainly the proportion
of their posts that qualify as rants doesn't even approach the
proportion of your posts that qualify as rants.
> > 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
>
> And I question your sanity, "Series".
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > rationally suggested that macros, CLOS, and some other particular
> > things have their downsides, but I have not "ranted".
>
> You've done nothing but rant, you liar.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
As I have already explained in more detail above, I have in fact
ranted very little, posting mainly cogent, calm, and reasonable
arguments supporting my side.
The one person in this thread who clearly has gone off the deep end
calls himself "Lew".
On 15 May, 22:40, Series Expansion <·······@gmail.com> wrote:
> On May 15, 3:52 pm, gugamilare <··········@gmail.com> wrote:
>
> > Just like a function can have bugs. Or do you write bugless functions?
> > Tell me the secret then.
>
> Did you miss the bit about tight coupling making it harder to find the
> bugs?
It's not clear to me what you mean by tight coupling or how
it would make it harder to find bugs.
> > By using macros the bug will be in one single place, so you can easily
> > change it. If you write the same code a hundred times and realize that
> > it is wrong, you will have to change the one hundred places where you
> > wrote that same thing.
>
> If your editor doesn't support search and replace, I suggest you
> search for a new one to replace it. :)
So in NetBeans you can specify a multi-line region of code where
perhaps the first or last lines of the code you want to change
do not occupy the whole line and then replace it with something
else ? It's quite good if you can do this but it's still less
convenient than macros.
> > Macros are not a source of headaches in CL because they are most times
> > as simple as a normal function. And you can always expand the code
> > directly from the source (by hitting a small sequence of keystrokes)
> > if you thing it has a bug somewhere.
>
> And now you've replaced a bit of your code with the expanded version.
> Later you'll change the macro for whatever reason, but at this one
> spot the change won't be applied since the macro call was replaced
> with its expansion in your editor at that spot. That copy now gets out
> of synch with the rest of the code.
As others have pointed out it's not clear here what gugamilare
meant. Perhaps he meant that you expand the macro , see why it
doesn't work at that specific place in the code , modify the
macro code and then restore the macro call at the place in the
code where you did the expansion. But let's say instead that you
decide that the macro doesn't work quite right at a specific
place where you originally used it so you have to write the code
explicitly or write another macro for that particular place or
even write a function for that particular place. So yes that
place in the code requires from then on "special treatment", it
won't be affected when you change the macro code.
But once again the exact same scenario can happen if you only
use functions. Say you use foo() in 50 different places in your
code but on testing you find that it doesn't achieve the desired
result in one place. So you eliminate the call to foo() at that
particular spot and replace it with something else. Obviously
if later on you change the foo() code it won't affect that
particular place. So why is it more dangerous with macros?
< Snip comments about IDEs >
> The irony being that that was basically the criticism you leveled at
> Java and its frequent need for boilerplate code: if I make 100 copies
> and later need to change something I have to track them all down. You
> may actually have it worse:
> 1. You write a macro.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 2. At one point, something goes wrong so you hit a "small sequence of
> keystrokes" to do an in-place replacement of a call to that macro
> with its expansion.
> 3. You fix the bug in the macro, whatever it was, but don't change
> that other code back into a macro call.
> 4. Later, you make a change to the macro.
> 5. Because you didn't copy-paste that code all over the place, you
> think you DON'T have to go track down copies and make sure
> they're all in synch. As a result, the expanded copy produced
> in step 2 doesn't end up reflecting the change.
> 6. Now you've got code that's getting out of synch with other code.
And as I pointed out above the exact same thing can happen with
functions. An IDE which would help with the issue would work
just as well with macros. Now if you want to make the argument
that there are better IDEs available for Java than for Lisp that
may be true but I'm only commenting on whether Lisp macros are
inherently more dangerous than other programming constructs.
> > I really don't think this is the case with CL macros.
>
> I don't see how it can fail to be. Obviously the code at the macro
> call site intimately depends on the macro's innards -- for example, if
> one input to the macro is an expression with side-effects, the number
> of times the side-effects happen and the order in which side-effects
> of different inputs happen will depend heavily on the exact macro
> code. So certainly code that calls the macro will break if the macro
> implementation (not just its signature) changes.
And code which calls a function will break if the function
implementation is not correct. I'm not sure what you mean by
signature.
> The reverse is also
> true: if the macro takes the inputs apart with car and cdr to
> transform them in some way, its correctness will depend on the inputs
> having the correct structure.
Even if a macro had to use car and cdr to take apart its
argument it could check that the argument has the correct
structure and if it didn't issue an error. But Common Lisp
macros do not have to use such lowly means. Consider the
following definition:
(defmacro m (a (b c) (d e (f g)))
`(list ,a ,b ,c ,d ,e ,f ,g))
What the macro does is trivial, it just prints its arguments but
the point is to show how the definition of the macro can specify
the structure of its arguments. If I call the macro like
(m 1 2 3 4 5 6 7)
or
(m 1 (2 3) (3 4 5 6))
I will get an error message. I have to call it like
(m 1 (2 3) (3 4 (5 6)))
in which case variable a will be bound to 1, b to 2, etc. So
the Lisp compiler automatically checks that the arguments passed
to the macro have the right structure and binds each variable
appearing in the macro definition to the corresponding part of
the arguments given to the macro.
> So, the macro definition and every call site of the macro will be
> tightly coupled.
>
> A Java method or C function definition is more loosely coupled. Since
> it's just values of some sort passed as parameters, rather than code,
> the order of side-effects of the arguments is well-defined: each
> happens once, in left-to-right-order, at the call site and just before
> the call itself.
Actually if in C you do foo(expr1 , expr2) the order in which
expr1 and expr2 will be evaluated is unspecified. In any case
the order of evaluation is precisely specified in Lisp. The
appropriate parts of the code passed as an argument to the macro
will be assigned to the macro variables and what happens from
then on depends on what the macro does. It can decide which code
to evaluate and in which order.
> With pass-by-value (Java primitives and non-pointer C
> parameters) the function also won't alter the passed-in data. With
> pass-by-reference (Java objects with mutable state, pointers, C++
> references) the function can alter the passed-in data but its
> implementation still won't influence side effects and order of
> evaluation of the argument expressions.
But it will influence the order of evaluation of all the expressions
that
appear inside the function. In other words writing
a = expr1;
b = expr2;
may have different side effects than writing
b = expr2;
a = expr1;
Now let's imagine that C had a special syntax which allowed you
to decide in which order the arguments of a function get
evaluated. So in a call like foo(expr1 , expr2) you could use
the special syntax to decide if expr1 gets evaluated before
expr2 or vice versa. What makes you think that this would
present any greater programming problems or potential for bugs
than what C actually does offer? It seems to me that order of
evaluation is a central aspect of (non-functional) programming
so I don't see how having one more place where you can influence
order of evaluation makes such a great difference.
> Macros may be able to do powerful things, but with that power comes
> the greater potential for problems. (Others have mentioned variable
> capture, so I won't go into detail about that here.)
Has someone mentioned variable capture in this thread? I missed
this. Anyway there is a standard and easy way to avoid this
(unless of course you want variable capture to happen and on
some occasions you do) which is explained in chapter 8 of
``Practical Common Lisp''.
< Snip comments about modifying running images >
--
He could sometimes be caustic in his reminiscences of the
South during that era, once writing that "even in the 'Bible
Belt' the Bible is a relatively unknown book -- sacred, of
course, but quite unfamiliar."
Refers to theologian Langdon Gilkey Dies
On May 16, 3:44 am, Spiros Bousbouras <······@gmail.com> wrote:
> On 15 May, 22:40, Series Expansion <·······@gmail.com> wrote:
> > On May 15, 3:52 pm, gugamilare <··········@gmail.com> wrote:
>
> > > Just like a function can have bugs. Or do you write bugless functions?
> > > Tell me the secret then.
>
> > Did you miss the bit about tight coupling making it harder to find the
> > bugs?
>
> It's not clear to me what you mean by tight coupling or how
> it would make it harder to find bugs.
Then you're not qualified to give practical advice about software
development until you've learned more about these things.
> > > If you write the same code a hundred times and realize that
> > > it is wrong, you will have to change the one hundred places where you
> > > wrote that same thing.
>
> > If your editor doesn't support search and replace, I suggest you
> > search for a new one to replace it. :)
>
> So in NetBeans you can specify a multi-line region of code where
> perhaps the first or last lines of the code you want to change
> do not occupy the whole line and then replace it with something
> else ?
In any modern text editor one should be able to do that much. But
gugamilare seemed to be thinking that it's really laborious to make
the same change to the same string in 100 different places. With
reasonably modern tools, that is not the case.
> > > Macros are not a source of headaches in CL because they are most times
> > > as simple as a normal function. And you can always expand the code
> > > directly from the source (by hitting a small sequence of keystrokes)
> > > if you thing it has a bug somewhere.
>
> > And now you've replaced a bit of your code with the expanded version.
> > Later you'll change the macro for whatever reason, but at this one
> > spot the change won't be applied since the macro call was replaced
> > with its expansion in your editor at that spot. That copy now gets out
> > of synch with the rest of the code.
>
> As others have pointed out it's not clear here what gugamilare
> meant. Perhaps he meant that you expand the macro , see why it
> doesn't work at that specific place in the code , modify the
> macro code and then restore the macro call at the place in the
> code where you did the expansion.
That's more or less what he said, yes, though the obvious expectation
of an experienced developer is that sooner or later, the final "undo"
step WILL get forgotten by someone, somewhere.
> But once again the exact same scenario can happen if you only
> use functions. Say you use foo() in 50 different places in your
> code but on testing you find that it doesn't achieve the desired
> result in one place. So you eliminate the call to foo() at that
> particular spot and replace it with something else. Obviously
> if later on you change the foo() code it won't affect that
> particular place.
Or better, generalize foo() with a new parameter that parametrizes the
way in which the uses differ.
> So why is it more dangerous with macros?
Everything's more dangerous with macros.
> > The irony being that that was basically the criticism you leveled at
> > Java and its frequent need for boilerplate code: if I make 100 copies
> > and later need to change something I have to track them all down. You
> > may actually have it worse:
> > 1. You write a macro.
> > 2. At one point, something goes wrong so you hit a "small sequence of
> > keystrokes" to do an in-place replacement of a call to that macro
> > with its expansion.
> > 3. You fix the bug in the macro, whatever it was, but don't change
> > that other code back into a macro call.
> > 4. Later, you make a change to the macro.
> > 5. Because you didn't copy-paste that code all over the place, you
> > think you DON'T have to go track down copies and make sure
> > they're all in synch. As a result, the expanded copy produced
> > in step 2 doesn't end up reflecting the change.
> > 6. Now you've got code that's getting out of synch with other code.
>
> And as I pointed out above the exact same thing can happen with
> functions.
Except that nobody does in-editor inlining of function calls. Not even
as an optimization, these days.
You don't have to, because if the function does the wrong thing the
error's in the function and the function's easy to locate, and if it
doesn't, nothing wacky will be happening. In particular, the
evaluation of the function's arguments is not dependent on the
implementation of the function.
With a macro, on the other hand, expressions in the arguments may end
up evaluated zero or more times in any sequence rather than once each
in left to right order, and changes in the macro's implementation may
change this. If some of the arguments at a particular call site are
expressions with side-effects, the semantics of that code will
sensitively depend on the details of the macro's innards. Furthermore
the macro might be capturing local variables or otherwise interacting
with its environment in ways that functions never do. If a local
variable name happens to clash with a name used internally by the
macro, kaboom! And then you have to do the kludgy expand-in-place
thing to find out what's going wrong, and if you leave it like that,
you've fixed one kaboom but you've got another ticking bomb in exactly
the same spot.
Consider local-variable capture.
Functions: safe, because the function's own local variables are a
separate scope.
Closures: safe; though the closure can alter variables in a larger
scope, the closure's code is lexically contained in that
larger scope, and any unintended interactions are easy to
spot and fix. If the same closure may be evaluated at
many locations, it still can't muck with those locations'
local variables.
Macros: Unsafe. Suppose the macro names some internal variable foo.
Any code that calls the macro and has a local variable named
foo will have problems, and the problems depend on the
innards of the macro. If the macro is changed to make no
outward modification in its normal behavior, but with
internal variable renamings, it might suddenly cause bugs at
call sites that formerly worked. If the macro and the call
site are in separately-managed pieces of code, rather than
one person's code, this is especially problematical.
Now consider side effects:
Functions: safe. Function argument expressions are evaluated left
to right and then assigned to the function's formal
parameters, then the function body is run. Changes to the
number of times and sequence of use of the formal
parameters within the function body have no effect at the
call site, given the function's own return value and side
effects don't change.
Closures: safe. Closures are exactly like functions in this regard,
and though closures can have side effects locally in the
enclosing code, so can the contents of an if branch or a
loop body (and some languages implement these with
closures!).
Macros: Unsafe. Macro arguments are evaluated as they are
encountered in expanding the macro and then executing the
expanded code, so if parameters a, b, and c are used in the
sequence c, a, a, the expressions at the call site are
evaluated in the same order -- so the third argument
expression is evaluated, then the first is evaluated twice,
while the second is never evaluated. If these have side
effects, there's a problem. Furthermore, side effects of
the macro body and of the arguments can be interspersed
arbitrarily. Worse, changes to the macro's implementation
that nominally don't change its semantics can and will
rearrange these side effects.
Worse still, it's hard to fix these problems with macros.
Variable capture: this one is easy to avoid, though the recipe for
avoiding it is easy to forget. In C macros intended to be statements
rather than expressions, you can use a brace-delimited block inside
the macro with its own local variables, for example:
#define FOO(x) {int t = (x); foo1(t); foo2(t);}
will not clobber a local variable named "t" at a call-site, but will
without the braces. Lisp may have an equivalent way of creating a more-
local scope to brace blocks that can be exploited similarly, and if it
does it can probably be used in expression-equivalent macros and not
just statement-equivalent macros, but forgetting to do it will be no
easier to avoid.
Barring a way to create a local scope block inside the macro, the only
way out seems to be to use a global variable. Ugh.
Order of side effects: this one is harder. Again in statement-
equivalent C macros you can use code like the above; in that code,
side effects of x will occur only once and before any side effects of
the macro code, since "int t = x;" has no side effects.
#define FOO(x) foo1(x); foo2(x)
would have run into this problem however, with side effects of x
happening twice, once before and once after the side effects (if any)
of foo1.
Lisp macros surely allow a way out analogous to "t = x;" at the cost
of causing variable capture. As noted above, they *may* provide some
way to prevent variable capture. Both things will be easy to forget,
and the problems caused by macros that forget one or both will be
difficult to diagnose and fix.
If the only way to avoid variable capture is to use a global variable,
though, ugh.
Even if not, there's still yet another problem: consider calling the
following macro:
#define BAR(x,y) {int s = (x), t = (y); foo1(s); foo2(s); foo1(t); foo2
(t);}
in this context:
int s = 17;
int a = 34;
BAR(a,s);
This expands to
int s = 17;
int a = 34;
{int s = (a), t = (s); foo1(s); foo2(s); foo1(t); foo2(t);};
Uh-oh! The intent was surely to invoke
foo1(34); foo2(34); foo1(17); foo2(17);
but the effect in this case will be to invoke
foo1(34); foo2(34); foo1(34); foo2(34);
because the internal local variable s hides the s that's local to the
call site, and it was a parameter. Change the names from a and s to a
and b and the problem goes away, so the problem depends on the names
of the variables near the call site. Arrrrgh!!
Macros in pure-functional languages are only half as evil, since order
of side effects are not a concern, but the problems with variable
capture remain, and as can be seen above simply cannot be made to go
away entirely, except by using global variables with all the problems
that THOSE entail. I doubt most pure functional languages will allow
that dubious escape hatch either, so using one to evade the order-of-
side-effects problem actually makes the variable capture problem
marginally worse.
Only marginally. Once you resort to global variables, you give up
reentrancy for the affected macro, you give up thread-safety or add
some lock contention at every site the macro gets used, and you create
potential name pollution and side effect issues. There's a reason
they're considered harmful.
Macros: the "goto" of the Lisp family of languages.
> Now if you want to make the argument
> that there are better IDEs available for Java than for Lisp that
> may be true but I'm only commenting on whether Lisp macros are
> inherently more dangerous than other programming constructs.
So am I, in the extensive discussion immediately above.
> > I don't see how it can fail to be. Obviously the code at the macro
> > call site intimately depends on the macro's innards -- for example, if
> > one input to the macro is an expression with side-effects, the number
> > of times the side-effects happen and the order in which side-effects
> > of different inputs happen will depend heavily on the exact macro
> > code. So certainly code that calls the macro will break if the macro
> > implementation (not just its signature) changes.
>
> And code which calls a function will break if the function
> implementation is not correct.
It won't generally be the case, though, that a change to the
function's innards that doesn't change its (nominal) semantics will
break things.
As already explained to gugamilare, if a function takes a and b and
returns the sum of a and 2*b, it doesn't tend to matter (except maybe
for obscure overflow or fp roundoff related cases, and maybe
performance-wise) whether it's implemented as a + b + b or a + 2*b. It
also doesn't matter if the compiler optimizes both cases to a + (b >>
1).
If it's a macro instead, all hell breaks loose. The a + b + b version
causes the expression that supplies b to be executed twice, and
therefore any side effects of that expression to happen twice. For
example, if it's x++, x gets incremented twice instead of once because
of an *implementation detail*. Worse, if a coder expects x to be
double-incremented and accounts for that, then it's recompiled with
aggressive optimizations that replace x + x with x >> 1, the double-
increment goes away and you've got problems again.
Ultimately, the problem is that macros lack encapsulation while
functions don't. The caller of a function doesn't care what names are
used inside a function, nor does the function care what names are used
at any of its call sites. They're not nested scopes, but rather sister
scopes; neither sees the other's locals. There's an encapsulation
barrier of sorts between a function and all of its call sites; except
for intentional side effects, all influences go in through the
argument expressions and out through the return value.
Another form of encapsulation is that the call site code before the
function call runs, then each argument expression runs in left-to-
right order, then the function runs, and then the call site code after
the function call runs. There's a neat separation into blocks: all the
call site code before the function call, then the function call, then
all the call site code after. The timing, number of evaluations, and
sequence of evaluations of call site code depend solely on the
arrangement of the call site code and not one whit on the arrangement
of the code in the function body.
Neither of these holds any more with macros. The argument expressions
and macro code are chopped up, mixed, and evaluated in a sequence
dependent on the macro body. Variables in the macro can either clobber
or hide local variables at the call site, and will do so depending on
the names; changing the names in the macro or at the call site may
alter behavior drastically. Macros lack encapsulation.
Closures also lack encapsulation from their construction site, but the
problem is absent there because these are lexically nested scopes; the
bits of code that are not encapsulation-separated are also physically
proximate in the code base. It's no more of a problem than loop bodies
being able to affect or hide variables in the enclosing function body.
Macros, by contrast, have these same effects *nonlocally*.
If a closure is like a loop body in terms of its effects on code
readability, modularity, and coupling, then a macro is more like a
goto in these terms.
And all of this is *ignoring* the possibility of a macro quietly
replacing a function and altering its semantics, an issue that I
discuss elsethread.
> > The reverse is also
> > true: if the macro takes the inputs apart with car and cdr to
> > transform them in some way, its correctness will depend on the inputs
> > having the correct structure.
>
> Even if a macro had to use car and cdr to take apart its
> argument it could check that the argument has the correct
> structure and if it didn't issue an error.
Ah, code that compiles but yields mystery runtime errors, always a fun
way to begin the day.
> in which case variable a will be bound to 1, b to 2, etc. So
> the Lisp compiler automatically checks that the arguments passed
> to the macro have the right structure
What if the argument is a list cons'd at runtime, whose structure the
compiler therefore cannot know in advance? The structure could, say,
depend on the results of a very complex computation.
> Actually if in C you do foo(expr1 , expr2) the order in which
> expr1 and expr2 will be evaluated is unspecified.
In practice it tends to be left-to-right. It always is in Java. It is
always the case, in either language, that their side effects will all
occur exactly once.
> In any case the order of evaluation is precisely specified in Lisp.
I'm sure it is. The problem is that the sequence depends on the
macro's internal guts and not just on the structure of the code at the
call site. That's tight coupling.
> > With pass-by-value (Java primitives and non-pointer C
> > parameters) the function also won't alter the passed-in data. With
> > pass-by-reference (Java objects with mutable state, pointers, C++
> > references) the function can alter the passed-in data but its
> > implementation still won't influence side effects and order of
> > evaluation of the argument expressions.
>
> But it will influence the order of evaluation of all the expressions
> that appear inside the function.
That's not a problem. I don't mind it if the structure of the code in
foo.java affects the order of evaluation of expressions in foo.java. I
just don't want it affecting the order in bar.java, and thankfully,
unless bar == foo or foo.java is actually Sun's Compiler.java, it
won't.
Not so with Lisp.
> a = expr1;
> b = expr2;
>
> may have different side effects than writing
>
> b = expr2;
> a = expr1;
That's fine. The problem is when expr1 and expr2 in
foo(expr1,expr2)
have different side effects than in
foo(expr1,expr2)
because someone changed foo a while ago, rather than because it was
changed to foo(expr2,expr1).
Now the evaluation of code HERE is changed by code over THERE and not
just by code HERE. Do you see what I'm getting at? Subtle problems
might show up here because of changes elsewhere that wouldn't have
changed the semantics of foo IF foo were a normal function, or IF
expr1 and expr2 were free of side-effects.
I don't understand why you're still not getting it. It's gotta be as
plain as the nose on your face by now that macros lack a form of
encapsulation that functions have, and the implementation details of a
macro are necessarily tightly coupled to the code at every call site,
whereas the coupling is much looser between functions and their call
sites.
I've thoroughly torpedoed your repeated claim that macros are "just as
safe as functions". It's taking on water and heading for crush depth.
Abandon ship already!
> Now let's imagine that C had a special syntax which allowed you
> to decide in which order the arguments of a function get
> evaluated. So in a call like foo(expr1 , expr2) you could use
> the special syntax to decide if expr1 gets evaluated before
> expr2 or vice versa. What makes you think that this would
> present any greater programming problems or potential for bugs
> than what C actually does offer?
It wouldn't if it were syntax used at the call site. It would if it
were syntax used inside foo's function body in some distant chunk of
code you might not even be allowed to modify, or even have in source
form at all.
> It seems to me that order of
> evaluation is a central aspect of (non-functional) programming
> so I don't see how having one more place where you can influence
> order of evaluation makes such a great difference.
The problem is that it influences order of evaluation not locally but
through "spooky action at a distance". In quantum theory, we've
learned to accept that as unavoidable, but keep it the hell away from
my code!
> > Macros may be able to do powerful things, but with that power comes
> > the greater potential for problems. (Others have mentioned variable
> > capture, so I won't go into detail about that here.)
>
> Has someone mentioned variable capture in this thread?
It was mentioned, but that was about it. Until now. Now I have gone
into some detail about it, since nobody else was bothering to go into
any detail about it and since it is another powerful argument against
your "macros are no biggie, really!" nonsense.
> Anyway there is a standard and easy way to avoid this
I'm sure there is, but it will have its own problems. I noted two
escape hatches above, each with problems:
1. Create a nested scope and use local variables. Now you only get
trouble if a call site uses a variable of the same name in one of
the arguments to the call, instead of all the time. But you still
can't avoid it entirely. Or:
2. Use global variables, preferably in combination with namespaces.
Of course, all of us here already know why global variables are
only slightly less evil than goto. Even with namespaces.
Series Expansion wrote:
> Then you're not qualified to give practical advice about software
> development until you've learned more about these things.
You're not qualified for a job whose hardest task is asking, "Would you like
fries with that?"
--
Lew
On May 17, 1:29 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > Then you're not qualified to give practical advice about software
> > development until you've learned more about these things.
>
> You're not qualified for a job whose hardest task is asking, "Would you like
> fries with that?"
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
On 2009-05-15, Series Expansion <·······@gmail.com> wrote:
> On May 15, 5:21 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> "eric-and-jane-smith" <·······@nospam.com> writes:
>> > ····@informatimago.com (Pascal J. Bourguignon) wrote in
>> >···················@galatea.local:
>>
>> >> Lisp macros are just a much simplier and much more powerful to archive
>> >> the same results much faster.
>>
>> > It's hard to make the power of CL macros clear to non-Lispers. They think
>> > in terms of the macros of other programming languages, and have no idea
>> > what CL macros are. From their point of view, we seem to be telling them
>> > we want to use macros as a klugey substitute for C++ templates, or for the
>> > Java type system, or whatever.
>>
>> > This kind of debate tends to go in circles till it degenerates, because the
>> > parties aren't really communicating, because the same words mean different
>> > things to them.
>>
>> Ok, then let me summarize lisp macros as being hooks in the lisp compiler.
>>
>> Imagine what you could do if you could modify your compiler on the fly:
>
> - you could blow things up in completely new and exotic ways
The ability to define types or overload operators is also on on-the-fly
modification to the compiler.
> - you could generate bugs it would take a crack team of comp.sci
> Ph.D.s to track down
>
> - you could find previous/other programs no longer compiling, or
> worse, compiling but no longer working correctly once recompiled
That's a retarded statement which shows ignorance of what is going on.
> The potential here is for foot-bullets express-delivered by a fully-
The potential here is for you to do some RTFM before looking like a moron.
Series Expansion <·······@gmail.com> writes:
> On May 15, 5:21�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> "eric-and-jane-smith" <·······@nospam.com> writes:
>> > ····@informatimago.com (Pascal J. Bourguignon) wrote in
>> >···················@galatea.local:
>>
>> >> Lisp macros are just a much simplier and much more powerful to archive
>> >> the same results much faster.
>>
>> > It's hard to make the power of CL macros clear to non-Lispers. �They think
>> > in terms of the macros of other programming languages, and have no idea
>> > what CL macros are. �From their point of view, we seem to be telling them
>> > we want to use macros as a klugey substitute for C++ templates, or for the
>> > Java type system, or whatever.
>>
>> > This kind of debate tends to go in circles till it degenerates, because the
>> > parties aren't really communicating, because the same words mean different
>> > things to them.
>>
>> Ok, then let me summarize lisp macros as being hooks in the lisp compiler.
>>
>> Imagine what you could do if you could modify your compiler on the fly:
>
> - you could blow things up in completely new and exotic ways
>
> - you could generate bugs it would take a crack team of comp.sci
> Ph.D.s to track down
>
> - you could find previous/other programs no longer compiling, or
> worse, compiling but no longer working correctly once recompiled
Strangely enough, this doesn't occurs in Lisp.
Are lisp programmers super geniuses?
Or are they just not imaginative enough to shoot themselves in the foot?
By the way, why would any body want to shoot himself in the foot?
No, that's silly, we just don't do that.
Yes, you could blow things up, but if you've got more than three
neurons, you won't.
Yes, you could create bugs, but it's easier to avoid them.
Yes, you could render your language incompatible. But lisp
programmers don't have to implement a whole new language to be able to
incorporate their favorite language feature, so they don't (contrarily
to the Perl, Java, Python, Ruby, etc, language creators), and
consequently, you can still run programs that are 50 years old on
modern lisp system.
> The potential here is for foot-bullets express-delivered by a fully-
> automatic assault rifle instead of the revolver Java gives you, C's
> shotgun, or C++'s, semiauto pistol.
Well, perhaps Lisp programmers are the type of guys to ask what the
red button is used for before pressing it... In anycase, we don't
observe holes in lisp programmers' feet.
> It's not a surprise that it's heavily used in comp.sci research but
> you don't see many desktop applications written in Lisp, then.
>
> It has its niche. But I see problems with its ability to achieve
> widespread use for more ordinary and common-place applications.
That's strange. Are you sure you are looking at lisp? When I do, I
see solutions, not problems.
--
__Pascal Bourguignon__
On May 15, 2:53 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > - you could blow things up in completely new and exotic ways
>
> > - you could generate bugs it would take a crack team of comp.sci
> > Ph.D.s to track down
>
> > - you could find previous/other programs no longer compiling, or
> > worse, compiling but no longer working correctly once recompiled
>
> Strangely enough, this doesn't occurs in Lisp.
> Are lisp programmers super geniuses?
> Or are they just not imaginative enough to shoot themselves in the foot?
> By the way, why would any body want to shoot himself in the foot?
> No, that's silly, we just don't do that.
Okay. So your thesis is that lisp programmers are perfect. Maybe not
super geniuses, but perfect. They do not have accidents. They do not
make mistakes. They never shoot themselves in the foot.
OK, got that.
I think we're done here. :)
> consequently, you can still run programs that are 50 years old on
> modern lisp system.
OK, not quite done. This gem absolutely has to be polished and brought
into the light for all to see.
Yes, folks, Pascal is seriously suggesting that it might be a PLUS
that we can run fifty-year-old code. Code with Y2K bugs, no GUI,
cryptic diagnostic messages, and rudimentary teletype output. Code
that will probably make the operating system complain that "Windows
cannot find a compatible punched-card reader. Plug one into a USB port
and click OK to continue." Good luck with that.
In practice, code tends to be obsolete even quicker than hardware
does. Library code not so much, but application code and business
logic, definitely. Fifty-year-old code won't know about your mouse or
graphics hardware. It won't know about curses. It probably won't even
know about line-oriented interaction from the dark ages. It's probably
got a batch-processing interface. Say, anyone got an emulator for a
DEC reel-to-reel tape drive from the sixties?
Business logic suffers worse than the user interface, if anything.
Fifty-year-old tax software will get your taxes wrong. Fifty-year-old
accounting and legal software won't know about Sarbanes-Oxley. Fifty-
year-old patent-filing software thinks universities still can't patent
shit. Fifty-year-old software certainly can't provide cloud-based
fulfillment services to rival Amazon's S3 offerings. Try finding a
fifty-year-old media player that can parse your mp3s, or a fifty-year-
old compiler that groks Java for that matter. I'm not sure fifty-year-
old code can even grok TCP/IP; certainly not NNTP, HTTP, or HTML. So
much for modern network integration.
OK, so it can run fifty-year-old code. Now tell me why you'd want to.
> > It's not a surprise that it's heavily used in comp.sci research but
> > you don't see many desktop applications written in Lisp, then.
>
> > It has its niche. But I see problems with its ability to achieve
> > widespread use for more ordinary and common-place applications.
>
> That's strange. Are you sure you are looking at lisp? When I do, I
> see solutions, not problems.
Solutions, perhaps, but not apparently to typical desktop users'
problems. Or else where are the desktop applications that are coded in
Lisp?
(As an added zinger: Amazon's server-side stuff did once include quite
a lot of Lisp, though obviously not fifty-year-old Lisp. Then they
migrated to Java. I wonder why?)
Series Expansion <·······@gmail.com> writes:
> On May 15, 2:53�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > - you could blow things up in completely new and exotic ways
>>
>> > - you could generate bugs it would take a crack team of comp.sci
>> > � Ph.D.s to track down
>>
>> > - you could find previous/other programs no longer compiling, or
>> > � worse, compiling but no longer working correctly once recompiled
>> consequently, you can still run programs that are 50 years old on
>> modern lisp system.
> Yes, folks, Pascal is seriously suggesting that it might be a PLUS
> that we can run fifty-year-old code.
Well not only I'm serriously suggesting that, I proved it.
http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html
But what's more I'm even expecting from my fellow humans to be able to
do one step of inference during a discussion. But perhaps I
overestimate you.
What do you think, if a system is able to run code that's fifty years
old, will it able to run the previous programs or no?
--
__Pascal Bourguignon__
On May 15, 6:34 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 2:53 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> Series Expansion <·······@gmail.com> writes:
> >> > - you could blow things up in completely new and exotic ways
>
> >> > - you could generate bugs it would take a crack team of comp.sci
> >> > Ph.D.s to track down
>
> >> > - you could find previous/other programs no longer compiling, or
> >> > worse, compiling but no longer working correctly once recompiled
> >> consequently, you can still run programs that are 50 years old on
> >> modern lisp system.
> > Yes, folks, Pascal is seriously suggesting that it might be a PLUS
> > that we can run fifty-year-old code.
>
> Well not only I'm serriously suggesting that, I proved it.
OK, technically it can't actually NOT be a plus. But it's gotta be a
very, very SMALL plus. And the cost in not-very-modernness ...
Not a tradeoff I'd likely make.
···@informatimago.com (Pascal J. Bourguignon) wrote in
···················@pbourguignon.anevia.com:
> Ok, then let me summarize lisp macros as being hooks in the lisp
> compiler.
>
>
> Imagine what you could do if you could modify your compiler on the
> fly:
>
> - you could change your programming language, to specialize it for
> your current problem,
>
> - you could implement more sophisticated type or semantic checking,
>
> - you could implement higher level code generation strategies
> (eg. instead of just generating machine code from arithmetic
> operations or message sending, you could generate programs from a
> declarative description of your problem),
>
> - etc.
A lot of people might still not get it, even after understanding some of
the kinds of things that can be done with them. They might have bad
memories of trying to use the macros of other programming languages, and
making a big mess with them, such that their programs gradually became
hard to read and maintain. Their attitude might be that the more you can
do with them, the bigger a mess you can make with them.
Macros in other programming languages often seem to obfuscate the code as
much as they improve it, such that there may be little or no net gain.
But CL macros can make the code orders of magnitude clearer, easier to
read, easier to work with, and less error prone. There is a powerful
synergy between the different advantages of CL macros, such that knowing
them as a list of advantages is not enough to understand their real
power.
People with a lot of experience in a lot of other programming languages
are likely to think the concept of macros is simple and universal. Their
experience tells them they're like a two-edge sword, to be careful with,
and to not expect miracles from. The idea that in CL it would not be
unusual to write most of a 20-line function as one big macro call, with
other macro calls nested in that one, is likely to seem bizarre to them,
and give them even more reason to avoid CL.
And that's just one of many reasons why it's hard to advocate for CL to
people who have little or no experience with it. No matter what we say,
we sound like raving maniacs, till they find out for themselves, by
getting real experience with CL, and not just testing the waters by
writing some simple code that only uses a small fraction of the features
of the language.
"eric-and-jane-smith" <·······@nospam.com> writes:
> Macros in other programming languages often seem to obfuscate the code as
> much as they improve it, such that there may be little or no net gain.
> But CL macros can make the code orders of magnitude clearer, easier to
> read, easier to work with, and less error prone. There is a powerful
> synergy between the different advantages of CL macros, such that knowing
> them as a list of advantages is not enough to understand their real
> power.
Yes, a good point.
I've lately decided that I really like the example of WITH-OPEN-FILE as
an example of a nice Lisp macro. OK, it's already in the language, but
the important point is that it would be something easy to add if it
WASN'T in the language. This exposition can proceed by looking at the
problem it was put in to solve, and comparing it to two Java solutions.
Problem: When you open a file, you have to remember to close it, even if
the code using the file happens to throw an exception.
OK. The standard Java solution would be to use "try ... finally":
OutputStream out = null; // Needs definition outside try block.
try {
out = new FileOutputStream(filename);
// do stuff
} finally {
if (out != null) {
try {
out.close();
} catch (IOException ioe) {
// Do something like log this.
}
}
}
So, this is just a bit cumbersome, because you have to remember to
declare the variables in the correct place, remember to put in the
finally block, with appropriate safety checks. Note that because the
close() method can also throw an exception, you have to wrap it in its
own exception handling block. That's a lot of infrastructure that you
need to write around the file handling code that you really care about,
namely the "// do stuff" part.
Note in particular, that STATIC TYPING DOES NOTHING to enforce this type
of good programming practice. That's because it isn't a type error, but
an oversight in program strucure. Macros, on the other hand, allow you
to easily capture such good practice.
[Aside: There has of late been a lot of "excitement" about pattern-based
design. This is all well and good, but it is something that,
essentially, Common Lisp has had all along through the judicious use of
macros. In fact, lisp has gone beyond the notion of mere patterns and
instead calls this aspect the process of building a Domain Specific
Language (DSL)]
Now, you can, in fact, write the same thing in Common Lisp, yielding a
program that looks kind of like this:
(let ((out nil))
(unwind-protect
(progn
(setq out (open filename :direction :output))
;; Do stuff
)
(unless (null out)
(close out))))
where we set up the same basic structure. Now, since we nearly always
want to do something like this when we open the file, we would like to
have a safe way to do this that is convenient and gets the details
right. So we take the basic outline of what we want and write a macro
that embodies this particular idiom:
(defmacro with-open-file ((var filename &rest open-options) &body body)
`(let ((,var nil))
(unwind-protect
(progn
(setq ,var (open ,filename ,@open-options))
,@body)
(unless (null ,var)
(close ,var)))))
So now we have a macro that automatically handles the task of opening a
file and remembering to close it. That simplifies our code to the more
perspicacious and correct, because the macro has been carefully
constructed:
(with-open-file (out filename :direction :output)
;; do-stuff
)
This also allows us to concentrate our attention on the actual DO-STUFF
part, which is the variable part of this endeavor and the place where
logic bugs can occur. We don't have to bother ourselves looking at all
of the boilerplate and making sure we got it right, since we've already
gotten the boilerplate parts correct in our macro.
So, how would one go about doing something similar in Java. The real
crux of the matter is that there isn't any facility in the language that
allows you to introduce a new control structure that allows you to
insert your actual program into the middle of some combination of
existing constructs.
As near as I can tell, the method one would need to use involves
encapsulating the program you want to execute inside a (possibly
anonymous) class with a defined "run" interface so that it can be
executed. That would involve something along the lines of
public interface FileProcessor {
public void processFile (OutputStream out);
}
public class ProcessFile {
public static void processOpenFile (String filename, FileProcessor worker) {
OutputStream out = null;
try {
out = new FileOutputStream(filename);
worker.processFile(out);
} finally {
if (out != null) {
try {
out.close();
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
}
}
}
OK. With this infrastructure defined, we can now write code that looks
sort of like this:
ProcessFile.processOpenFile(filename,
new FileProcessor () {
public void processFile(OutputStream out) {
// do stuff
}
});
where we create a new anonymous class instance to encapsulate the body
of the code that we want to execute.
So, it is possible to build up such abstractions in Java, but to my eyes
that looks a lot clunkier and less integrated than the Lisp macro
solution. You see, there isn't any way of introducing new forms into
Java that look like the language itself. So there isn't any way to add
your own control structure construct that looks like
with_open_file (out, filename) {
// do stuff
}
which would be the real equivalent of the Common Lisp macro solution.
So this is a very simple example of what is meant when lisp programmers
talk about using macros to write code that is correct, and a very
simplistic example of how we go about writing DSLs to solve problems, by
removing the superstructure required by the programming language from
sight so we can concentrate on getting the actual business logic right.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 15, 12:31 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> (defmacro with-open-file ((var filename &rest open-options) &body body)
> `(let ((,var nil))
> (unwind-protect
> (progn
> (setq ,var (open ,filename ,@open-options))
> ,@body)
> (unless (null ,var)
> (close ,var)))))
>
>
> (with-open-file (out filename :direction :output)
> ;; do-stuff
> )
The statically-typed language C++ lets you do something equivalent,
thanks to RAII. You create a local variable out that's an output
stream, open it, do stuff with it, and then let the local variable go
out of scope. However that happens (normal or exception) the output
stream's destructor does the job. So there's no need for even two
lines of boilerplate there.
At this point it looks like C++ > Lisp > Java on this score.
> ProcessFile.processOpenFile(filename,
> new FileProcessor () {
> public void processFile(OutputStream out) {
> // do stuff
> }
> });
>
> where we create a new anonymous class instance to encapsulate the body
> of the code that we want to execute.
>
> So, it is possible to build up such abstractions in Java, but to my eyes
> that looks a lot clunkier and less integrated than the Lisp macro
> solution. You see, there isn't any way of introducing new forms into
> Java that look like the language itself. So there isn't any way to add
> your own control structure construct that looks like
>
> with_open_file (out, filename) {
> // do stuff
> }
>
> which would be the real equivalent of the Common Lisp macro solution.
Not yet. There are plans afoot to address this, in Java 7 or (more
likely) Java 8, by adding some sort of syntactic sugar here, perhaps
full-blown closures.
Then it might be C++, Java > Lisp.
Series Expansion <·······@gmail.com> writes:
> Not yet. There are plans afoot to address this, in Java 7 or (more
> likely) Java 8, by adding some sort of syntactic sugar here, perhaps
> full-blown closures.
>
> Then it might be C++, Java > Lisp.
Hmmm. A curious algebra, this one.
Each time a language adopts a featuer from Lisp, it becomes better than
Lisp. As Alice would say, "curiouser and curiouser"
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> Not yet. There are plans afoot to address this, in Java 7 or (more
>> likely) Java 8, by adding some sort of syntactic sugar here, perhaps
>> full-blown closures.
>>
>> Then it might be C++, Java > Lisp.
>
> Hmmm. A curious algebra, this one.
>
> Each time a language adopts a featuer from Lisp, it becomes better than
> Lisp. As Alice would say, "curiouser and curiouser"
Considering only syntactic features? "He is intelligent, but not
experienced. His pattern suggests one-dimensional thinking." With
apologies to Mr. Nimoy. :)
Series Expansion and the other cljp'ers here have been mentioning such
features as ability to keep the code, the IDE/toolchain, and the runtime
environment separate and know what is where and where everything is, use
external version control tools (a biggie in most real-world commercial
development projects, and I include big and widely-used open source
projects in that category as they usually have commercial involvement
and funding somewhere), and have the compiler catch more bugs earlier in
the code-compile-correct-test-debug cycle.
On Fri, 15 May 2009 12:15:59 -0700, Series Expansion wrote:
> On May 15, 12:31 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> So, it is possible to build up such abstractions in Java, but to my
>> eyes that looks a lot clunkier and less integrated than the Lisp macro
>> solution. You see, there isn't any way of introducing new forms into
>> Java that look like the language itself. So there isn't any way to add
>> your own control structure construct that looks like
>>
>> with_open_file (out, filename) {
>> // do stuff
>> }
>>
>> which would be the real equivalent of the Common Lisp macro solution.
>
> Not yet. There are plans afoot to address this, in Java 7 or (more
> likely) Java 8, by adding some sort of syntactic sugar here, perhaps
> full-blown closures.
>
> Then it might be C++, Java > Lisp.
You are just not getting it, are you? Those languages will be
superior to Lisp when _you_ can add constructs like that.
Tamas
On May 15, 3:39 pm, Tamas K Papp <······@gmail.com> wrote:
> On Fri, 15 May 2009 12:15:59 -0700, Series Expansion wrote:
> > On May 15, 12:31 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> >> So, it is possible to build up such abstractions in Java, but to my
> >> eyes that looks a lot clunkier and less integrated than the Lisp macro
> >> solution. You see, there isn't any way of introducing new forms into
> >> Java that look like the language itself. So there isn't any way to add
> >> your own control structure construct that looks like
>
> >> with_open_file (out, filename) {
> >> // do stuff
> >> }
>
> >> which would be the real equivalent of the Common Lisp macro solution.
>
> > Not yet. There are plans afoot to address this, in Java 7 or (more
> > likely) Java 8, by adding some sort of syntactic sugar here, perhaps
> > full-blown closures.
>
> > Then it might be C++, Java > Lisp.
>
> You are just not getting it, are you? Those languages will be
> superior to Lisp when _you_ can add constructs like that.
If _I_ can add constructs like that, my coworker can too, probably
ones that are incompatible with mine, making our attempts to
collaborate blow up in our faces. Then our boss wonders why we're
stuck, and whether the money the company is spending on our salaries
and benefits would be better spent elsewhere...
That degree of malleability, in a team environment, is not all it's
cracked up to be. Ever heard of the Tower of Babel? After years of
work it would up vaporware. Guess why.
On 15 May, 21:09, Series Expansion <·······@gmail.com> wrote:
> On May 15, 3:39 pm, Tamas K Papp <······@gmail.com> wrote:
>
> > You are just not getting it, are you? Those languages will be
> > superior to Lisp when _you_ can add constructs like that.
>
> If _I_ can add constructs like that, my coworker can too, probably
> ones that are incompatible with mine, making our attempts to
> collaborate blow up in our faces.
I don't see how it follows that you cannot collaborate but in
any case it's the same with functions: you and a coworker might
write functions with the same name but doing different things.
Any solution you have for this problem will work with macros.
--
Who's your mama?
On 15 May, 21:09, Series Expansion <·······@gmail.com> wrote:
> On May 15, 3:39 pm, Tamas K Papp <······@gmail.com> wrote:
>
> > You are just not getting it, are you? Those languages will be
> > superior to Lisp when _you_ can add constructs like that.
>
> If _I_ can add constructs like that, my coworker can too, probably
> ones that are incompatible with mine, making our attempts to
> collaborate blow up in our faces.
I don't see how it follows that you cannot collaborate but in
any case it's the same with functions: you and a coworker might
write functions with the same name but doing different things.
Any solution you have for this problem will work with macros.
--
Who's your mama?
On May 15, 4:49 pm, Spiros Bousbouras <······@gmail.com> wrote:
> I don't see how it follows that you cannot collaborate but in
> any case it's the same with functions: you and a coworker might
> write functions with the same name but doing different things.
> Any solution you have for this problem will work with macros.
Three messages saying this, more or less. Two of them identical and
from you.
None acknowledging the difference between merely defining named
functions and actually *altering how the compiler interprets the
language* (or, and this came up elsethread, altering a system class to
add idiosyncratic new methods).
On 16 May, 04:45, Series Expansion <·······@gmail.com> wrote:
> On May 15, 4:49 pm, Spiros Bousbouras <······@gmail.com> wrote:
>
> > I don't see how it follows that you cannot collaborate but in
> > any case it's the same with functions: you and a coworker might
> > write functions with the same name but doing different things.
> > Any solution you have for this problem will work with macros.
>
> Three messages saying this, more or less. Two of them identical and
> from you.
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.
Regarding the duplicate post, I thought it looked so nice it just
had to be posted twice ;-)
> None acknowledging the difference between merely defining named
> functions and actually *altering how the compiler interprets the
> language* (or, and this came up elsethread, altering a system class to
> add idiosyncratic new methods).
My knowledge of CLOS is rudimentary so I've stayed out of that
part of the discussion and I have only skimmed through posts
commenting on it. I can assure you I have read very carefully
(the parts of) your posts specifically dealing with macros. I'll
comment on some of them right after this but I'm afraid I will
still not acknowledge any difference because you have not
convinced me there is a difference with regards to safety.
Regarding the coworker issue it is perfectly possible to use
macros to increase your own productivity without your macros
having any impact whatsoever on the code of any of your
coworkers: you write your functions using macros or whatever
else you find increases your productivity and you only expose an
interface to other people. I'm not saying that macros should
only be used by one person and not a team, I'm just pointing out
that even in such a scenario they will have a positive impact
while at the same time minimising the dangers you seem to think
are present.
Oh and macros do not alter ``how the compiler interprets the
language''.
By the way, I usually don't make an issue out of people
acknowledging stuff but since you brought it up you have not
acknowledged
<
http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/65299a1a8856b074/4ef5dfa2fc6d906f?#4ef5dfa2fc6d906f
>
[1] <
http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/65299a1a8856b074/7385151a2ea1e6a9?#7385151a2ea1e6a9
>
On May 16, 1:10 am, Spiros Bousbouras <······@gmail.com> wrote:
> On 16 May, 04:45, Series Expansion <·······@gmail.com> wrote:
> > On May 15, 4:49 pm, Spiros Bousbouras <······@gmail.com> wrote:
> > > I don't see how it follows that you cannot collaborate but in
> > > any case it's the same with functions: you and a coworker might
> > > write functions with the same name but doing different things.
> > > Any solution you have for this problem will work with macros.
>
> > Three messages saying this, more or less. Two of them identical and
> > from you.
>
> 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. Besides, my original point
stands: with functions, you affect whatever calls those functions.
Macros on the other hand can throw a monkey wrench anywhere into the
codebase, if something goes wrong.
> Regarding the duplicate post, I thought it looked so nice it just
> had to be posted twice ;-)
Some guy thinks his advertisements for shoes look so nice in cljp that
they just have to posted sixty thousand times.
> I have read very carefully
> (the parts of) your posts specifically dealing with macros. I'll
> comment on some of them right after this but I'm afraid I will
> still not acknowledge any difference because you have not
> convinced me there is a difference with regards to safety.
Well, I don't know how it can get any plainer than my earlier example
showing that a macro introduced into one bit of a codebase can
potentially quietly redefine system functions used throughout that
codebase. This could happen by accident and cause bugs that were very
hard to track down.
> Regarding the coworker issue it is perfectly possible to use
> macros to increase your own productivity without your macros
> having any impact whatsoever on the code of any of your
> coworkers
Macros alter the compiler's behavior; you said it yourself earlier.
That means the potential for them to alter how it treats the
coworker's code. So once your code, including your macro, and your
coworker's code are combined anywhere, boom!
Maybe not a problem if there are separate compilation units that get
linked together later. I could #define something in one of my .c
(not .h) files and it would be local to that file, and not affect how
anyone else's .c files were compiled, and the C linker wouldn't care
when it later linked the .o files. But my understanding of Lisp is
that all of the code is compiled together as a seamless whole, which
means a macro in that code can potentially "contaminate" any
subsequent code, more like a #define in a .h file than one in a .c
file. And I've shown how a buggy one can be dangerous.
> Oh and macros do not alter ``how the compiler interprets the
> language''.
This is in direct contradiction to your own earlier claim. (And what's
with the funny quotes? Shift key broken?)
> By the way, I usually don't make an issue out of people
> acknowledging stuff but since you brought it up you have not
> acknowledged
> <http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/...
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.
Spiros Bousbouras wrote:
>> 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.
Series Expansion wrote:
> What's this [1] shit? Some creative sort of pseudo-pronoun?
It's obvious to the rest of us, without resorting to potty-mouthedness. Use
of a reference to a footnote as a stand-in for the contents of the footnote is
a long-established practice among the literate.
--
Lew
Series Expansion <·······@gmail.com> writes:
> Macros alter the compiler's behavior; you said it yourself earlier.
> That means the potential for them to alter how it treats the
> coworker's code. So once your code, including your macro, and your
> coworker's code are combined anywhere, boom!
I can see how this is legitimate confusion on your part. Macros only
have local effects, within their own bodies. They are like functions
which recieve their arguments verbatim, and return Lisp code to be
substituted for themselves.
On May 16, 6:27 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> Series Expansion <·······@gmail.com> writes:
> > Macros alter the compiler's behavior; you said it yourself earlier.
> > That means the potential for them to alter how it treats the
> > coworker's code. So once your code, including your macro, and your
> > coworker's code are combined anywhere, boom!
>
> I can see how this is legitimate confusion on your part.
There is no confusion.
> Macros only have local effects, within their own bodies.
Of course not; if that were true, macros would be useless. Macros have
effect wherever their names occur in the program text.
On 16 May, 20:32, Series Expansion <·······@gmail.com> wrote:
> On May 16, 1:10 am, Spiros Bousbouras <······@gmail.com> wrote:
>
> > 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/comp.lang.lisp/browse_thread/thread/65299a1a8856b074/7385151a2ea1e6a9?#7385151a2ea1e6a9
>
[...]
> Macros alter the compiler's behavior; you said it yourself earlier.
For the record, I never said such a thing.
[...]
> > By the way, I usually don't make an issue out of people
> > acknowledging stuff but since you brought it up you have not
> > acknowledged
> > <http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/...
>
> 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 ;-)
--
May you live every day of your life.
Jonathan Swift
On May 17, 12:31 am, Spiros Bousbouras <······@gmail.com> wrote:
> On 16 May, 20:32, Series Expansion <·······@gmail.com> wrote:
[...]
> > 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.
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
Pillsy wrote:
> On May 17, 12:31 am, Spiros Bousbouras <······@gmail.com> wrote:
>> On 16 May, 20:32, Series Expansion <·······@gmail.com> wrote:
> [...]
>>> 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.
It took you a long time to figure out that "Series Expansion" is a troll.
(And a liar, too.)
> 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.
This thread is boring.
--
Lew
On May 17, 1:13 pm, Lew <·····@lewscanon.com> wrote:
> Pillsy wrote:
> > On May 17, 12:31 am, Spiros Bousbouras <······@gmail.com> wrote:
> >> 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.
>
> It took you a long time to figure out that "Series Expansion" is a troll.
> (And a liar, too.)
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Spiros.
> > 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.
>
> This thread is boring.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Pillsy.
On May 17, 2:07 am, Pillsy <·········@gmail.com> wrote:
> On May 17, 12:31 am, Spiros Bousbouras <······@gmail.com> wrote:
>
> > On 16 May, 20:32, Series Expansion <·······@gmail.com> wrote:
> [...]
> > > 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?
No, I am not.
> > I checked your Google profile and you only have posts in this
> > thread.
That is because until roughly a week ago, I was a lurker in
comp.lang.java.programmer.
> > So I guess you saw that a flamewar was brewing and you decided
> > to jump in to push people's buttons.
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.
On May 17, 12:31 am, Spiros Bousbouras <······@gmail.com> wrote:
> On 16 May, 20:32, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 1:10 am, Spiros Bousbouras <······@gmail.com> wrote:
>
> > > 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.
You were writing a usenet post, not an academic paper. Please stick to
the style guidelines.
> > Macros alter the compiler's behavior; you said it yourself earlier.
>
> For the record, I never said such a thing.
You, personally, may not have, but your side of the debate did, in
<··············@pbourguignon.anevia.com>:
Ok, then let me summarize lisp macros as being hooks in the lisp
compiler.
Imagine what you could do if you could modify your compiler on
the fly
That your side's position is apparently somewhat incoherent does not
aid its credibility.
> > > By the way, I usually don't make an issue out of people
> > > acknowledging stuff but since you brought it up you have not
> > > acknowledged
> > > <http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/...
>
> > 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?
Your side's penchant for randomly inserting personal attacks into its
posts also does not aid its credibility.
> 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.
Actually, no. I was lurking, as new users commonly do, when a subject
came up that interested me sufficiently to decide to author a post,
essentially to ask whether Lisp had yet reached the maturity to be
used for desktop applications and similar everyday programming
purposes. It had not, but the question sparked a discussion that has
now unfortunately become somewhat acrimonious. It is worthy of note
that, in this thread, the primary sources of flamage thus far has been
comp.lang.lisp, not comp.lang.java.programmer, and that the
comp.lang.java.programmer poster with the largest contribution of
namecalling and vitriol thus far has been Lew, not I.
On May 15, 4:09 pm, Series Expansion <·······@gmail.com> wrote:
> That degree of malleability, in a team environment, is not all it's
> cracked up to be. Ever heard of the Tower of Babel? After years of
> work it would up vaporware. Guess why.
http://en.wikipedia.org/wiki/Tower_of_Babel
Your knowledge of biblical literature leaves something to be desired.
Don't write lisp code, God will be angry!
On May 15, 6:41 pm, ··················@gmail.com wrote:
> On May 15, 4:09 pm, Series Expansion <·······@gmail.com> wrote:
>
> > That degree of malleability, in a team environment, is not all it's
> > cracked up to be. Ever heard of the Tower of Babel? After years of
> > work it would up vaporware. Guess why.
Wound up vaporware.
And my point stands.
On Fri, 15 May 2009 13:09:51 -0700, Series Expansion wrote:
> On May 15, 3:39 pm, Tamas K Papp <······@gmail.com> wrote:
>> On Fri, 15 May 2009 12:15:59 -0700, Series Expansion wrote:
>>
>> > Then it might be C++, Java > Lisp.
>>
>> You are just not getting it, are you? Those languages will be superior
>> to Lisp when _you_ can add constructs like that.
>
> If _I_ can add constructs like that, my coworker can too, probably ones
> that are incompatible with mine, making our attempts to collaborate blow
> up in our faces. Then our boss wonders why we're stuck, and whether the
> money the company is spending on our salaries and benefits would be
> better spent elsewhere...
Or maybe you could just talk about it and sort it out with your
coworker. Ever tried things like that? :-)
Tamas
On May 15, 6:31 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> "eric-and-jane-smith" <·······@nospam.com> writes:
> > Macros in other programming languages often seem to obfuscate the code as
> > much as they improve it, such that there may be little or no net gain.
> > But CL macros can make the code orders of magnitude clearer, easier to
> > read, easier to work with, and less error prone. There is a powerful
> > synergy between the different advantages of CL macros, such that knowing
> > them as a list of advantages is not enough to understand their real
> > power.
>
> Yes, a good point.
>
> I've lately decided that I really like the example of WITH-OPEN-FILE as
> an example of a nice Lisp macro. OK, it's already in the language, but
> the important point is that it would be something easy to add if it
> WASN'T in the language. This exposition can proceed by looking at the
> problem it was put in to solve, and comparing it to two Java solutions.
>
> Problem: When you open a file, you have to remember to close it, even if
> the code using the file happens to throw an exception.
>
> OK. The standard Java solution would be to use "try ... finally":
>
> OutputStream out = null; // Needs definition outside try block.
> try {
> out = new FileOutputStream(filename);
> // do stuff
> } finally {
> if (out != null) {
> try {
> out.close();
> } catch (IOException ioe) {
> // Do something like log this.
> }
> }
> }
>
> So, this is just a bit cumbersome, because you have to remember to
> declare the variables in the correct place, remember to put in the
> finally block, with appropriate safety checks. Note that because the
> close() method can also throw an exception, you have to wrap it in its
> own exception handling block. That's a lot of infrastructure that you
> need to write around the file handling code that you really care about,
> namely the "// do stuff" part.
>
> Note in particular, that STATIC TYPING DOES NOTHING to enforce this type
> of good programming practice. That's because it isn't a type error, but
> an oversight in program strucure. Macros, on the other hand, allow you
> to easily capture such good practice.
>
> [Aside: There has of late been a lot of "excitement" about pattern-based
> design. This is all well and good, but it is something that,
> essentially, Common Lisp has had all along through the judicious use of
> macros. In fact, lisp has gone beyond the notion of mere patterns and
> instead calls this aspect the process of building a Domain Specific
> Language (DSL)]
>
> Now, you can, in fact, write the same thing in Common Lisp, yielding a
> program that looks kind of like this:
>
> (let ((out nil))
> (unwind-protect
> (progn
> (setq out (open filename :direction :output))
> ;; Do stuff
> )
> (unless (null out)
> (close out))))
>
> where we set up the same basic structure. Now, since we nearly always
> want to do something like this when we open the file, we would like to
> have a safe way to do this that is convenient and gets the details
> right. So we take the basic outline of what we want and write a macro
> that embodies this particular idiom:
>
> (defmacro with-open-file ((var filename &rest open-options) &body body)
> `(let ((,var nil))
> (unwind-protect
> (progn
> (setq ,var (open ,filename ,@open-options))
> ,@body)
> (unless (null ,var)
> (close ,var)))))
>
> So now we have a macro that automatically handles the task of opening a
> file and remembering to close it. That simplifies our code to the more
> perspicacious and correct, because the macro has been carefully
> constructed:
>
> (with-open-file (out filename :direction :output)
> ;; do-stuff
> )
>
> This also allows us to concentrate our attention on the actual DO-STUFF
> part, which is the variable part of this endeavor and the place where
> logic bugs can occur. We don't have to bother ourselves looking at all
> of the boilerplate and making sure we got it right, since we've already
> gotten the boilerplate parts correct in our macro.
>
> So, how would one go about doing something similar in Java. The real
> crux of the matter is that there isn't any facility in the language that
> allows you to introduce a new control structure that allows you to
> insert your actual program into the middle of some combination of
> existing constructs.
>
> As near as I can tell, the method one would need to use involves
> encapsulating the program you want to execute inside a (possibly
> anonymous) class with a defined "run" interface so that it can be
> executed. That would involve something along the lines of
>
> public interface FileProcessor {
> public void processFile (OutputStream out);
>
> }
>
> public class ProcessFile {
> public static void processOpenFile (String filename, FileProcessor worker) {
> OutputStream out = null;
> try {
> out = new FileOutputStream(filename);
> worker.processFile(out);
> } finally {
> if (out != null) {
> try {
> out.close();
> } catch (IOException ioe) {
> ioe.printStackTrace();
> }
> }
> }
> }
>
> }
>
> OK. With this infrastructure defined, we can now write code that looks
> sort of like this:
>
> ProcessFile.processOpenFile(filename,
> new FileProcessor () {
> public void processFile(OutputStream out) {
> // do stuff
> }
> });
>
> where we create a new anonymous class instance to encapsulate the body
> of the code that we want to execute.
>
> So, it is possible to build up such abstractions in Java, but to my eyes
> that looks a lot clunkier and less integrated than the Lisp macro
> solution.
The "Spring" Java framework uses this pattern alot in its so-called
"template" classes, which help removing part of the boilerplate from
using some of the most common Java libraries. For example, when using
Hibernate (most used Java ORM) you have to write something like this
all the time:
//sessionFactory is initialized once and then reused everywhere
Session session = sessionFactory.createSession();
Transaction t = session.beginTransaction();
try {
//do stuff
t.commit();
} catch(HibernateException e) {
t.rollback();
} finally {
session.close();
}
While Spring gives you something like
HibernateTemplate tmpl = new HibernateTemplate(sessionFactory);
tmpl.doInHibernate(new HibernateCallback() {
public void dontRememberItsName(Session s) throws HibernateException
{
//do stuff
}
});
This is IMHO not only much uglier than a Lisp macro; it's really
conceptually different. It's more like
(do-in-hibernate (lambda (session) ...do stuff...))
where do-in-hibernate is a higher-order function, not a macro. This
might not look like a big difference to someone that is not accustomed
to macros, but can quickly become a pain in the @$$ if you start
nesting many pseudo-macro calls like that. Plus, the code loses some
of its "declarative" look, and loses big functionality too - no more
tampering with the lexical environment is allowed, including voluntary
variable capture, local declarations, etc. and also no more code
walking to analyze and transform user-provided code, since it's hidden
in a lambda. Of course, these are advanced concepts - I myself really
used them just a few times, mostly for experimentation - but knowing
they're possible gives you another weapon against the hardest
problems.
> You see, there isn't any way of introducing new forms into
> Java that look like the language itself. So there isn't any way to add
> your own control structure construct that looks like
>
> with_open_file (out, filename) {
> // do stuff
> }
>
> which would be the real equivalent of the Common Lisp macro solution.
In fact, with-open-file style macros are so useful that IIRC the
designers of C# built them into the language, with the using(resource)
{ ...code... } construct. Of course, language designers can only
foresee a limited set of patterns that can have the dignity of a
dedicated language construct. So, you're out of luck as soon as you
encounter a pattern the language designers haven't included, unless
you have macros.
> So this is a very simple example of what is meant when lisp programmers
> talk about using macros to write code that is correct, and a very
> simplistic example of how we go about writing DSLs to solve problems, by
> removing the superstructure required by the programming language from
> sight so we can concentrate on getting the actual business logic right.
Really good points. I'll save your post and show it to my fellow
coworkers - all Java developers ;)
(To be fair, this is not much a Java problem but a general non-Lisp
problem ;-) In fact, Java is pretty advanced for being a "mainstream"
language - compare for example with C++ and its total lack of dynamic
typing, no reflection, no garbage collection, no anonymous classes
that can at least simulate closures, etc. etc.).
Alessio
On Fri, 15 May 2009 12:59:16 +0000, eric-and-jane-smith wrote:
> And that's just one of many reasons why it's hard to advocate for CL to
> people who have little or no experience with it. No matter what we say,
> we sound like raving maniacs, till they find out for themselves, by
> getting real experience with CL, and not just testing the waters by
> writing some simple code that only uses a small fraction of the features
> of the language.
I prefer not to advocate. I am happy to discuss CL with people, but I
would be reluctant proselytize vehemently.
It took me about a year to "get" macros even partially, and I am sure
there is still so much more to learn. The problem is that it is hard
to demonstrate the most useful features in short code snippets that
non-lispers could be expected to understand.
Also, macros can be abused. I have done that when I was learning
Lisp, and only learned how to write better macros gradually with the
guidance of the kind people on c.l.l. I can imagine that in a
corporate environment with many programmers, one would be wary of
inexperienced programmers writing macros, especially if you don't have
the time or inclination to teach them better because of high personnel
turnover rates.
Tamas
On 2009-05-15, Tamas K Papp <······@gmail.com> wrote:
> Also, macros can be abused. I have done that when I was learning
> Lisp, and only learned how to write better macros gradually with the
> guidance of the kind people on c.l.l. I can imagine that in a
> corporate environment with many programmers, one would be wary of
> inexperienced programmers writing macros, especially if you don't have
> the time or inclination to teach them better because of high personnel
> turnover rates.
I learned Lisp macros in about a week, and have always written great ones.
:)
Mileage varies.
Tamas K Papp <······@gmail.com> writes:
> On Fri, 15 May 2009 12:59:16 +0000, eric-and-jane-smith wrote:
>
>> And that's just one of many reasons why it's hard to advocate for CL to
>> people who have little or no experience with it. No matter what we say,
>> we sound like raving maniacs, till they find out for themselves, by
>> getting real experience with CL, and not just testing the waters by
>> writing some simple code that only uses a small fraction of the features
>> of the language.
>
> I prefer not to advocate. I am happy to discuss CL with people, but I
> would be reluctant proselytize vehemently.
>
> It took me about a year to "get" macros even partially, and I am sure
> there is still so much more to learn. The problem is that it is hard
> to demonstrate the most useful features in short code snippets that
> non-lispers could be expected to understand.
>
> Also, macros can be abused. I have done that when I was learning
> Lisp, and only learned how to write better macros gradually with the
> guidance of the kind people on c.l.l. I can imagine that in a
> corporate environment with many programmers, one would be wary of
> inexperienced programmers writing macros, especially if you don't have
> the time or inclination to teach them better because of high personnel
> turnover rates.
This argument is wrong.
In the corporate context, with any programming language there are
restrictions. There's a "style guide", sometimes it's even quite thick.
When you use programming language such as C++ there is a lot of things
you are prohibited to use, or that you must do in a given way.
Well it would be the same when using lisp. The inexperienced
programmers would be forbidden to write macros (or would get special
attention in code reviews). But experienced programmers could write
them and provide a DSL library for the inexperienced ones.
--
__Pascal Bourguignon__
"eric-and-jane-smith" <·······@nospam.com> writes:
> ···@informatimago.com (Pascal J. Bourguignon) wrote in
> ···················@pbourguignon.anevia.com:
>
>> Ok, then let me summarize lisp macros as being hooks in the lisp
>> compiler.
>>
>>
>> Imagine what you could do if you could modify your compiler on the
>> fly:
>>
>> - you could change your programming language, to specialize it for
>> your current problem,
>>
>> - you could implement more sophisticated type or semantic checking,
>>
>> - you could implement higher level code generation strategies
>> (eg. instead of just generating machine code from arithmetic
>> operations or message sending, you could generate programs from a
>> declarative description of your problem),
>>
>> - etc.
>
> A lot of people might still not get it, even after understanding some of
> the kinds of things that can be done with them. They might have bad
> memories of trying to use the macros of other programming languages, and
> making a big mess with them, such that their programs gradually became
> hard to read and maintain. Their attitude might be that the more you can
> do with them, the bigger a mess you can make with them.
>
> Macros in other programming languages often seem to obfuscate the code as
> much as they improve it, such that there may be little or no net gain.
> But CL macros can make the code orders of magnitude clearer, easier to
> read, easier to work with, and less error prone. There is a powerful
> synergy between the different advantages of CL macros, such that knowing
> them as a list of advantages is not enough to understand their real
> power.
>
> People with a lot of experience in a lot of other programming languages
> are likely to think the concept of macros is simple and universal. Their
> experience tells them they're like a two-edge sword, to be careful with,
> and to not expect miracles from. The idea that in CL it would not be
> unusual to write most of a 20-line function as one big macro call, with
> other macro calls nested in that one, is likely to seem bizarre to them,
> and give them even more reason to avoid CL.
>
> And that's just one of many reasons why it's hard to advocate for CL to
> people who have little or no experience with it. No matter what we say,
> we sound like raving maniacs, till they find out for themselves, by
> getting real experience with CL, and not just testing the waters by
> writing some simple code that only uses a small fraction of the features
> of the language.
Well at that point I can only say that, well over here we're not (all)
raving maniacs, that we have useful tools that help solve or obviate a
lot of problems found with other programming languages, and point to
that tutorial: http://www.lisperati.com/casting.html
(and http://www.cliki.net/Online%20Tutorial for those who want to
learn more).
--
__Pascal Bourguignon__
Stefan Ram wrote:
> The same coded in Java without macros /is/ more verbose,
> but also more readable to someone who knows Java:
>
> public static String getMultiValue( Object valueObject )
> { String result = null;
> if( valueObject == null )result = null;
>
> else if( valueObject instanceof StringValue )
> { StringValue stringValue =( StringValue )valueObject;
> result = getStringValue( stringValue ); }
>
> else if( valueObject instanceof SprayValue )
> { SprayValue setValue =( SprayValue )valueObject;
> result = getSetValue( setValue ); }
>
> return result; }
An experienced Java programmer will see this series of 'instanceof'
operators and look for a way to code the thing polymorphically.
interface Multi<T>
{
public String getValue( T arg );
}
class StringVersion implements Multi<String>
{
public String getValue( String arg )
{
return getStringValue( arg );
}
}
class SprayVersion implements Multi<Spray>
{
public String getValue( Spray arg )
{
return getSprayValue( arg );
}
}
etc.
--
Lew
From: Thomas A. Russ
Subject: Re: macros (was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <ymiy6synx4a.fsf@blackcat.isi.edu>
Lew <···@lewscanon.com> writes:
> Stefan Ram wrote:
> > �� The same coded in Java without macros /is/ more verbose,
> > �� but also more readable to someone who knows Java:
> >
> > public static String getMultiValue( Object valueObject )
> > { String result = null;
> > �� if( valueObject == null )result = null;
> >
> > �� else if( valueObject instanceof StringValue )
> > �� { StringValue stringValue =( StringValue )valueObject;
> > �� �� result = getStringValue( stringValue ); }
> >
> > �� else if( valueObject instanceof SprayValue )
> > �� { SprayValue setValue =( SprayValue )valueObject;
> > �� �� result = getSetValue( setValue ); }
> >
> > �� return result; }
>
> An experienced Java programmer will see this series of 'instanceof'
> operators and look for a way to code the thing polymorphically.
>
> interface Multi<T>
> {
> public String getValue( T arg );
> }
> class StringVersion implements Multi<String>
> {
> public String getValue( String arg )
> {
> return getStringValue( arg );
> }
> }
> class SprayVersion implements Multi<Spray>
> {
> public String getValue( Spray arg )
> {
> return getSprayValue( arg );
> }
> }
>
> etc.
So, then you either need to carefully wrap everything you want to handle
in a new object just in order to do the dispatch on it for this one
method.
(BTW, this is caused by the inability to add methods to a Java class
once it is defined. Another nice, flexible benefit of CLOS).
--
Thomas A. Russ, USC/Information Sciences Institute
On May 15, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> (BTW, this is caused by the inability to add methods to a Java class
> once it is defined. Another nice, flexible benefit of CLOS).
Another potential source of headaches too, I'll warrant. Imagine the
chaos that would ensue if Java did allow this. Someone might add a
method to the String class called "foo" to do X. Someone else adds a
method to the String class called "foo" to do Y. Then someone tries to
use both pieces of code together in the same project and kaboom!
The only way out looks like adding a whole 'nother system of package
namespaces *inside* *each and every class* for its methods.
Even then you get dependency headaches. Code calling someString.foo()
won't compile if you don't have the right non-standard String
extension in your classpath somewhere. It's one thing if you have
instanceOfSomeUnfamiliarClass.foo() and obviously need a library
installed, but when code calls non-existent methods on standard
library classes like String, who you gonna call? A google search for
"SomeUnfamiliarClass" might turn up the needed library; a google
search for "String" isn't likely to help much.
On 15 maio, 16:03, Series Expansion <·······@gmail.com> wrote:
> On May 15, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > (BTW, this is caused by the inability to add methods to a Java class
> > once it is defined. Another nice, flexible benefit of CLOS).
>
> Another potential source of headaches too, I'll warrant. Imagine the
> chaos that would ensue if Java did allow this. Someone might add a
> method to the String class called "foo" to do X. Someone else adds a
> method to the String class called "foo" to do Y. Then someone tries to
> use both pieces of code together in the same project and kaboom!
>
> The only way out looks like adding a whole 'nother system of package
> namespaces *inside* *each and every class* for its methods.
>
> Even then you get dependency headaches. Code calling someString.foo()
> won't compile if you don't have the right non-standard String
> extension in your classpath somewhere. It's one thing if you have
> instanceOfSomeUnfamiliarClass.foo() and obviously need a library
> installed, but when code calls non-existent methods on standard
> library classes like String, who you gonna call? A google search for
> "SomeUnfamiliarClass" might turn up the needed library; a google
> search for "String" isn't likely to help much.
You are once again flaming what you do not understand. The CL package
system will solve the name collision with no harm done. Any method you
write, you will write it in your own library's namespace. Two
different libraries can implement many and many functions with the
same name. They will only make external the functions / methods that
provide the functionality of the lib. If anyone want to use the two of
them together, and it has some symbol clashes (probably just a few of
them), this person can explicitly tell how the clashes should be
handled.
On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
> On 15 maio, 16:03, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 15, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > > (BTW, this is caused by the inability to add methods to a Java class
> > > once it is defined. Another nice, flexible benefit of CLOS).
>
> > Another potential source of headaches too, I'll warrant. Imagine the
> > chaos that would ensue if Java did allow this. Someone might add a
> > method to the String class called "foo" to do X. Someone else adds a
> > method to the String class called "foo" to do Y. Then someone tries to
> > use both pieces of code together in the same project and kaboom!
>
> > The only way out looks like adding a whole 'nother system of package
> > namespaces *inside* *each and every class* for its methods.
>
> > Even then you get dependency headaches. Code calling someString.foo()
> > won't compile if you don't have the right non-standard String
> > extension in your classpath somewhere. It's one thing if you have
> > instanceOfSomeUnfamiliarClass.foo() and obviously need a library
> > installed, but when code calls non-existent methods on standard
> > library classes like String, who you gonna call? A google search for
> > "SomeUnfamiliarClass" might turn up the needed library; a google
> > search for "String" isn't likely to help much.
>
> You are once again flaming what you do not understand.
I'm not the one doing the flaming here at all.
> The CL package system will solve the name collision with no harm done.
I just explained why the package system won't. Adding new classes in
their own packages? No problem, the package system can distinguish
foo.String from bar.String. Adding new methods to an existing class,
say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
foo.String.doIt()? They have the same method name, are methods of
classes with the same name, and the classes are in the same package.
As far as the compiler is concerned, they are the same. The package
system cannot distinguish them unless we add another layer of
namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
and foo.String.quux.doIt() instead of just foo.String.doIt() as the
fully-qualified names. And now we're deep in migraine-headache
territory, without oar or compass...
> They will only make external the functions / methods that
> provide the functionality of the lib.
Java can do this too.
So, basically, you're saying that the way you avoid the name clash is
to make baz's String.doIt() and quux's String.doIt() private. Of
course, this now means that anyone who wants their own code to call a
String.doIt() has to roll their own and can't get a canned one from a
library. Because if they do, and there's multiple incompatible
libraries that provide this, then we're back to square one and name
clashes.
Of course, the best way to avoid multiple incompatible libraries is to
have commonly desired functionality built into the standard library.
And then letting third parties create (non-private, at least) methods
in your classes is unnecessary.
Of course letting them create private ones is also tricky. They need
to be a new kind of private: private to the module that defines them,
NOT to the class they're defined in (now that those are different).
Now the private/public/local/global scope system gets more
complicated.
Everywhere I look I see tradeoffs here.
> If anyone want to use the two of
> them together, and it has some symbol clashes (probably just a few of
> them), this person can explicitly tell how the clashes should be
> handled.
Ah, I love the smell of boilerplate code in the morning!
Series Expansion <·······@gmail.com> writes:
> On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
>
>> The CL package system will solve the name collision with no harm done.
>
> I just explained why the package system won't. Adding new classes in
> their own packages? No problem, the package system can distinguish
> foo.String from bar.String. Adding new methods to an existing class,
> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
> foo.String.doIt()?
I guess that's one of the downsides of an inside-out object
system.
>> They will only make external the functions / methods that
>> provide the functionality of the lib.
>
> Java can do this too.
>
> So, basically, you're saying that the way you avoid the name clash is
> to make baz's String.doIt() and quux's String.doIt() private. Of
> course, this now means that anyone who wants their own code to call a
> String.doIt() has to roll their own and can't get a canned one from a
> library. Because if they do, and there's multiple incompatible
> libraries that provide this, then we're back to square one and name
> clashes.
No, he's saying that support methods that don't make up a library's API
won't be exported from packages, so there's no hazard of name clashes
between them when one chooses to import all symbols from a package. That
leaves a smaller number of potential name clashes to resolve manually.
>> If anyone want to use the two of them together, and it has some
>> symbol clashes (probably just a few of them), this person can
>> explicitly tell how the clashes should be handled.
>
> Ah, I love the smell of boilerplate code in the morning!
Not boilerplate. Just resolving a couple of conflicts if they arise. You
could skip it entirely and use package prefixes if you liked, which
isn't always a bad thing to do.
Paul Donnelly wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
>>
>>> The CL package system will solve the name collision with no harm done.
>> I just explained why the package system won't. Adding new classes in
>> their own packages? No problem, the package system can distinguish
>> foo.String from bar.String. Adding new methods to an existing class,
>> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
>> foo.String.doIt()?
>
> I guess that's one of the downsides of an inside-out object
> system.
Can I jump in here? You see, I have a theory.
It goes something like this. Java and most OO languages are actually
noun-oriented languages. They follow the natural way of thinking:
subject does verb to object. 1 + 1 = 2. And so on.
Lisp is verb-oriented. It goes (verb subject object1 object2) or (+ 1 1).
Right off, Lisp seems less intuitive. But that doesn't necessarily mean
anything.
However, it will also affect namespacing.
With Java, you'd have packages that then contain nouns (classes), in
which you implement verbs (methods). So suppose there's Integer, Float,
and Double and they all have plus verbs that take their own kind. I add
Complex and create a Complex.plus(Complex) verb inside it, and stick it
in my own namespace.
Good, good.
With Lisp, you'd have packages that then contain verbs, in which you
implement versions for different nouns. So you'd have a system package
containing plus, which in turn contains plus(Integer, Integer),
plus(Float, Float), and plus(Double, Double).
Now you can see where the problem will show up. If I want to add a
Complex noun, now I have to add a plus(Complex, Complex) to plus. Which
means I have to modify something in the system package. Uh-oh!
It all boils down to which programmers will be doing more often: adding
new nouns which may be used with already-existing verbs, or adding new
verbs which may be used with already-existing nouns.
Adding new nouns which are used only with new verbs is not a problem in
either case.
Adding new nouns which may be used with already-existing verbs is not a
problem if namespaces contain nouns, which contain implementations per
supported verb. But it is a problem if namespaces contain verbs, which
contain implementations per supported noun.
Adding new verbs which may be used with already-existing nouns is not a
problem if namespaces contain verbs, which contain implementations per
supported noun. But it is a problem if namespaces contain nouns, which
contain implementations per supported verb.
So, if new nouns with existing verbs is more common, Java's method is
better. If new verbs with existing nouns is more common, Lisp's method
is better. (Leaving static vs. dynamic typing entirely alone here and
considering only the order of scoping of nouns and verbs within
namespaces.) Doing the "wrong" one in either language will cause
headaches unless there's a way to namespace separately by noun and verb,
which would cause its own inherent variety of headaches instead.
My own experience tells me that new nouns with existing verbs is more
common. I quite often want to define a new Java class that has state. I
much less often wish for an existing Java class to have a method I've
never heard of before.
The workaround also isn't usually that bad: create a utility class with
a static method to do the manipulation. It can't be polymorphic or use
the object's private state directly, but the latter is for the best and
the former, while annoying, isn't usually a show-stopper.
The Lisp way around would present problems. On the rare occasion I
wanted to augment an existing class with new behavior it would be easy:
define my own verb in my own namespace and set up somehow a polymorphic
dispatch on object type. On the much more frequent occasion I wanted to
add a new noun, I'd often be forced to change verbs that lived in
pre-existing namespaces, and maybe even in more than one namespace; the
code for my new noun would be scattered all over the codebase AND the
namespaces within the system, rather than in exactly one place in each.
Ouch.
There's also going to be big differences in polymorphism. With an object
oriented system, nouns can be subtypes of other nouns, and verb behavior
can be inherited, with or without modification. Dispatch is based on the
run-time-type of the noun, and adding a new polymorphic type is easy. In
Java, suppose there was an Addable interface specifying the plus method,
and Integer, Float, and Double implemented it. If I created my Complex
class and implemented Addable, code that did generic sums over Addables
would automatically also work with Complex now. I wouldn't have to make
any changes outside the Complex class.
With Lisp, I'd need to change the system namespace's plus verb's
dispatch table manually so that it knew about my Complex class, on the
other hand. Both problems in one. In fact, every combination of noun and
verb in dynamic dispatch needs to be explicitly specified somewhere.
From the sounds of it, I couldn't just say "Complex is a type of
Number" in Lisp and have the compiler automatically know where to
dispatch plus, minus, times, and dividedBy; I'd have to edit four
separate dispatch tables in four separate places, AND define (hopefully
all in one final, fifth place) my Complex implementations of these that
the new dispatch table entries would point to. With Java I'd just have
to define the implementations, naming them correctly, and stick
"implements Number" somewhere and away I'd go.
>> So, basically, you're saying that the way you avoid the name clash is
>> to make baz's String.doIt() and quux's String.doIt() private.
>
> No, he's saying that support methods that don't make up a library's API
> won't be exported from packages, so there's no hazard of name clashes
> between them when one chooses to import all symbols from a package.
That's the same thing isn't it? He says "private", you say "won't be
exported"; it looks the same to me.
>>> If anyone want to use the two of them together, and it has some
>>> symbol clashes (probably just a few of them), this person can
>>> explicitly tell how the clashes should be handled.
>> Ah, I love the smell of boilerplate code in the morning!
>
> Not boilerplate. Just resolving a couple of conflicts if they arise.
At each place where it arises.
This can happen in Java too, if the same piece of code uses two
different classes with the same unqualified name. You can end up with
code littered with "java.util.Date" and "javax.sql.Date" for instance in
some types of enterprise code. It's god-awful. All those repeated
"java.util." and "javax.sql." prefixes add up to quite a lot of boilerplate.
Fortunately, it's rare to get name clashes between different peoples'
nouns and still need to intersperse both in one bit of code. It's much
more common with verbs:
someIOStream.close();
aDoor.close();
aPort.close();
aSocket.close();
aTransaction.close();
if (difference(pointA, pointB).close()) doSomething();
I'd hate to have to fully qualify all my "close"s, or "open"s, or
"free"s, or "release"s, or "next"s, or "remove"s, or "equals"s, instead
of the correct one being inferred from the type of the expression to the
left of it.
On May 15, 7:22 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Paul Donnelly wrote:
> > Series Expansion <·······@gmail.com> writes:
>
> >> On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
>
> >>> The CL package system will solve the name collision with no harm done.
> >> I just explained why the package system won't. Adding new classes in
> >> their own packages? No problem, the package system can distinguish
> >> foo.String from bar.String. Adding new methods to an existing class,
> >> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
> >> foo.String.doIt()?
>
> > I guess that's one of the downsides of an inside-out object
> > system.
>
> Can I jump in here? You see, I have a theory.
>
> It goes something like this. Java and most OO languages are actually
> noun-oriented languages. They follow the natural way of thinking:
> subject does verb to object.
Depending on your culture this may or may not be a natural way of
thinking.
> 1 + 1 = 2. And so on.
Woah! hang on there..
This is a /very/ bad example of subject does verb to object.
> Lisp is verb-oriented. It goes (verb subject object1 object2) or (+ 1 1).
>
Right, Add one and one.
(although actually '+' in lisp is more like a summation than a '+')
> Right off, Lisp seems less intuitive. But that doesn't necessarily mean
> anything.
Not obviously less intuitive here...
>
> However, it will also affect namespacing.
>
Go on..
> With Java, you'd have packages that then contain nouns (classes), in
> which you implement verbs (methods). So suppose there's Integer, Float,
> and Double and they all have plus verbs that take their own kind. I add
> Complex and create a Complex.plus(Complex) verb inside it, and stick it
> in my own namespace.
>
> Good, good.
>
> With Lisp, you'd have packages that then contain verbs, in which you
> implement versions for different nouns. So you'd have a system package
> containing plus, which in turn contains plus(Integer, Integer),
> plus(Float, Float), and plus(Double, Double).
MMM. no.
To continue the anaolgy:
You have packages with verbs /and/ nouns (at the same level).
Then your verbs are specified based on the noun that they apply to.
>
> Now you can see where the problem will show up. If I want to add a
> Complex noun, now I have to add a plus(Complex, Complex) to plus. Which
> means I have to modify something in the system package. Uh-oh!
>
No. You tack on another specification to the verb.
> It all boils down to which programmers will be doing more often: adding
> new nouns which may be used with already-existing verbs, or adding new
> verbs which may be used with already-existing nouns.
>
Not really.
> Adding new nouns which are used only with new verbs is not a problem in
> either case.
>
> Adding new nouns which may be used with already-existing verbs is not a
> problem if namespaces contain nouns, which contain implementations per
> supported verb. But it is a problem if namespaces contain verbs, which
> contain implementations per supported noun.
>
> Adding new verbs which may be used with already-existing nouns is not a
> problem if namespaces contain verbs, which contain implementations per
> supported noun. But it is a problem if namespaces contain nouns, which
> contain implementations per supported verb.
>
Neither of these is really a problem in lisp.
> So, if new nouns with existing verbs is more common, Java's method is
> better. If new verbs with existing nouns is more common, Lisp's method
> is better. (Leaving static vs. dynamic typing entirely alone here and
> considering only the order of scoping of nouns and verbs within
> namespaces.) Doing the "wrong" one in either language will cause
> headaches unless there's a way to namespace separately by noun and verb,
> which would cause its own inherent variety of headaches instead.
(defgeneric frobnobdicate (a b)
(:method ((foo foo) (bar bar)) ;;arguments
.. body)
(:method ((foo foo) (baz baz))
..body))
(defclass foo () ;; no inheritance
(AttributesHere))
(defclass bar ()
(AttributesHere))
(defclass baz ()
(AttributesHere))
(defclass bat (baz) ;inherits from baz
())
Then I can do:
(frobnobdicate InstanceOfFoo InstanceOfBar)
(frobnobdicate InstanceOfFoo InstanceOfBaz)
(frobnobdicate InstanceOfFoo InstanceOfBat)
>
> My own experience tells me that new nouns with existing verbs is more
> common. I quite often want to define a new Java class that has state. I
> much less often wish for an existing Java class to have a method I've
> never heard of before.
>
Of course, this is programming in Java (I assume?), where everything
is (somewhat arbitrarily) 'noun based'.
> The workaround also isn't usually that bad: create a utility class with
> a static method to do the manipulation. It can't be polymorphic or use
> the object's private state directly, but the latter is for the best and
> the former, while annoying, isn't usually a show-stopper.
>
> The Lisp way around would present problems. On the rare occasion I
> wanted to augment an existing class with new behavior it would be easy:
> define my own verb in my own namespace and set up somehow a polymorphic
polymorphic dispatch == generic function
> dispatch on object type. On the much more frequent occasion I wanted to
> add a new noun, I'd often be forced to change verbs that lived in
> pre-existing namespaces, and maybe even in more than one namespace; the
> code for my new noun would be scattered all over the codebase AND the
> namespaces within the system, rather than in exactly one place in each.
>
Not really. You could put all of your methods for a given generic
function with the generic function, or you could put all of your
methods for a given object with the object.
(using defmethod).
If you want to use the exact same existing method, you could just
inherit it.
> Ouch.
>
> There's also going to be big differences in polymorphism. With an object
> oriented system, nouns can be subtypes of other nouns, and verb behavior
> can be inherited, with or without modification. Dispatch is based on the
> run-time-type of the noun, and adding a new polymorphic type is easy.
> In
> Java, suppose there was an Addable interface specifying the plus method,
> and Integer, Float, and Double implemented it. If I created my Complex
> class and implemented Addable, code that did generic sums over Addables
> would automatically also work with Complex now. I wouldn't have to make
> any changes outside the Complex class.
>
> With Lisp, I'd need to change the system namespace's plus verb's
> dispatch table manually so that it knew about my Complex class, on the
> other hand. Both problems in one. In fact, every combination of noun and
> verb in dynamic dispatch needs to be explicitly specified somewhere.
No. Use inheritance.
You'd have a metaclass addable and everything addable that would
inherit it.
> From the sounds of it, I couldn't just say "Complex is a type of
> Number" in Lisp and have the compiler automatically know where to
> dispatch plus, minus, times, and dividedBy; I'd have to edit four
> separate dispatch tables in four separate places, AND define (hopefully
> all in one final, fifth place) my Complex implementations of these that
> the new dispatch table entries would point to. With Java I'd just have
> to define the implementations, naming them correctly, and stick
> "implements Number" somewhere and away I'd go.
You really don't seem to have a clue about lisp or clos.
>
> >> So, basically, you're saying that the way you avoid the name clash is
> >> to make baz's String.doIt() and quux's String.doIt() private.
>
> > No, he's saying that support methods that don't make up a library's API
> > won't be exported from packages, so there's no hazard of name clashes
> > between them when one chooses to import all symbols from a package.
>
> That's the same thing isn't it? He says "private", you say "won't be
> exported"; it looks the same to me.
>
Packages and methods are very different things.
> >>> If anyone want to use the two of them together, and it has some
> >>> symbol clashes (probably just a few of them), this person can
> >>> explicitly tell how the clashes should be handled.
> >> Ah, I love the smell of boilerplate code in the morning!
>
> > Not boilerplate. Just resolving a couple of conflicts if they arise.
>
> At each place where it arises.
>
> This can happen in Java too, if the same piece of code uses two
> different classes with the same unqualified name. You can end up with
> code littered with "java.util.Date" and "javax.sql.Date" for instance in
> some types of enterprise code. It's god-awful. All those repeated
> "java.util." and "javax.sql." prefixes add up to quite a lot of boilerplate.
>
> Fortunately, it's rare to get name clashes between different peoples'
> nouns and still need to intersperse both in one bit of code. It's much
> more common with verbs:
>
> someIOStream.close();
> aDoor.close();
> aPort.close();
> aSocket.close();
> aTransaction.close();
> if (difference(pointA, pointB).close()) doSomething();
>
> I'd hate to have to fully qualify all my "close"s, or "open"s, or
> "free"s, or "release"s, or "next"s, or "remove"s, or "equals"s, instead
> of the correct one being inferred from the type of the expression to the
> left of it.
Ok. I agree. Based on this thread alone CL is too difficult for the
masses.
This is not a reflection on Lisp, it is a reflection on the masses.
Next time I suggest knowing a little bit about lisp and clos before
arguing about lisp and clos.
··················@gmail.com wrote:
> On May 15, 7:22 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Can I jump in here? You see, I have a theory.
>>
>> It goes something like this. Java and most OO languages are actually
>> noun-oriented languages. They follow the natural way of thinking:
>> subject does verb to object.
>
> [flamage]
>
>> 1 + 1 = 2. And so on.
>
> Woah! hang on there..
> [flamage]
Oh boy, now the fun begins. :P
>> Right off, Lisp seems less intuitive. But that doesn't necessarily mean
>> anything.
>
> Not obviously less intuitive here...
Ask any ten random fifth-graders which makes immediate sense and which
they have to think about: 1 + 1, + 1 1.
>> With Lisp, you'd have packages that then contain verbs, in which you
>> implement versions for different nouns. So you'd have a system package
>> containing plus, which in turn contains plus(Integer, Integer),
>> plus(Float, Float), and plus(Double, Double).
>
> MMM. no.
> To continue the anaolgy:
> You have packages with verbs /and/ nouns (at the same level).
> Then your verbs are specified based on the noun that they apply to.
That's even worse. If the verbs are namespaced by the nouns (and I don't
see this working with dynamic typing AT ALL), then having packages with
verbs seems superfluous. If they're namespaced separately, we're right
back where we started at package.Class.anotherpackage.Method, only it's
reversed to (anotherpackage.Method package.Class). You've got name
qualifiers warting out all over the place here!
>> Now you can see where the problem will show up. If I want to add a
>> Complex noun, now I have to add a plus(Complex, Complex) to plus. Which
>> means I have to modify something in the system package. Uh-oh!
>>
> No. You tack on another specification to the verb.
Which is (hypothetically) located in a package you don't own, perhaps
even the system package (whatever is analogous to java.lang).
Java won't let you easily tack anything on to anything in java.lang and
with good reason.
Imagine the headaches and incompatibilities if code with different
things "tacked onto" java.lang had to coexist in the same software one
day. Without even getting into the security can-o-worms it would open.
These considerations exist whatever the language and whatever its system
namespace is called, however.
>> It all boils down to which programmers will be doing more often: adding
>> new nouns which may be used with already-existing verbs, or adding new
>> verbs which may be used with already-existing nouns.
>
> Not really.
Yes really.
>> Adding new nouns which may be used with already-existing verbs is not a
>> problem if namespaces contain nouns, which contain implementations per
>> supported verb. But it is a problem if namespaces contain verbs, which
>> contain implementations per supported noun.
>>
>> Adding new verbs which may be used with already-existing nouns is not a
>> problem if namespaces contain verbs, which contain implementations per
>> supported noun. But it is a problem if namespaces contain nouns, which
>> contain implementations per supported verb.
>
> Neither of these is really a problem in lisp.
Well, one of them HAS to be unless both nouns and verbs have to be
qualified, separately. And then we're deep into
fruits.Kumquat.digestion.eatMe() territory. I guess you can import
Kumquat. What do you do about eatMe() though?
>> So, if new nouns with existing verbs is more common, Java's method is
>> better. If new verbs with existing nouns is more common, Lisp's method
>> is better. (Leaving static vs. dynamic typing entirely alone here and
>> considering only the order of scoping of nouns and verbs within
>> namespaces.) Doing the "wrong" one in either language will cause
>> headaches unless there's a way to namespace separately by noun and verb,
>> which would cause its own inherent variety of headaches instead.
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> ..body))
>
> (defclass foo () ;; no inheritance
> (AttributesHere))
>
> (defclass bar ()
> (AttributesHere))
>
> (defclass baz ()
> (AttributesHere))
>
> (defclass bat (baz) ;inherits from baz
> ())
>
> Then I can do:
> (frobnobdicate InstanceOfFoo InstanceOfBar)
> (frobnobdicate InstanceOfFoo InstanceOfBaz)
> (frobnobdicate InstanceOfFoo InstanceOfBat)
Christ, where's the Tylenol??
*rummaging*
*pop* *gulp* Ah, much better.
Eh, I don't see any namespace related anything in that. I do see
manually managed dispatch tables and plenty of other migraine-inducers
though.
Suppose you created all of that stuff and then someone else wanted to
frobnobdicate their quux objects. Now they have to mess with the
defgeneric ... etc. in your namespace, in your source code...
I think one thing people are missing here is that real software projects
are typically worked on by teams, and even lone developers typically use
third-party and system libraries. That divides the typical project's
code base, from a particular developer's viewpoint, into "my code" and
"everyone else's code", and generally limits them to making changes to,
or putting things into the namespaces in, "my code" only.
The days of the lone hacker building a whole system from the ground up
singlehandedly are mostly gone, for better or for worse.
Languages that don't provide for other use-cases, and in particular ones
that don't play nice with modularising code, version control, or
testing-distinct-from-going-live, will increasingly be marginalized.
>> My own experience tells me that new nouns with existing verbs is more
>> common. I quite often want to define a new Java class that has state. I
>> much less often wish for an existing Java class to have a method I've
>> never heard of before.
>>
> Of course, this is programming in Java (I assume?), where everything
> is (somewhat arbitrarily) 'noun based'.
It's far more general than that.
Results 1 - 10 of about 8,950 from dictionary.com for noun.
Results 1 - 10 of about 1,470 from dictionary.com for verb.
The implication of these two Google searches is that nouns are about six
times more numerous than verbs.
It stands to reason that needing a new noun to use with existing verbs
might be about six times more frequent than needing a new verb to use
with existing nouns.
>> On the much more frequent occasion I wanted to
>> add a new noun, I'd often be forced to change verbs that lived in
>> pre-existing namespaces, and maybe even in more than one namespace; the
>> code for my new noun would be scattered all over the codebase AND the
>> namespaces within the system, rather than in exactly one place in each.
>>
> Not really. You could put all of your methods for a given generic
> function with the generic function, or you could put all of your
> methods for a given object with the object.
> (using defmethod).
>
> If you want to use the exact same existing method, you could just
> inherit it.
The case at issue is when there's a pre-existing generic function with
the desired name, in library code or otherwise where I couldn't fiddle
with it (except as a lone-wolf hacker), and in a namespace I shouldn't
put my own stuff in (except as a lone-wolf hacker).
>> With Lisp, I'd need to change the system namespace's plus verb's
>> dispatch table manually so that it knew about my Complex class, on the
>> other hand. Both problems in one. In fact, every combination of noun and
>> verb in dynamic dispatch needs to be explicitly specified somewhere.
>
> No. Use inheritance.
> You'd have a metaclass addable and everything addable that would
> inherit it.
The hypothesis at issue is that this metaclass, or whatever, already
exists and I'm not free to modify that code.
>> From the sounds of it, I couldn't just say "Complex is a type of
>> Number" in Lisp and have the compiler automatically know where to
>> dispatch plus, minus, times, and dividedBy; I'd have to edit four
>> separate dispatch tables in four separate places, AND define (hopefully
>> all in one final, fifth place) my Complex implementations of these that
>> the new dispatch table entries would point to. With Java I'd just have
>> to define the implementations, naming them correctly, and stick
>> "implements Number" somewhere and away I'd go.
>
> [flame]
How tiresome.
>>>> So, basically, you're saying that the way you avoid the name clash is
>>>> to make baz's String.doIt() and quux's String.doIt() private.
>>> No, he's saying that support methods that don't make up a library's API
>>> won't be exported from packages, so there's no hazard of name clashes
>>> between them when one chooses to import all symbols from a package.
>> That's the same thing isn't it? He says "private", you say "won't be
>> exported"; it looks the same to me.
>
> Packages and methods are very different things.
Of course they are, but methods are in packages, and packages create
namespaces, and not everyone on a large project (or a typical project
even) will be able to make changes to things in every namespace.
>> This can happen in Java too, if the same piece of code uses two
>> different classes with the same unqualified name. You can end up with
>> code littered with "java.util.Date" and "javax.sql.Date" for instance in
>> some types of enterprise code. It's god-awful. All those repeated
>> "java.util." and "javax.sql." prefixes add up to quite a lot of boilerplate.
>>
>> Fortunately, it's rare to get name clashes between different peoples'
>> nouns and still need to intersperse both in one bit of code. It's much
>> more common with verbs:
>>
>> someIOStream.close();
>> aDoor.close();
>> aPort.close();
>> aSocket.close();
>> aTransaction.close();
>> if (difference(pointA, pointB).close()) doSomething();
>>
>> I'd hate to have to fully qualify all my "close"s, or "open"s, or
>> "free"s, or "release"s, or "next"s, or "remove"s, or "equals"s, instead
>> of the correct one being inferred from the type of the expression to the
>> left of it.
>
> [flame]
I guess we're done here if you have nothing else constructive to say now.
Seamus MacRae <··········@live.ca.nospam> writes:
>> (defgeneric frobnobdicate (a b)
>> (:method ((foo foo) (bar bar)) ;;arguments
>> .. body)
>> (:method ((foo foo) (baz baz))
>> ..body))
>>
>> (defclass foo () ;; no inheritance
>> (AttributesHere))
>>
>> (defclass bar ()
>> (AttributesHere))
>>
>> (defclass baz ()
>> (AttributesHere))
>>
>> (defclass bat (baz) ;inherits from baz
>> ())
>>
>> Then I can do:
>> (frobnobdicate InstanceOfFoo InstanceOfBar)
>> (frobnobdicate InstanceOfFoo InstanceOfBaz)
>> (frobnobdicate InstanceOfFoo InstanceOfBat)
>
> Christ, where's the Tylenol??
>
> *rummaging*
>
> *pop* *gulp* Ah, much better.
>
> Eh, I don't see any namespace related anything in that. I do see
> manually managed dispatch tables and plenty of other migraine-inducers
> though.
Whatever you think you see, I can assure you it's a hallucination.
> Suppose you created all of that stuff and then someone else wanted to
> frobnobdicate their quux objects. Now they have to mess with the
> defgeneric ... etc. in your namespace, in your source code...
Methods don't need to be placed in a DEFGENERIC form.
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>>> (defgeneric frobnobdicate (a b)
>>> (:method ((foo foo) (bar bar)) ;;arguments
>>> .. body)
>>> (:method ((foo foo) (baz baz))
>>> ..body))
>>>
>>> (defclass foo () ;; no inheritance
>>> (AttributesHere))
>>>
>>> (defclass bar ()
>>> (AttributesHere))
>>>
>>> (defclass baz ()
>>> (AttributesHere))
>>>
>>> (defclass bat (baz) ;inherits from baz
>>> ())
>>>
>>> Then I can do:
>>> (frobnobdicate InstanceOfFoo InstanceOfBar)
>>> (frobnobdicate InstanceOfFoo InstanceOfBaz)
>>> (frobnobdicate InstanceOfFoo InstanceOfBat)
>> Christ, where's the Tylenol??
>>
>> *rummaging*
>>
>> *pop* *gulp* Ah, much better.
>>
>> Eh, I don't see any namespace related anything in that. I do see
>> manually managed dispatch tables and plenty of other migraine-inducers
>> though.
>
> Whatever you think you see, I can assure you it's a hallucination.
Accusing your debate opponent of being mentally ill is a deplorable and
dishonest tactic, the more so when you do it obliquely to try to hide
the fact that your argument is an ad hominem one.
>> Suppose you created all of that stuff and then someone else wanted to
>> frobnobdicate their quux objects. Now they have to mess with the
>> defgeneric ... etc. in your namespace, in your source code...
>
> Methods don't need to be placed in a DEFGENERIC form.
But you guys said earlier that "we don't put methods in classes, we put
them in generic functions".
And Anonymous C Lisper just said, where I quoted it above, that generic
functions take the form of these "defgeneric" constructs.
I then simply pointed out what happens if that construct happens to be
in code you can't change.
Even supposing there's two ways to make generic functions, using a
centrally-controlled "defgeneric" and using some hypothetical
distributed construct, if an author chose to use the centralized
"defgeneric" method for a particular generic function, and you need to
modify that particular generic function, and you don't have write rights
to the code containing that particular generic function ...
Seamus MacRae <··········@live.ca.nospam> writes:
> > Methods don't need to be placed in a DEFGENERIC form.
>
> But you guys said earlier that "we don't put methods in classes, we put
> them in generic functions".
>
> And Anonymous C Lisper just said, where I quoted it above, that generic
> functions take the form of these "defgeneric" constructs.
>
> I then simply pointed out what happens if that construct happens to be
> in code you can't change.
>
> Even supposing there's two ways to make generic functions, using a
> centrally-controlled "defgeneric" and using some hypothetical
> distributed construct, if an author chose to use the centralized
> "defgeneric" method for a particular generic function, and you need to
> modify that particular generic function, and you don't have write rights
> to the code containing that particular generic function ...
No you don't.
You see, the fundamental problem with your arguments is that you
persistently argue from ignorance. You see snippets of Common Lisp, and
rather than trying to understand them through outside reading and
research, you jump to conclusions based on other languages you know.
You then assert, quite forcefully, objections based on your
misunderstanding of how things work. So this practice of making
unwarranted assumptions and then stating them as "facts" makes this
entire discussion a lot more long-winded that it really need be.
In that final paragraph above, you make the unwarranted assumption that
the choice of how to do the definition is an exclusive one. In fact,
they can be easily mixed. A fundamental flaw in your argumentation is
to not allow for the possibility of any options that you can't conceive
of, or to see that there can be a multiplicity of ways to specify
something in a programming language.
--
Thomas A. Russ, USC/Information Sciences Institute
On 2009-05-20, Thomas A. Russ <···@sevak.isi.edu> wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> "defgeneric" method for a particular generic function, and you need to
>> modify that particular generic function, and you don't have write rights
>> to the code containing that particular generic function ...
>
> No you don't.
>
> You see, the fundamental problem with your arguments is that you
> persistently argue from ignorance. You see snippets of Common Lisp, and
> rather than trying to understand them through outside reading and
> research, you jump to conclusions based on other languages you know.
Only a moron would try to guess semantics from syntax, and present
the guess as fact.
Nobody who sits within a ten cubicle radius of me would go online and post
wild-assed guesses he has absolutely no clue about.
That's because I find myself in the middle of an engineering company.
Kaz Kylheku wrote:
> On 2009-05-20, Thomas A. Russ <···@sevak.isi.edu> wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>> "defgeneric" method for a particular generic function, and you need to
>>> modify that particular generic function, and you don't have write rights
>>> to the code containing that particular generic function ...
>> No you don't.
Yes you do.
>> You see, the fundamental problem with your arguments is that you
>> persistently argue from ignorance. [rest of insult post deleted unread]
Once again Thomas dishonestly resorts to the ad hominem attack in lieu
of a well-thought-out, reasoned argument. (And dishonestly tries to hide
it from me, too!)
> Only a moron [rest of insult post deleted unread]
Once again Kaz dishonestly resorts to the ad hominem attack in lieu of a
well-thought-out, reasoned argument. (And dishonestly tries to hide it
from me, too!)
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>>> Methods don't need to be placed in a DEFGENERIC form.
>> But you guys said earlier that "we don't put methods in classes, we put
>> them in generic functions".
>>
>> And Anonymous C Lisper just said, where I quoted it above, that generic
>> functions take the form of these "defgeneric" constructs.
>>
>> I then simply pointed out what happens if that construct happens to be
>> in code you can't change.
>>
>> Even supposing there's two ways to make generic functions, using a
>> centrally-controlled "defgeneric" and using some hypothetical
>> distributed construct, if an author chose to use the centralized
>> "defgeneric" method for a particular generic function, and you need to
>> modify that particular generic function, and you don't have write rights
>> to the code containing that particular generic function ...
>
> No you don't.
Yes you do.
> You see, the fundamental problem with your arguments is that you
> persistently argue from ignorance. [rest of insult post deleted unread]
Ocne again you dishonestly resort to the ad hominem attack in lieu of a
well-thought-out, reasoned argument. (And dishonestly try to hide it
from me, too!)
Seamus MacRae <··········@live.ca.nospam> writes:
> ··················@gmail.com wrote:
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > ..body))
> > (defclass foo () ;; no inheritance
> > (AttributesHere))
> > (defclass bar ()
> > (AttributesHere))
> > (defclass baz ()
> > (AttributesHere))
> > (defclass bat (baz) ;inherits from baz
> > ())
> > Then I can do:
> > (frobnobdicate InstanceOfFoo InstanceOfBar)
> > (frobnobdicate InstanceOfFoo InstanceOfBaz)
> > (frobnobdicate InstanceOfFoo InstanceOfBat)
>
> Eh, I don't see any namespace related anything in that. I do see
> manually managed dispatch tables and plenty of other migraine-inducers
> though.
Precisely. It doesn't enter into this at all, in most cases.
It is nicely in the background for when you need it, but it doesn't
intrude into your day-to-day programming most of the time.
> Suppose you created all of that stuff and then someone else wanted to
> frobnobdicate their quux objects. Now they have to mess with the
> defgeneric ... etc. in your namespace, in your source code...
Um, no.
They don't need to do anything with DEFGENERIC at all, since that
function is already present.
They just add their own method by just doing
(defmethod frobnicate ((foo quux) (baz quux))
..body)
and this method gets added. They do this in their own source code.
They don't need to do anything to your source code.
Perhaps you were confused because the poster to which you were replying
used one of the alternate convenience techniques for adding methods to a
generic function.
That is ONE way to do it, but in Lisp there are often multiple ways to
accomplish the same thing. In this case, there is also a stand-alone
DEFMETHOD that could be used instead. Having a lot of flexibility in a
language takes some getting used to, but the philosophy of Lisp is to
provide a wide range of tools and techniques and rely upon programmers
being smart enough to pick the tool that is most appropriate to the
problem at hand.
> I think one thing people are missing here is that real software projects
> are typically worked on by teams, and even lone developers typically use
> third-party and system libraries. That divides the typical project's
> code base, from a particular developer's viewpoint, into "my code" and
> "everyone else's code", and generally limits them to making changes to,
> or putting things into the namespaces in, "my code" only.
>
> The days of the lone hacker building a whole system from the ground up
> singlehandedly are mostly gone, for better or for worse.
>
> Languages that don't provide for other use-cases, and in particular ones
> that don't play nice with modularising code, version control, or
> testing-distinct-from-going-live, will increasingly be marginalized.
Well, that is one of the nice things about CLOS and being able to add
additional methods or even entire functions to existing objects (such as
in libraries) where you don't have access to the source code. There
have been lots of large systems built with lisp, and these things have
been given a fair amount of thought. Just because the solution is
different from Java's solution doesn't make it ineffective.
See again my hammer and picnic blanket analogy for why you might want to
be able to do new things with existing objects. Suppose you wanted to
graph a tree of objects. java.lang.Class doesn't have a graph()
method, and you can't add one. In CLOS you just define a graph method,
specializing as necessary, say if you wanted to render Class and
Interface differently.
> It's far more general than that.
>
> Results 1 - 10 of about 8,950 from dictionary.com for noun.
> Results 1 - 10 of about 1,470 from dictionary.com for verb.
>
> The implication of these two Google searches is that nouns are about six
> times more numerous than verbs.
I doubt the scientific validity of this, but we'll let that pass.
It still doesn't follow that one would choose a methodology that makes
one or the other of these approaches MORE difficult, when one can
instead have a methodology where adding a noun or adding a verb are
equally easy. That seems a no-brainer to me.
> It stands to reason that needing a new noun to use with existing verbs
> might be about six times more frequent than needing a new verb to use
> with existing nouns.
So, you advocate then arbitrarily making about 1/6th of your work harder
than it needs to be because, well it's only 16% of the time?
> The case at issue is when there's a pre-existing generic function with
> the desired name, in library code or otherwise where I couldn't fiddle
> with it (except as a lone-wolf hacker), and in a namespace I shouldn't
> put my own stuff in (except as a lone-wolf hacker).
Um. You are making unwarranted assumptions again.
1) You are expected to use pre-existing generic functions. That's how
you extend the existing library code base.
2) You are NOT expected to even have access to the source code. You
don't need it. You shouldn't mess with it. All you need to know is
what the API for the generic function is. That is all you need know
is the signature and the semantics (the latter so you know that this
is actually the generic function you want).
3) The name already exists in the namespace, so you aren't changing the
namespace at all. (BTW: Namespaces in Common Lisp are exactly
that. They are NAMEspaces and only concern themselves with the
resolution of names. They don't get overloaded with notions of
functions, classes, or anything extraneous like that)
4) Assuming that you are extending the generic function in a reasonable
manner, for example by adding methods that dispatch on types that
you have defined, then there is no "lone-wolf hacker" part to this
at all. It is a controlled extension of the library. It is no more
"lone-wolf hacker" than subclassing a library class in Java would be.
> The hypothesis at issue is that this metaclass, or whatever, already
> exists and I'm not free to modify that code.
So far so code.
There is an existing function or class.
You are not free to modify that code.
That doesn't stop you from either creating a subclass of that library
class or extending the generic function by adding methods. YOU DO NOT
NEED ACCESS TO THE ORIGINAL CODE TO ADD METHODS. No more so than you
need access to the source code in Java to create a subclass.
Perhaps that is the analogy that you need to understand this. In Common
Lisp adding a method to a generic function is the same as creating a new
subclass of an existing class. It extends the generic function by
allowing it to apply to a new combination of method argument types. It
is, in essence, adding a dynamically dispatched "subclass" to the
generic function.
We'll not get into metaclasses, because they don't really exist in Java.
> > Packages and methods are very different things.
>
> Of course they are, but methods are in packages, and packages create
> namespaces, and not everyone on a large project (or a typical project
> even) will be able to make changes to things in every namespace.
Methods are not in packages.
Now there is some potential for confusion here, because both Java and
Common Lisp have things called "packages", but they are not quite the
same.
A Common Lisp package is simply a namespace. It controls the mapping
from surface strings to symbols. Symbols are first class objects in
Common Lisp. Symbols are used as the namees of things in Common Lisp,
but the package system affects only the mapping of strings to names when
lisp code (or data) is read.
Only symbols are in packages.
There is a difference between using and making changes. Even if you
can't (or shouldn't) make changes to a namespace, you can still use the
existing names that are in there. Just as you can subclass any class
you like (except Java final classes), you can extend any generic
function in Common Lisp. That doesn't change the namespace. It merely
extends the generic function, much as sublasses extend their parents.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> ··················@gmail.com wrote:
>
>>> (defgeneric frobnobdicate (a b)
>>> (:method ((foo foo) (bar bar)) ;;arguments
>>> .. body)
>>> (:method ((foo foo) (baz baz))
>>> ..body))
>>> (defclass foo () ;; no inheritance
>>> (AttributesHere))
>>> (defclass bar ()
>>> (AttributesHere))
>>> (defclass baz ()
>>> (AttributesHere))
>>> (defclass bat (baz) ;inherits from baz
>>> ())
>>> Then I can do:
>>> (frobnobdicate InstanceOfFoo InstanceOfBar)
>>> (frobnobdicate InstanceOfFoo InstanceOfBaz)
>>> (frobnobdicate InstanceOfFoo InstanceOfBat)
>> Eh, I don't see any namespace related anything in that. I do see
>> manually managed dispatch tables and plenty of other migraine-inducers
>> though.
>
> Precisely. It doesn't enter into this at all, in most cases.
> It is nicely in the background for when you need it, but it doesn't
> intrude into your day-to-day programming most of the time.
[More Lisp-specific stuff] ...
As fascinating as this Lisp conversation is, it's off topic for a Java newsgroup.
--
Lew
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> ··················@gmail.com wrote:
>
>>> (defgeneric frobnobdicate (a b)
>>> (:method ((foo foo) (bar bar)) ;;arguments
>>> .. body)
>>> (:method ((foo foo) (baz baz))
>>> ..body))
>>> (defclass foo () ;; no inheritance
>>> (AttributesHere))
>>> (defclass bar ()
>>> (AttributesHere))
>>> (defclass baz ()
>>> (AttributesHere))
>>> (defclass bat (baz) ;inherits from baz
>>> ())
>>> Then I can do:
>>> (frobnobdicate InstanceOfFoo InstanceOfBar)
>>> (frobnobdicate InstanceOfFoo InstanceOfBaz)
>>> (frobnobdicate InstanceOfFoo InstanceOfBat)
>> Eh, I don't see any namespace related anything in that. I do see
>> manually managed dispatch tables and plenty of other migraine-inducers
>> though.
>
> Precisely. It doesn't enter into this at all, in most cases.
> It is nicely in the background for when you need it, but it doesn't
> intrude into your day-to-day programming most of the time.
Except the hypothetical situation at issue was when you wanted to add a
new dispatch for a method and the "defgeneric" dispatch-table thingie
was not in the same namespace you want your own code to be in.
Which means that Anonymous C Lisper dodged the issue instead of
addressing it.
>> Suppose you created all of that stuff and then someone else wanted to
>> frobnobdicate their quux objects. Now they have to mess with the
>> defgeneric ... etc. in your namespace, in your source code...
>
> Um, no.
Um, yes.
(defgeneric frobnobdicate (a b)
(:method ((foo foo) (bar bar)) ;;arguments
.. body)
(:method ((foo foo) (baz baz))
..body))
has to become something else, I'm guessing
(defgeneric frobnobdicate (a b)
(:method ((foo foo) (bar bar)) ;;arguments
.. body)
(:method ((foo foo) (baz baz))
.. body)
(:method ((foo foo) (quux quux))
..body))
or something close to that, to add quux to the set of classes it
dispatches on.
> They just add their own method by just doing
>
> (defmethod frobnicate ((foo quux) (baz quux))
> ..body)
>
> and this method gets added. They do this in their own source code.
> They don't need to do anything to your source code.
That is in contradiction with how Anonymous C Lisper said it was done.
Furthermore, the generic function frobnicate exists in *some* namespace.
Whose? If it's not yours, you'll either be intruding, or you'll be
creating a parallel generic function with the same name in a different
namespace. In the latter case, the two generic functions won't be
compatible anymore than java.util.Date and javax.sql.Date are. You
couldn't have x.frobnicate() (or rather, Lisp's equivalent syntax)
dispatch to foo's frobnicate if x was a foo and to quux's if x was a
quux; if you had imported Anonymous C Lisper's frobnicate x.frobnicate()
would not know about quux (only foo, bar, and baz) and if you had
imported your frobnicate x.frobnicate() would not know about foo (or bar
or baz), only quux. In either case, it would do what you wanted for one
type of value in x and give some sort of runtime error for the other.
It's the same problem, except swapping nouns and verbs, as trying in
Java to have a method whose return type was simply "Date" and then
sometimes return a java.util.Date and sometimes a javax.sql.Date from
it. (The best you can do is return a common supertype, in this case
likely having to be Object.)
> Perhaps you were confused because ...
I will not entertain public speculation regarding my mental functioning.
Please refrain from such. I will not respond to that kind of nonsense
except to trim most of it when replying and make a note similar to this
one that it is not polite behavior.
> That is ONE way to do it, but in Lisp there are often multiple ways to
> accomplish the same thing.
And therefore a high likelihood of confusion being created, particularly
as to where something is getting its value or definition from.
What I've seen so far of Lisp in your posts looks like an excellent
recipe for creating tightly-coupled code that will end up being a
nightmare to debug and maintain in any seriously large real-world
project. Localizing generic functions in one spot in the code causes
code-ownership-respecting change-request bottlenecks or else people
stepping on one another's toes. Disseminating them throughout the code
base, on the other hand, causes the code that's affecting *your* code to
be widely dispersed and hard to locate.
Haven't you guys ever heard of encapsulation?
> Having a lot of flexibility in a language takes some getting used to
This is also one of the touted "strengths" of perl. Everyone knows what
the result was: a messy hodgepodge with so many ways to do anything that
code reads like line noise and understanding other peoples' code
requires an encyclopedic knowledge of ALL of the ten zillion ways to do
everything.
Not a problem for small, single-developer projects.
HUGE problem for huge, multi-developer projects.
Hence the recent large scale exodus from perl to ruby and (to a lesser
extent) Python. The recent explosive growth in ruby (and especially
rails) has to a significant degree been fueled by perl users jumping ship.
> but the philosophy of Lisp is to
> provide a wide range of tools and techniques and rely upon programmers
> being smart enough to pick the tool that is most appropriate to the
> problem at hand.
Fine for single-developer projects.
In multi-developer projects, you have to also rely upon programmers
knowing ALL of the tools, every single last one of them.
Java only barely dodged this bullet, due to the literate-programming
influences on it. Java code contains all kinds of library calls into the
vast, almost incomprehensibly complex standard library, and often into
third-party libraries too. Fortunately, decent Java IDEs let you get
from some code using an unfamiliar class or method to the documentation
for that method almost instantly.
This doesn't work for perl (or, I expect, Lisp) because a) perl at least
lacks this bundle-the-docs-with-the-code-in-a-tool-recognized-format
aspect of Java, and b) even were it otherwise, stuff built into the
language itself lacks this sort of "JIT documentation" anyway. In Java
it's not a problem; although your IDE won't let you point at "int" and
get a primer on the built-in "int" type or point at "class" and get an
explanation of that, there's only a small amount to understand, and it
easily fits within the head of a single programmer. Not so with perl
and, apparently, Lisp; the former has, and the latter apparently has,
TONS of built-in operators and other things that are not going to have
"JIT docs" and that ARE all going to appear in code written by a large
enough team of developers, you can betcher aspidistras they will.
>> The days of the lone hacker building a whole system from the ground up
>> singlehandedly are mostly gone, for better or for worse.
>>
>> Languages that don't provide for other use-cases, and in particular ones
>> that don't play nice with modularising code, version control, or
>> testing-distinct-from-going-live, will increasingly be marginalized.
>
> Well, that is one of the nice things about CLOS
Much the reverse, as I have just explained. CLOS is an inside-out object
system; instead of providing powerful tools to create encapsulation to
insulate some code from changes to other code, it seems to provide
powerful tools to destroy encapsulation and change the behavior of
arbitrary other code. In a single-developer or serial-developer
environment, that might be powerful, but in a team-development
environment, it's a train wreck waiting to happen.
> There have been lots of large systems built with lisp, and these
> things have been given a fair amount of thought.
The problem is that developing a large system without teamwork, with
only one coder at a time, takes eons.
It's no wonder Lisp hackers enjoy good job security at the few job
positions they hold; they're going to be working on whatever they're
building until retirement, if not until doomsday.
> Just because the solution is different from Java's solution doesn't
> make it ineffective.
No, of course not. It's the solution not scaling to large devteams that
makes it ineffective.
> See again my hammer and picnic blanket analogy for why you might want to
> be able to do new things with existing objects.
I think that analogy was already torpedoed in another post.
> Suppose you wanted to graph a tree of objects. java.lang.Class
> doesn't have a graph() method, and you can't add one.
Fortunately for those of your coworkers who rely on its behavior.
A Java programmer create an external iterator that traverses classes
somehow.
> In CLOS you just define a graph method specializing as necessary
So a Lisp programmer has the option: create an external iterator that
traverses classes somehow, or muck with a system class and thereby break
everyone else's code in the project, thus getting the entire rest of the
team mad at them and probably winding up fired.
Oh, yeah, except that Lisp programmers work alone, or at best in pairs.
They more or less have to.
>> It's far more general than that.
>>
>> Results 1 - 10 of about 8,950 from dictionary.com for noun.
>> Results 1 - 10 of about 1,470 from dictionary.com for verb.
>>
>> The implication of these two Google searches is that nouns are about six
>> times more numerous than verbs.
>
> I doubt the scientific validity of this, but we'll let that pass.
It's quite valid. It's not a whole-web search, it's a search of just the
definitions at dictionary.com, where nearly all occurrences of "noun"
are in the form of word (noun) definition, and nearly all occurrences of
"verb" are in the form of word (verb) definition. I'd say the figures
are within 5% of the actual numbers of nouns and verbs on the site. (It
would have been nice, though, if they'd had a page with such statistics
that I could find.)
> It still doesn't follow that one would choose a methodology that makes
> one or the other of these approaches MORE difficult, when one can
> instead have a methodology where adding a noun or adding a verb are
> equally easy.
But you can't have such a methodology. There are only three possibilities:
One does package.Noun.verb;
One does package.verb(Noun);
One does package1.verb(package2.Noun) or package1.Noun.package2.verb.
The third is clearly cumbersome and difficult. Eliminate it. The first
makes it easy to add new nouns, and new verbs to new nouns, only. The
second makes it easy to add new verbs, and new nouns to existing verbs,
only. So the first makes it hard to add new verbs to existing nouns and
the second makes it hard to add new nouns to existing verbs, while the
third makes it easy to do both but hard to USE the darn things after.
The choice between the first two is then made by which one does more
often, add new nouns or add new verbs.
Apparently one adds new nouns about 6x as often as one adds new verbs.
The statistics on overall language size suggest it, and my own personal
experience bears it out.
> So, you advocate then arbitrarily making about 1/6th of your work harder
> than it needs to be because, well it's only 16% of the time?
No. I advocate choosing to make 16% harder (package.Noun.verb) over
making 84% harder (package.verb(Noun)) or 100% harder
(package1.verb(package2.Noun) or package1.Noun.package2.verb).
>> The case at issue is when there's a pre-existing generic function with
>> the desired name, in library code or otherwise where I couldn't fiddle
>> with it (except as a lone-wolf hacker), and in a namespace I shouldn't
>> put my own stuff in (except as a lone-wolf hacker).
>
> Um. You are making unwarranted assumptions again.
No, I am not, and you will kindly refrain from using accusatory
expressions ("you are <something that's bad>") directed at me in your
news posts ever again. It's extremely rude.
> 1) You are expected to use pre-existing generic functions. That's how
> you extend the existing library code base.
The problem is that doing so leads to problems in large-team shops when
conflicting modifications get made to basic code used systemwide. This
is why most programming languages don't let you make any modifications
to basic code used systemwide whatsoever. Lisp permitting such
modifications will cause team-size scaling problems.
> 2) You are NOT expected to even have access to the source code. You
> don't need it. You shouldn't mess with it.
So, the spirit of closed-source no-serviceable-parts-inside is still
alive and well in at least one place besides Redmond, WA.
> All you need to know is what the API for the generic function is.
That lets you call it but not add to it. To add to the generic function
in Anonymous C Lisper's post (the thing with the "(foo foo) (bar bar)"
stuff in it) obviously requires its source code.
> That is all you need know is the signature and the semantics (the
> latter so you know that this is actually the generic function you want).
Works for generic functions. Doesn't work for macros, since little
implementation details like the names of internally used variables in
the macros and how many times it references one of its parameters will
change its behavior. Without the source code, trying to debug problems
caused by extra side effects or by collisions between your variables and
variables inside the macro will be a nightmare.
Someone else in this thread has gone into a lot more detail about this,
posting a detailed and fairly convincing argument that some kinds of
macros could not be implemented without the macro having at least one of
three undesirable traits: non-reentrant and either not thread-safe or a
concurrency bottleneck; may cause local variable name collisions; and
may cause multiple occurrence of argument side effects.
Of these, the former is a pretty big deal, and the latter two mean
subtle bugs could arise where the macro got used that would be hard to
figure out without access to its source code.
> 3) The name already exists in the namespace, so you aren't changing the
> namespace at all.
That's sophistry. You could use the same statement to argue that
altering the behavior of java.lang.String was not "changing" the
java.lang namespace at all.
> (BTW: Namespaces in Common Lisp are exactly
> that. They are NAMEspaces and only concern themselves with the
> resolution of names. They don't get overloaded with notions of
> functions, classes, or anything extraneous like that)
Java packages don't, either, save that they get their own documentation
blurb and there's a "within this namespace only" level of access control
between protected ("same-namespace and subclasses") and private ("this
class and nested classes only", roughly).
Of course, the latter probably mystifies you, like everything else to do
with encapsulation.
> 4) Assuming that you are extending the generic function in a reasonable
> manner, for example by adding methods that dispatch on types that
> you have defined, then there is no "lone-wolf hacker" part to this
> at all. It is a controlled extension of the library. It is no more
> "lone-wolf hacker" than subclassing a library class in Java would be.
Subclassing a library class doesn't change the base class's behavior.
Whereas letting anyone edit
(foo foo) (bar bar)
(foo foo) (baz baz)
to
(foo foo) (bar bar)
(foo foo) (baz baz)
(foo foo) (quux quux)
necessarily also allows editing it to
(foo foo) (mumble mumble)
(foo foo) (baz baz)
and people frobnobdicating bars elsewhere in the project getting a nasty
surprise next time integration tests are run.
>> The hypothesis at issue is that this metaclass, or whatever, already
>> exists and I'm not free to modify that code.
>
> So far so code.
This does not make sense.
> That doesn't stop you from either creating a subclass of that library
> class or extending the generic function by adding methods.
Except that the latter is done by modifying the piece of code with the
defgeneric thingy, at least for a nonempty subset of generic functions
if not for all of them.
> Perhaps that is the analogy that you need to understand this. In Common
> Lisp adding a method to a generic function is the same as creating a new
> subclass of an existing class. It extends the generic function by
> allowing it to apply to a new combination of method argument types.
It's not the concept that concerns me. It's the actual mechanics.
Altering the dispatch table to add something means having write access,
which means having the ability to also alter or remove something,
perhaps unintentionally while trying to add something. It's a fruitful
source of breakage, it encourages tight coupling, and in some projects,
it might even be considered a security risk.
> It is, in essence, adding a dynamically dispatched "subclass" to the
> generic function.
Assuming no slips of the finger while editing the defgeneric thing, in
cases where that's how the particular generic function is defined
instead of that other way.
>>> Packages and methods are very different things.
>> Of course they are, but methods are in packages, and packages create
>> namespaces, and not everyone on a large project (or a typical project
>> even) will be able to make changes to things in every namespace.
>
> Methods are not in packages.
This contradicts what you guys said earlier. Earlier you intimated that
verbs (and maybe nouns AS WELL) were in namespaces.
If methods really are not in packages, there goes the neighborhood. Name
collisions are going to be causing an unbelievable amount of headaches
in any sufficiently large project.
> A Common Lisp package is simply a namespace.
So is a Java package, for the most part.
> It controls the mapping from surface strings to symbols.
Ditto, if by that you mean "resolving non-fully-qualified names in the
source code at compile time".
(Computer science really ought to adopt a more uniform terminology for
such common concepts.)
> the package system affects only the mapping of strings to names when
> lisp code (or data) is read.
Seems to confirm the above.
> Only symbols are in packages.
I don't see that this is a useful distinction, between "the method is in
the package" and "the method's name is in the package". It amounts to
the same thing. Using Java-like syntax, as I'm more familiar with it:
import package3.verb;
package1.verb
package2.verb
verb
will mean package1's version, package2's version, and package3's
version, in order. Whether you say "verb" is in the package or the
particular method is in the package, this isn't changed. In fact, it
doesn't seem to me to make much sense to say that "verb" itself is in a
particular package.
If by "symbol" you mean the equivalent of the fully-qualified name, then
yes, "package1.verb" is in package1 and so forth, but the important
thing to the programmer is that the different "verb"s avoid colliding,
and the choice of package to import affects how occurrences of
unqualified "verb" are resolved.
Then the distinction is entirely useless; whether the verb itself, as in
the code that does something, or simply the (fully-qualified) name used
to access it, is in package3 seems to be a meaningless quibble.
Especially given Lisp's lack of Java's default-access and protected
modifiers, which might be argued to make the distinction more meaningful
(but with nouns replacing verbs).
> There is a difference between using and making changes. Even if you
> can't (or shouldn't) make changes to a namespace, you can still use the
> existing names that are in there.
I would consider changing the code associated with those names to be
making changes in the namespace.
I would consider altering java.lang.String to add a new verb quux to it
to enable aString.quux() to be making an alteration in java.lang.
Likewise I would consider altering a Lisp verb lisp-verb in
some-namespace to add a new noun quux to it to enable (lisp-verb
some-quux) to be making an alteration in some-namespace.
> Just as you can subclass any class you like (except Java final
> classes), you can extend any generic function in Common Lisp.
> That doesn't change the namespace.
I'm sorry, but it does. Contrast:
package foo;
public class FooException extends Exception { }
which extends Exception (in java.lang) with FooException (in foo) and a
hypothetical addition of a Lisp class quux to a foo package with a
dispatch added for quuxes to a generic function in a bar package. You
aren't just subclassing something in the bar package, you're actually
changing the behavior of something in the bar package.
In the Java version you don't have to touch anything in java.lang. The
JVM figures out on the fly during class-loading what dispatch tables to
use. Maybe if the generic function in the bar package was defined the
"defmethod" way the same holds for the Lisp compiler or VM. However, if
the generic function was defined the "defgeneric" way, the way Anonymous
C Lisper did his, then there's a problem, because there's an explicit
dispatch table in the code instead of the compiler making one. To
frobnobdicate a quux, code belonging to the bar package would have to be
edited, and not just code belonging to the foo package (where quux
itself is).
> It merely extends the generic function, much as sublasses extend
> their parents.
In the above example, the addition of FooException does not prevent
people using the original Exception.
Extending a generic function doesn't seem to me to create two versions,
keeping the original version under the original name and adding a new
version under a different name (ala Exception and FooException).
Instead, it *changes* the generic function (frobnobdicate and
frobnobdicate). This means nobody can use the original frobnobdicate --
and every bit of code referring to it refers to the new frobnobdicate now.
Obviously, havoc would ensue if subclassing Exception caused every bit
of code using Exception to suddenly be using FooException instead.
In fact, though you repeatedly analogize extending a generic function to
subclassing, it seems to be more like editing Exception itself and
adding a new method to it. Maybe it doesn't disturb the existing code
that uses Exception (except for breaking subclasses that added a
same-named method that couldn't be either an overload or an override of
the new base-class method), but it does change something in java.lang,
and it also breaks encapsulation, big-time.
Your generic functions sound to me somewhat like data-less classes, more
like a Java interface with one method specified than like a function.
Only where Java interfaces are implemented by adding "implements Foo" to
other classes, only some Lisp generic functions are analogously
"implemented"; others, the ones defined using "defgeneric" as in
Anonymous C Lisper's post, are more like a hypothetical alternative kind
of interface that lists a method name and a list of the implementing
classes and is implemented by adding an entry to that list. It therefore
cannot be implemented without changing code used by other parts of the
project, potentially breaking things.
Seamus MacRae <··········@live.ca.nospam> writes:
> Thomas A. Russ wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
> >> ··················@gmail.com wrote:
> >
> >>> (defgeneric frobnobdicate (a b)
> >>> (:method ((foo foo) (bar bar)) ;;arguments
> >>> .. body)
> >>> (:method ((foo foo) (baz baz))
> >>> ..body))
> >>> (defclass foo () ;; no inheritance
> >>> (AttributesHere))
> >>> (defclass bar ()
> >>> (AttributesHere))
> >>> (defclass baz ()
> >>> (AttributesHere))
> >>> (defclass bat (baz) ;inherits from baz
> >>> ())
> >>> Then I can do:
> >>> (frobnobdicate InstanceOfFoo InstanceOfBar)
> >>> (frobnobdicate InstanceOfFoo InstanceOfBaz)
> >>> (frobnobdicate InstanceOfFoo InstanceOfBat)
> >> Eh, I don't see any namespace related anything in that. I do see
> >> manually managed dispatch tables and plenty of other migraine-inducers
> >> though.
> > Precisely. It doesn't enter into this at all, in most cases.
> > It is nicely in the background for when you need it, but it doesn't
> > intrude into your day-to-day programming most of the time.
>
> Except the hypothetical situation at issue was when you wanted to add a
> new dispatch for a method and the "defgeneric" dispatch-table thingie
> was not in the same namespace you want your own code to be in.
That isn't a problem. But you seem to want to argue without actually
trying to understand the technology you are arguing about. But perhaps
I'm incorrect in this assumption. In which case, I suggest that you
read about the way namespaces ("packages") in Common Lisp work:
Suffice it to say for this discussion that in order to extend a generic
function defined in another namespace, you simply need to refer to the
name of that generic function using either an import of the name or a
package qualifier, and then add whatever you want. Since namespaces in
Lisp only affect the interpretation of textual strings when mapping them
to symbols (which are used as names), you only need to qualify the
places where you need to refer to those names.
Example
(in-package :my-namespace)
(defmethod other-name-space:function-name (...arguments...)
...code...)
So, here we have added amethod to a function-name in some other
namespace without any need to futz with dispatch tables (the compiler
does that, assuming they use dispatch tables instead of some other
dispatching mechanism....) You don't need to do anything with
DEFGENERIC. You don't need to do anything at all with the other code,
other than know the name and what the generic function is supposed to
do.
> Which means that Anonymous C Lisper dodged the issue instead of
> addressing it.
>
> >> Suppose you created all of that stuff and then someone else wanted to
> >> frobnobdicate their quux objects. Now they have to mess with the
> >> defgeneric ... etc. in your namespace, in your source code...
> > Um, no.
>
> Um, yes.
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> ..body))
>
> has to become something else, I'm guessing
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> .. body)
> (:method ((foo foo) (quux quux))
> ..body))
>
>
> or something close to that, to add quux to the set of classes it
> dispatches on.
Um, no, it doesn't.
You leave the original DEFGENRIC alone and simply put
(defmethod frobnobdicate ((foo foo) (quux quux))
..body)
in your code. Since the name is the same symbol (as mediated by the
package system), this method will be associated by the lisp compiler
with the generic function.
DEFGENERIC is actually an optional declaration. All that is really
necessary is to provide definitions for the methods you want. This is
normally done via DEFMETHOD, but as a programmer convenience one can
also define methods using the :method keyword inside a defgeneric.
But those :method definitions are purely for the convenience of the
programmer, assuming they WANT to put the method definitions together
with the generic function declartion. If they don't want to do that,
they can organize the code differently and put DEFMETHODs in other
places. Or you can do both.
Flexibilty surely is a good idea, right?
> > They just add their own method by just doing
> > (defmethod frobnicate ((foo quux) (baz quux))
> > ..body)
> > and this method gets added. They do this in their own source code.
> > They don't need to do anything to your source code.
>
> That is in contradiction with how Anonymous C Lisper said it was
> done.
No. It is another way of doing the same thing. One of the strengths of
Lisp is that there are often multiple ways of doing the same thing, so
you can choose the one that best suits your style or that makes the most
sense for solving your problem. The lisp design philosophy is to
provide a wide variety of tools and trust that the programmers have been
trained to be sufficiently competent to use them wisely.
> Furthermore, the generic function frobnicate exists in *some*
> namespace. Whose?
Um, no. The only thing that exist in namespaces are names. That why
it's called a NAMEspace and not a FUNCTIONspace or some other such
thing.
The only thing that exists in a namespace is the name "frobnicate". The
generic function exists as an object in the runtime image of the lisp
system when the program is executing.
> If it's not yours, you'll either be intruding, or
> you'll be creating a parallel generic function with the same name in a
> different namespace. In the latter case, the two generic functions won't
> be compatible anymore than java.util.Date and javax.sql.Date are. You
> couldn't have x.frobnicate() (or rather, Lisp's equivalent syntax)
> dispatch to foo's frobnicate if x was a foo and to quux's if x was a
> quux; if you had imported Anonymous C Lisper's frobnicate x.frobnicate()
> would not know about quux (only foo, bar, and baz) and if you had
> imported your frobnicate x.frobnicate() would not know about foo (or bar
> or baz), only quux. In either case, it would do what you wanted for one
> type of value in x and give some sort of runtime error for the
> other. It's the same problem, except swapping nouns and verbs, as trying
> in Java to have a method whose return type was simply "Date" and then
> sometimes return a java.util.Date and sometimes a javax.sql.Date from
> it. (The best you can do is return a common supertype, in this case
> likely having to be Object.)
>
> > Perhaps you were confused because ...
>
> I will not entertain public speculation regarding my mental
> functioning. Please refrain from such. I will not respond to that kind
> of nonsense except to trim most of it when replying and make a note
> similar to this one that it is not polite behavior.
Well noting that your are confused when you are saying things about lisp
that are patently untrue is, actually, polite behavior. Or do you have
some other preferred way for me to refer to someone making statements
that are objectively false?
>
> > That is ONE way to do it, but in Lisp there are often multiple ways to
> > accomplish the same thing.
>
> And therefore a high likelihood of confusion being created, particularly
> What I've seen so far of Lisp in your posts looks like an excellent
> recipe for creating tightly-coupled code that will end up being a
> nightmare to debug and maintain in any seriously large real-world
> project. Localizing generic functions in one spot in the code causes
> code-ownership-respecting change-request bottlenecks or else people
> stepping on one another's toes. Disseminating them throughout the code
> base, on the other hand, causes the code that's affecting *your* code to
> be widely dispersed and hard to locate.
This is not any more of a problem than subclassing someone else's
class. That would have all of the same localization and coupling
issues. What the generic-function model of object-orientation does is
to extend the whole idea of class-hierarchies to functions. So if it's
a good idea for organizing classes, why isn't it a good idea for
organizing functions?
It really is just such a generalization.
> Haven't you guys ever heard of encapsulation?
Sure. Classes encapsulate data. Generic functions encapsulate
procedures. Why would one want to conflate those two different types of
abstraction and encapsulation?
...
> > Just because the solution is different from Java's solution doesn't
> > make it ineffective.
>
> No, of course not. It's the solution not scaling to large devteams that
> makes it ineffective.
Asserted without proof.
Counterexamples indicate that this is not the case.
> > See again my hammer and picnic blanket analogy for why you might want to
> > be able to do new things with existing objects.
>
> I think that analogy was already torpedoed in another post.
Hmmm. Missed it.
> > Suppose you wanted to graph a tree of objects. java.lang.Class
> > doesn't have a graph() method, and you can't add one.
>
> Fortunately for those of your coworkers who rely on its behavior.
Um, why should coworkers care if you add a method that they don't use?
How does that affect their code.
> A Java programmer create an external iterator that traverses classes
> somehow.
And does its own type dispatch, because you can't add methods that use
the built-in type dispatch. Talk about nightmares. Why would you want
to force users to do their own method dispatching, when that is
precisely what object-oriented systems were developed to do for you.
Clearly a step backwards.
> > In CLOS you just define a graph method specializing as necessary
>
> So a Lisp programmer has the option: create an external iterator that
> traverses classes somehow, or muck with a system class and thereby break
> everyone else's code in the project, thus getting the entire rest of the
> team mad at them and probably winding up fired.
First of all, you don't muck with anyone's code.
Second of all, you can't break anyone else's code by defining a new
function on a class that the other's don't use. Just like adding a new
subclass to a Java class can't break someone else's code that uses the
original class. This is the great benefit of procedural abstraction.
So, it's clear you don't understand the model of object-oriented
programming that Lisp uses.
Actually, from Paul Graham's example, you get fabulously rich...
> > It still doesn't follow that one would choose a methodology that makes
> > one or the other of these approaches MORE difficult, when one can
> > instead have a methodology where adding a noun or adding a verb are
> > equally easy.
>
> But you can't have such a methodology. There are only three possibilities:
Objectively false. Common Lisp has such a methodology. Also there are
additional possibilities beyond the three which you imagine.
> One does package.Noun.verb;
> One does package.verb(Noun);
> One does package1.verb(package2.Noun) or package1.Noun.package2.verb.
>
> The third is clearly cumbersome and difficult. Eliminate it. The first
> makes it easy to add new nouns, and new verbs to new nouns, only. The
> second makes it easy to add new verbs, and new nouns to existing verbs,
> only. So the first makes it hard to add new verbs to existing nouns and
> the second makes it hard to add new nouns to existing verbs, while the
> third makes it easy to do both but hard to USE the darn things after.
Um, how about this other option:
One does package:name
and then everything you want to name: classes, functions, structures,
tags, etc. becomes equally easy to add.
> No. I advocate choosing to make 16% harder (package.Noun.verb) over
> making 84% harder (package.verb(Noun)) or 100% harder
> (package1.verb(package2.Noun) or package1.Noun.package2.verb).
As opposed to making all 100% easy.
> >> The case at issue is when there's a pre-existing generic function with
> >> the desired name, in library code or otherwise where I couldn't fiddle
> >> with it (except as a lone-wolf hacker), and in a namespace I shouldn't
> >> put my own stuff in (except as a lone-wolf hacker).
> > Um. You are making unwarranted assumptions again.
>
> No, I am not, and you will kindly refrain from using accusatory
> expressions ("you are <something that's bad>") directed at me in your
> news posts ever again. It's extremely rude.
Well, if you will stop making unwarranted assumptions, I'll stop
pointing them out.
> > 1) You are expected to use pre-existing generic functions. That's how
> > you extend the existing library code base.
>
> The problem is that doing so leads to problems in large-team shops when
> conflicting modifications get made to basic code used systemwide. This
> is why most programming languages don't let you make any modifications
> to basic code used systemwide whatsoever. Lisp permitting such
> modifications will cause team-size scaling problems.
>
> > 2) You are NOT expected to even have access to the source code. You
> > don't need it. You shouldn't mess with it.
>
> So, the spirit of closed-source no-serviceable-parts-inside is still
> alive and well in at least one place besides Redmond, WA.
>
> > All you need to know is what the API for the generic function is.
>
> That lets you call it but not add to it. To add to the generic function
> in Anonymous C Lisper's post (the thing with the "(foo foo) (bar bar)"
> stuff in it) obviously requires its source code.
Only because you assume that he showed you the only way to do it. That
is an unwarranted assumption, since there are other ways to do it as
well.
> > That is all you need know is the signature and the semantics (the
> > latter so you know that this is actually the generic function you want).
>
> Works for generic functions. Doesn't work for macros, since little
> implementation details like the names of internally used variables in
> the macros and how many times it references one of its parameters will
> change its behavior. Without the source code, trying to debug problems
> caused by extra side effects or by collisions between your variables and
> variables inside the macro will be a nightmare.
Not if the macro is designed competently so that it only uses fresh
symbols that can't clash with anything.
> Someone else in this thread has gone into a lot more detail about this,
> posting a detailed and fairly convincing argument that some kinds of
> macros could not be implemented without the macro having at least one of
> three undesirable traits: non-reentrant and either not thread-safe or a
> concurrency bottleneck; may cause local variable name collisions; and
> may cause multiple occurrence of argument side effects.
>
> Of these, the former is a pretty big deal, and the latter two mean
> subtle bugs could arise where the macro got used that would be hard to
> figure out without access to its source code.
Well, this has already been dealt with. I'll take your words as
conceding that macros can be defined without any of those problems.
> > 3) The name already exists in the namespace, so you aren't changing the
> > namespace at all.
>
> That's sophistry. You could use the same statement to argue that
> altering the behavior of java.lang.String was not "changing" the
> java.lang namespace at all.
>
> > (BTW: Namespaces in Common Lisp are exactly
> > that. They are NAMEspaces and only concern themselves with the
> > resolution of names. They don't get overloaded with notions of
> > functions, classes, or anything extraneous like that)
>
> Java packages don't, either, save that they get their own documentation
> blurb and there's a "within this namespace only" level of access control
> between protected ("same-namespace and subclasses") and private ("this
> class and nested classes only", roughly).
>
> Of course, the latter probably mystifies you, like everything else to do
> with encapsulation.
Hmmm. Was there some comment about being rude further up?
> > 4) Assuming that you are extending the generic function in a reasonable
> > manner, for example by adding methods that dispatch on types that
> > you have defined, then there is no "lone-wolf hacker" part to this
> > at all. It is a controlled extension of the library. It is no more
> > "lone-wolf hacker" than subclassing a library class in Java would be.
>
> Subclassing a library class doesn't change the base class's
> behavior. Whereas letting anyone edit
Adding a new method doesn't change the base functions behavior on any
existing arguments. It just adds new behavior. It really is the idea
of subclassing applied to procedures and not just data abstraction.
> (foo foo) (bar bar)
> (foo foo) (baz baz)
>
> to
>
> (foo foo) (bar bar)
> (foo foo) (baz baz)
> (foo foo) (quux quux)
>
> necessarily also allows editing it to
>
> (foo foo) (mumble mumble)
> (foo foo) (baz baz)
>
> and people frobnobdicating bars elsewhere in the project getting a nasty
> surprise next time integration tests are run.
Well, sure.
But you could also redefine a class you write that everyone else depends
on and get the same effect. Common Lisp assumes that the programmers
are reasonable and that in a large project they won't engage in
malicious behavior. Any large project will have a set of procedures
that govern who does what and how they should do it.
There is a fundamental philosophical difference here. Lisp programmers
prefer the flexibility they get from their language.
> >> The hypothesis at issue is that this metaclass, or whatever, already
> >> exists and I'm not free to modify that code.
> > So far so code.
>
> This does not make sense.
Typo. Should read "So far so good."
>
> > That doesn't stop you from either creating a subclass of that library
> > class or extending the generic function by adding methods.
>
> Except that the latter is done by modifying the piece of code with the
> defgeneric thingy, at least for a nonempty subset of generic functions
> if not for all of them.
No. You just effectively add additional, more specialized methods. It
really is the analog of subclassing moved to the function speace.
> > Perhaps that is the analogy that you need to understand this. In Common
> > Lisp adding a method to a generic function is the same as creating a new
> > subclass of an existing class. It extends the generic function by
> > allowing it to apply to a new combination of method argument types.
>
> It's not the concept that concerns me. It's the actual
> mechanics. Altering the dispatch table to add something means having
> write access, which means having the ability to also alter or remove
> something, perhaps unintentionally while trying to add something. It's a
> fruitful source of breakage, it encourages tight coupling, and in some
> projects, it might even be considered a security risk.
Well, you can always redefine things is Lisp. This bothers some
programmers but is seen as a good thing by others. Tastes vary. If you
don't like this philosophy, you are perhaps not a good candiate for
programming in lisp.
> > It is, in essence, adding a dynamically dispatched "subclass" to the
> > generic function.
>
> Assuming no slips of the finger while editing the defgeneric thing, in
> cases where that's how the particular generic function is defined
> instead of that other way.
Well, the same caveat applies to creating a subclass of a class.
There's no reason to believe that this is any more error prone when
applied to functions than it is to classes.
> >>> Packages and methods are very different things.
> >> Of course they are, but methods are in packages, and packages create
> >> namespaces, and not everyone on a large project (or a typical project
> >> even) will be able to make changes to things in every namespace.
> > Methods are not in packages.
>
> This contradicts what you guys said earlier. Earlier you intimated that
> verbs (and maybe nouns AS WELL) were in namespaces.
No, only names are in namespaces. That's why they're called NAMEspaces.
> If methods really are not in packages, there goes the neighborhood. Name
> collisions are going to be causing an unbelievable amount of headaches
> in any sufficiently large project.
No, they won't. Because they are disambiguated by their names, which
are in the namespaces.
> > A Common Lisp package is simply a namespace.
>
> So is a Java package, for the most part.
>
> > It controls the mapping from surface strings to symbols.
>
> Ditto, if by that you mean "resolving non-fully-qualified names in the
> source code at compile time".
>
> (Computer science really ought to adopt a more uniform terminology for
> such common concepts.)
>
> > the package system affects only the mapping of strings to names when
> > lisp code (or data) is read.
>
> Seems to confirm the above.
>
> > Only symbols are in packages.
>
> I don't see that this is a useful distinction, between "the method is in
> the package" and "the method's name is in the package". It amounts to
> the same thing. Using Java-like syntax, as I'm more familiar with it:
Um, not really.
It is a distinction that aids in understanding the way things are done
in Lisp. But that is perhaps a foreign idea in Java, since Jave doesn't
have first class symbols in the language.
...
> > Just as you can subclass any class you like (except Java final
> > classes), you can extend any generic function in Common Lisp.
> > That doesn't change the namespace.
>
> I'm sorry, but it does. Contrast:
>
> package foo;
>
> public class FooException extends Exception { }
>
> which extends Exception (in java.lang) with FooException (in foo) and a
> hypothetical addition of a Lisp class quux to a foo package with a
> dispatch added for quuxes to a generic function in a bar package. You
> aren't just subclassing something in the bar package, you're actually
> changing the behavior of something in the bar package.
No, you aren't changing anything in the package, because the package
just manages names.
You are subclassing the behavior of the function. So that is where the
distinction between names being
> In the Java version you don't have to touch anything in java.lang. The
> JVM figures out on the fly during class-loading what dispatch tables to
> use. Maybe if the generic function in the bar package was defined the
> "defmethod" way the same holds for the Lisp compiler or VM.
Same with Common Lisp and generic functions.
> However, if
> the generic function was defined the "defgeneric" way, the way Anonymous
> C Lisper did his, then there's a problem, because there's an explicit
> dispatch table in the code instead of the compiler making one. To
> frobnobdicate a quux, code belonging to the bar package would have to be
> edited, and not just code belonging to the foo package (where quux
> itself is).
Um, no there is not explicit dispatch table in the code. You are
reading something into the syntactic sugar that isn't there.
The two ways of defining methods are just syntactic variants. They
actually operate the same way under the hood. In other words
(defgeneric f (...)
(:method (args) ....)
(:method (other-args) ...))
Is exactly the same, functionally, as
(defgeneric f (...))
(defmethod f (args) ...)
(defmethod f (other-args) ...)
> > It merely extends the generic function, much as sublasses extend
> > their parents.
>
> In the above example, the addition of FooException does not prevent
> people using the original Exception.
Nor does adding a new method stop people from using the existing methods.
> Extending a generic function doesn't seem to me to create two versions, keeping the original version under the original name and adding a new version under a different name (ala Exception and FooException). Instead, it *changes* the generic function (frobnobdicate and frobnobdicate). This means nobody can use the original frobnobdicate --
> and every bit of code referring to it refers to the new frobnobdicate now.
>
> Obviously, havoc would ensue if subclassing Exception caused every bit
> of code using Exception to suddenly be using FooException instead.
The generic function doesn't change.
Only the methods change.
> In fact, though you repeatedly analogize extending a generic function to
> subclassing, it seems to be more like editing Exception itself and
> adding a new method to it. Maybe it doesn't disturb the existing code
> that uses Exception (except for breaking subclasses that added a
> same-named method that couldn't be either an overload or an override of
> the new base-class method), but it does change something in java.lang,
> and it also breaks encapsulation, big-time.
No, the new method only applies to the situation dictated by the type
dispatch on its arguments. Any existing methods are still there.
The closer analogy in Java would be
class A {
f ();
}
class B extends A {
}
Now if one were to subsequently edit the second class definition so that
it now looks like
class B extends A {
f ();
}
Is that changing the meaning of the method f on A? It will certainly
change the behavior of anyone who uses B instances, since they will now
have a different method executed than before the change.
That the same as in common lisp having
(defclass A ())
(defclass B (A))
(defmethod f ((arg1 A)))
and then adding a new method
(defmethod f ((arg1 B)))
> Your generic functions sound to me somewhat like data-less classes, more
> like a Java interface with one method specified than like a
> function. Only where Java interfaces are implemented by adding
> "implements Foo" to other classes, only some Lisp generic functions are
> analogously "implemented"; others, the ones defined using "defgeneric"
> as in Anonymous C Lisper's post, are more like a hypothetical
> alternative kind of interface that lists a method name and a list of the
> implementing classes and is implemented by adding an entry to that
> list. It therefore cannot be implemented without changing code used by
> other parts of the project, potentially breaking things.
Um, yes it can, because the grouping is purely a convenience abbreviation.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Thomas A. Russ wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> ··················@gmail.com wrote:
>>>>> (defgeneric frobnobdicate (a b)
>>>>> (:method ((foo foo) (bar bar)) ;;arguments
>>>>> .. body)
>>>>> (:method ((foo foo) (baz baz))
>>>>> ..body))
>>>>> (defclass foo () ;; no inheritance
>>>>> (AttributesHere))
>>>>> (defclass bar ()
>>>>> (AttributesHere))
>>>>> (defclass baz ()
>>>>> (AttributesHere))
>>>>> (defclass bat (baz) ;inherits from baz
>>>>> ())
>>>>> Then I can do:
>>>>> (frobnobdicate InstanceOfFoo InstanceOfBar)
>>>>> (frobnobdicate InstanceOfFoo InstanceOfBaz)
>>>>> (frobnobdicate InstanceOfFoo InstanceOfBat)
>>>> Eh, I don't see any namespace related anything in that. I do see
>>>> manually managed dispatch tables and plenty of other migraine-inducers
>>>> though.
>>> Precisely. It doesn't enter into this at all, in most cases.
>>> It is nicely in the background for when you need it, but it doesn't
>>> intrude into your day-to-day programming most of the time.
>> Except the hypothetical situation at issue was when you wanted to add a
>> new dispatch for a method and the "defgeneric" dispatch-table thingie
>> was not in the same namespace you want your own code to be in.
>
> That isn't a problem.
The recurrent mantra of a Lisp acolyte.
In the real world, of course, repeating such mantras will not magically
make real, actual problems go away.
> But you seem to want to argue without actually trying to understand
> the technology you are arguing about.
Not true. Furthermore, a tired old debating trick, changing the subject
from whatever it originally was to one's own opponent and making things
personal.
Nobody with an IQ over 80 falls for that sort of lameness. Shame on you
for insulting everyone's intelligence by even trying!
> But perhaps I'm incorrect in this assumption.
No "perhaps" about it.
>>>> Suppose you created all of that stuff and then someone else wanted to
>>>> frobnobdicate their quux objects. Now they have to mess with the
>>>> defgeneric ... etc. in your namespace, in your source code...
>>> Um, no.
>> Um, yes.
>>
>> (defgeneric frobnobdicate (a b)
>> (:method ((foo foo) (bar bar)) ;;arguments
>> .. body)
>> (:method ((foo foo) (baz baz))
>> ..body))
>>
>> has to become something else, I'm guessing
>>
>> (defgeneric frobnobdicate (a b)
>> (:method ((foo foo) (bar bar)) ;;arguments
>> .. body)
>> (:method ((foo foo) (baz baz))
>> .. body)
>> (:method ((foo foo) (quux quux))
>> ..body))
>>
>> or something close to that, to add quux to the set of classes it
>> dispatches on.
>
> [calls me a liar]
No, you're the liar. I made a straightforward extrapolation from the
originally-posted code, which cannot possibly be wrong unless there's
some horrible special-casing for when there are more than two, or
exactly three, or some such, dispatches.
Yet if there IS such horrible special-casing, then I STILL win, on my
larger point that this whole thing is a god-awful mess.
Checkmate.
>>> They just add their own method by just doing
>>> (defmethod frobnicate ((foo quux) (baz quux))
>>> ..body)
>>> and this method gets added. They do this in their own source code.
>>> They don't need to do anything to your source code.
>> That is in contradiction with how Anonymous C Lisper said it was
>> done.
>
> [calls me a liar]
No, no, no! I've told you repeatedly that I am not. Don't you listen?
>> Furthermore, the generic function frobnicate exists in *some*
>> namespace. Whose?
>
> [calls me a liar]
This is getting tiresome.
>>> Perhaps you were confused because ...
>> I will not entertain public speculation regarding my mental
>> functioning. Please refrain from such. I will not respond to that kind
>> of nonsense except to trim most of it when replying and make a note
>> similar to this one that it is not polite behavior.
>
> Well noting that your are confused [rest deleted]
I will not entertain public speculation regarding my mental
functioning. Please refrain from such. I will not respond to that kind
of nonsense except to trim most of it when replying and make a note
similar to this one that it is not polite behavior.
>> What I've seen so far of Lisp in your posts looks like an excellent
>> recipe for creating tightly-coupled code that will end up being a
>> nightmare to debug and maintain in any seriously large real-world
>> project. Localizing generic functions in one spot in the code causes
>> code-ownership-respecting change-request bottlenecks or else people
>> stepping on one another's toes. Disseminating them throughout the code
>> base, on the other hand, causes the code that's affecting *your* code to
>> be widely dispersed and hard to locate.
>
> This is not any more of a problem than subclassing someone else's
> class.
I had previously explained why it was one. It's kind of like that, but
in a hypothetical OO system where instead of
class X { void method ... }
class Y extends X { void method ... }
you instead had
class X extended-by Y { void method ... }
class Y { void method ... }
and to add your own class Z, you had to edit the declaration of class X.
Someone else's class X.
> That would have all of the same localization and coupling
> issues.
But not the changing-someone-else's-code issues.
>> Haven't you guys ever heard of encapsulation?
>
> Sure.
Then why don't you *use* it?!
>>> Just because the solution is different from Java's solution doesn't
>>> make it ineffective.
>> No, of course not. It's the solution not scaling to large devteams that
>> makes it ineffective.
>
> [calls me a liar]
Oh, how tiresome.
>>> See again my hammer and picnic blanket analogy for why you might want to
>>> be able to do new things with existing objects.
>> I think that analogy was already torpedoed in another post.
>
> Hmmm. Missed it.
Incoherent.
>>> Suppose you wanted to graph a tree of objects. java.lang.Class
>>> doesn't have a graph() method, and you can't add one.
>> Fortunately for those of your coworkers who rely on its behavior.
>
> Um, why should coworkers care if you add a method that they don't use?
> How does that affect their code.
Suppose your change to Class violated invariants that used to hold, and
that their code relied upon?
Suppose it was an interface, adding to which broke their code that
implemented it? (Bad enough that you can break code by editing your own
interfaces -- Sun recently did this, and there's a recent thread in cljp
about it; they added a method to a database interface that broke
someone's code, who complained there and of course it spawned a huge debate.
>> A Java programmer create an external iterator that traverses classes
>> somehow.
>
> And does its own type dispatch, because you can't add methods that use
> the built-in type dispatch. Talk about nightmares.
The alternative was apparently worse; indeed, too horrible to contemplate.
>>> In CLOS you just define a graph method specializing as necessary
>> So a Lisp programmer has the option: create an external iterator that
>> traverses classes somehow, or muck with a system class and thereby break
>> everyone else's code in the project, thus getting the entire rest of the
>> team mad at them and probably winding up fired.
>
> First of all, you don't muck with anyone's code.
See above.
> Second of all, you can't break anyone else's code by defining a new
> function on a class that the other's don't use.
And on a class that they do use?
> Just like adding a new subclass to a Java class can't break someone
> else's code that uses the original class.
Not if that class was designed right, with the protected and private
keywords used appropriately and the subclass therefore unable to muck
with the superclass's invariants.
Oops. Common Lisp has no concept of protected. Or private. Game over.
> So, it's clear you don't understand ...
I will not entertain public speculation regarding my mental
functioning. Please refrain from such. I will not respond to that kind
of nonsense except to trim most of it when replying and make a note
similar to this one that it is not polite behavior.
>>> It still doesn't follow that one would choose a methodology that makes
>>> one or the other of these approaches MORE difficult, when one can
>>> instead have a methodology where adding a noun or adding a verb are
>>> equally easy.
>> But you can't have such a methodology. There are only three possibilities:
>
> [calls me a liar]
Tiresome, tiresome, tiresome.
>> One does package.Noun.verb;
>> One does package.verb(Noun);
>> One does package1.verb(package2.Noun) or package1.Noun.package2.verb.
>>
>> The third is clearly cumbersome and difficult. Eliminate it. The first
>> makes it easy to add new nouns, and new verbs to new nouns, only. The
>> second makes it easy to add new verbs, and new nouns to existing verbs,
>> only. So the first makes it hard to add new verbs to existing nouns and
>> the second makes it hard to add new nouns to existing verbs, while the
>> third makes it easy to do both but hard to USE the darn things after.
>
> Um, how about this other option:
>
> One does package:name
>
> and then everything you want to name: classes, functions, structures,
> tags, etc. becomes equally easy to add.
That's just sneaking number three in through the back door. You mention
classes, structures, atc. AND functions. So it's
package1.verb(package2.Noun) then, modulo differences in syntax and
capitalization conventions.
>> No. I advocate choosing to make 16% harder (package.Noun.verb) over
>> making 84% harder (package.verb(Noun)) or 100% harder
>> (package1.verb(package2.Noun) or package1.Noun.package2.verb).
>
> As opposed to making all 100% easy.
Which is not possible. (No namespacing at all creates its own new nasty
class of pain. Try developing in Squeak some time. The lack of
namespaces for classes is *painful*, leading to collisions AND very long
class names that attempt to avoid them, usually by adding
poor-man's-namespaces in the form of long common prefixes in related
classes' names, which in turn would play hell with name completion if
the in-built editor HAD name completion ...
>>>> The case at issue is when there's a pre-existing generic function with
>>>> the desired name, in library code or otherwise where I couldn't fiddle
>>>> with it (except as a lone-wolf hacker), and in a namespace I shouldn't
>>>> put my own stuff in (except as a lone-wolf hacker).
>>> Um. You are making unwarranted assumptions again.
>> No, I am not, and you will kindly refrain from using accusatory
>> expressions ("you are <something that's bad>") directed at me in your
>> news posts ever again. It's extremely rude.
>
> Well, if you will stop making unwarranted assumptions
Wrong answer.
>>> All you need to know is what the API for the generic function is.
>> That lets you call it but not add to it. To add to the generic function
>> in Anonymous C Lisper's post (the thing with the "(foo foo) (bar bar)"
>> stuff in it) obviously requires its source code.
>
> Only because you assume [rest deleted]
See above re: making things personal.
>>> That is all you need know is the signature and the semantics (the
>>> latter so you know that this is actually the generic function you want).
>> Works for generic functions. Doesn't work for macros, since little
>> implementation details like the names of internally used variables in
>> the macros and how many times it references one of its parameters will
>> change its behavior. Without the source code, trying to debug problems
>> caused by extra side effects or by collisions between your variables and
>> variables inside the macro will be a nightmare.
>
> Not if the macro is designed competently so that it only uses fresh
> symbols that can't clash with anything.
Series Expansion did an excellent job of explaining how that's
mathematically impossible for any conceivable lexical macro system,
short of one whose expansion-generation functions can employ a halting
oracle. (That Lisp macros operate upon trees rather than linear text
does not make a material difference to his arguments.)
>> Of these, the former is a pretty big deal, and the latter two mean
>> subtle bugs could arise where the macro got used that would be hard to
>> figure out without access to its source code.
>
> Well, this has already been dealt with.
By calling people names and then sticking your head in the sand. That
doesn't do ostriches much good, from what I've heard, and I doubt it
will avail you of much, either.
> I'll take your words as conceding that macros can be defined without
> any of those problems.
How dishonest of you. I concede no such thing, of course.
>>> (BTW: Namespaces in Common Lisp are exactly
>>> that. They are NAMEspaces and only concern themselves with the
>>> resolution of names. They don't get overloaded with notions of
>>> functions, classes, or anything extraneous like that)
>> Java packages don't, either, save that they get their own documentation
>> blurb and there's a "within this namespace only" level of access control
>> between protected ("same-namespace and subclasses") and private ("this
>> class and nested classes only", roughly).
>>
>> Of course, the latter probably mystifies you, like everything else to do
>> with encapsulation.
>
> Hmmm. Was there some comment about being rude further up?
A comment about turnabout being fair play seems appropriate here.
>>> 4) Assuming that you are extending the generic function in a reasonable
>>> manner, for example by adding methods that dispatch on types that
>>> you have defined, then there is no "lone-wolf hacker" part to this
>>> at all. It is a controlled extension of the library. It is no more
>>> "lone-wolf hacker" than subclassing a library class in Java would be.
>> Subclassing a library class doesn't change the base class's
>> behavior. Whereas letting anyone edit
>
> Adding a new method doesn't change the base functions behavior on any
> existing arguments.
Already addressed; see above.
>> (foo foo) (bar bar)
>> (foo foo) (baz baz)
>>
>> to
>>
>> (foo foo) (bar bar)
>> (foo foo) (baz baz)
>> (foo foo) (quux quux)
>>
>> necessarily also allows editing it to
>>
>> (foo foo) (mumble mumble)
>> (foo foo) (baz baz)
>>
>> and people frobnobdicating bars elsewhere in the project getting a nasty
>> surprise next time integration tests are run.
>
> Well, sure.
Well, there's the inevitable victory for my side, then.
> Common Lisp assumes that the programmers are reasonable and that in a
> large project they won't engage in malicious behavior.
Accidents are more my concern.
Suppose whoever went to turn
(foo foo) (bar bar)
(foo foo) (baz baz)
into
(foo foo) (bar bar)
(foo foo) (quux quux)
(foo foo) (baz baz)
fat-fingered the ) key, which is next to ', and got:
(foo foo) (bar bar)
(foo foo) (quux quux)'
(foo foo) (baz baz)
instead? Likely this will quote the (foo foo) form on the next line,
with who knows what consequences. Given the lack of typing in CL, the
result will probably be run-time problems with code that previously
worked flawlessly and used the (foo foo) (baz baz) dispatch, rather than
a build failure with an error message pointing very close to the site of
the typo.
Of course, when just about everyone might have to add to that dispatch
table, a typo like that becomes increasingly likely in the long run.
Whereas if the table is edited only by one coder that "owns" it that
coder becomes, as was previously discussed, a bottleneck in the project,
somewhat like having a too-coarse-grained lock in concurrent code losing
you most of the performance benefits of parallelism.
> Any large project will have a set of procedures
> that govern who does what and how they should do it.
Bottleneck alert. (Did you know that coarse grained locks may also be
more prone to deadlock? They're held longer and more likely to overlap
in time.)
> There is a fundamental philosophical difference here.
That much is clear, and it seems your philosophy has no place in large
professional software development projects.
>>>> The hypothesis at issue is that this metaclass, or whatever, already
>>>> exists and I'm not free to modify that code.
>>> So far so code.
>> This does not make sense.
>
> Typo.
Excuses, excuses.
>>> That doesn't stop you from either creating a subclass of that library
>>> class or extending the generic function by adding methods.
>> Except that the latter is done by modifying the piece of code with the
>> defgeneric thingy, at least for a nonempty subset of generic functions
>> if not for all of them.
>
> No.
Yes, unless you're calling both me and Anonymous C. Lisper liars.
>>> Perhaps that is the analogy that you need to understand this. In Common
>>> Lisp adding a method to a generic function is the same as creating a new
>>> subclass of an existing class. It extends the generic function by
>>> allowing it to apply to a new combination of method argument types.
>> It's not the concept that concerns me. It's the actual
>> mechanics. Altering the dispatch table to add something means having
>> write access, which means having the ability to also alter or remove
>> something, perhaps unintentionally while trying to add something. It's a
>> fruitful source of breakage, it encourages tight coupling, and in some
>> projects, it might even be considered a security risk.
>
> Well, you can always redefine things is Lisp.
Kaboom!
> Tastes vary.
Yes, and when one of your coworkers has a taste for haggis or balut, the
whole work environment suffers.
>>> It is, in essence, adding a dynamically dispatched "subclass" to the
>>> generic function.
>> Assuming no slips of the finger while editing the defgeneric thing, in
>> cases where that's how the particular generic function is defined
>> instead of that other way.
>
> Well, the same caveat applies to creating a subclass of a class.
Not quite the same. See above, once again.
>>>>> Packages and methods are very different things.
>>>> Of course they are, but methods are in packages, and packages create
>>>> namespaces, and not everyone on a large project (or a typical project
>>>> even) will be able to make changes to things in every namespace.
>>> Methods are not in packages.
>> This contradicts what you guys said earlier. Earlier you intimated that
>> verbs (and maybe nouns AS WELL) were in namespaces.
>
> [calls me a liar]
How tiresome.
>> If methods really are not in packages, there goes the neighborhood. Name
>> collisions are going to be causing an unbelievable amount of headaches
>> in any sufficiently large project.
>
> [calls me a liar]
*yawn*
>>> Only symbols are in packages.
>> I don't see that this is a useful distinction, between "the method is in
>> the package" and "the method's name is in the package". It amounts to
>> the same thing. Using Java-like syntax, as I'm more familiar with it:
>
> Um, not really.
No, really, I used a Java-like syntax because I'm more familiar with it.
Truly I did!
>>> Just as you can subclass any class you like (except Java final
>>> classes), you can extend any generic function in Common Lisp.
>>> That doesn't change the namespace.
>> I'm sorry, but it does. Contrast:
>>
>> package foo;
>>
>> public class FooException extends Exception { }
>>
>> which extends Exception (in java.lang) with FooException (in foo) and a
>> hypothetical addition of a Lisp class quux to a foo package with a
>> dispatch added for quuxes to a generic function in a bar package. You
>> aren't just subclassing something in the bar package, you're actually
>> changing the behavior of something in the bar package.
>
> [calls me a liar]
ZZZzzzzzz ...
>> In the Java version you don't have to touch anything in java.lang. The
>> JVM figures out on the fly during class-loading what dispatch tables to
>> use. Maybe if the generic function in the bar package was defined the
>> "defmethod" way the same holds for the Lisp compiler or VM.
>
> Same with Common Lisp and generic functions.
No, not really, because of the explicit dispatch tables.
>> However, if
>> the generic function was defined the "defgeneric" way, the way Anonymous
>> C Lisper did his, then there's a problem, because there's an explicit
>> dispatch table in the code instead of the compiler making one. To
>> frobnobdicate a quux, code belonging to the bar package would have to be
>> edited, and not just code belonging to the foo package (where quux
>> itself is).
>
> [calls me and Anonymous C. Lisper liars]
I don't know about him, but I know I'm not one.
>>> It merely extends the generic function, much as sublasses extend
>>> their parents.
>> In the above example, the addition of FooException does not prevent
>> people using the original Exception.
>
> Nor does adding a new method stop people from using the existing methods.
I'm not analogizing with the method but with the whole generic function.
Editing it replaces it with a different one, rather than creating an
extension that has a different name and extended abilities and
*coexists* with the previous version, unlike extending a Java class.
>> Extending a generic function doesn't seem to me to create two versions, keeping the original version under the original name and adding a new version under a different name (ala Exception and FooException). Instead, it *changes* the generic function (frobnobdicate and frobnobdicate). This means nobody can use the original frobnobdicate --
>> and every bit of code referring to it refers to the new frobnobdicate now.
>>
>> Obviously, havoc would ensue if subclassing Exception caused every bit
>> of code using Exception to suddenly be using FooException instead.
>
> The generic function doesn't change.
Sure it does. Methods are added to it. Adding methods to Java classes
and (especially) interfaces can cause havoc. The same will be true of
generic functions.
>> In fact, though you repeatedly analogize extending a generic function to
>> subclassing, it seems to be more like editing Exception itself and
>> adding a new method to it. Maybe it doesn't disturb the existing code
>> that uses Exception (except for breaking subclasses that added a
>> same-named method that couldn't be either an overload or an override of
>> the new base-class method), but it does change something in java.lang,
>> and it also breaks encapsulation, big-time.
>
> No
You've gotten into a very bad habit of calling me a liar every paragraph
or two. Please cease and desist. Thank you.
> The closer analogy in Java would be
>
> class A {
> f ();
> }
>
> class B extends A {
> }
We've *been* through this already, and I've already explained why that's
not quite true.
Sheesh!
>> Your generic functions sound to me somewhat like data-less classes, more
>> like a Java interface with one method specified than like a
>> function. Only where Java interfaces are implemented by adding
>> "implements Foo" to other classes, only some Lisp generic functions are
>> analogously "implemented"; others, the ones defined using "defgeneric"
>> as in Anonymous C Lisper's post, are more like a hypothetical
>> alternative kind of interface that lists a method name and a list of the
>> implementing classes and is implemented by adding an entry to that
>> list. It therefore cannot be implemented without changing code used by
>> other parts of the project, potentially breaking things.
>
> [calls me a liar]
Figures.
Signal terminated.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>>> Only symbols are in packages.
>> I don't see that this is a useful distinction, between "the method is
>> in the package" and "the method's name is in the package". It amounts
>> to the same thing.
>
> Really?
Yes.
> So if I run a prize-draw where everyone writes their name on
> a piece of paper and we put the papers in a box and draw the winner at
> random...that's exactly the same as putting all the /people/ in the
> box? :)
No.
There is a world of difference between a Common Lisp package and a box,
and between Common Lisp and a prize-draw.
On May 22, 8:28 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
>
> >>> Only symbols are in packages.
> >> I don't see that this is a useful distinction, between "the method is
> >> in the package" and "the method's name is in the package". It amounts
> >> to the same thing.
>
> > Really?
>
> Yes.
>
> > So if I run a prize-draw where everyone writes their name on
> > a piece of paper and we put the papers in a box and draw the winner at
> > random...that's exactly the same as putting all the /people/ in the
> > box? :)
>
> No.
>
> There is a world of difference between a Common Lisp package and a box,
> and between Common Lisp and a prize-draw.
Shame on Seamus.
If you're drawing on Star Wars metaphors, let me quote this to you:
"Why do you persist, Mr Anderson?"
Paul Foley's analogy is clear: a package is a package of designators,
not a package of things. If you don't understand it, then before you
go about talking about qualifying this and qualifying that, you should
probably go and qualify yourself.
- Adlai
Adlai wrote:
> On May 22, 8:28 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>> Only symbols are in packages.
>>>> I don't see that this is a useful distinction, between "the method is
>>>> in the package" and "the method's name is in the package". It amounts
>>>> to the same thing.
>>> Really?
>> Yes.
>>
>>> So if I run a prize-draw where everyone writes their name on
>>> a piece of paper and we put the papers in a box and draw the winner at
>>> random...that's exactly the same as putting all the /people/ in the
>>> box? :)
>> No.
>>
>> There is a world of difference between a Common Lisp package and a box,
>> and between Common Lisp and a prize-draw.
>
> Shame on Seamus.
No.
> If you're drawing on Star Wars metaphors, let me quote this to you:
> "Why do you persist, Mr Anderson?"
That was not from Star Wars, it was from The Matrix.
Do you expect me to take you seriously when you can't even get *that* right?
Seamus MacRae <··········@live.ca.nospam> writes:
> Adlai wrote:
>
> > If you're drawing on Star Wars metaphors, let me quote this to you:
> > "Why do you persist, Mr Anderson?"
>
> That was not from Star Wars, it was from The Matrix.
>
> Do you expect me to take you seriously when you can't even get *that* right?
Are you now advancing "getting things right" as a criterion for
credibility? Fascinating, in an ironic sort of way.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 22, 12:23 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
> > Adlai wrote:
>
> > > If you're drawing on Star Wars metaphors, let me quote this to you:
> > > "Why do you persist, Mr Anderson?"
>
> > That was not from Star Wars, it was from The Matrix.
>
> > Do you expect me to take you seriously when you can't even get *that* right?
>
> Are you now advancing "getting things right" as a criterion for
> credibility? Fascinating, in an ironic sort of way.
More insults behind peoples' backs. What is the matter with you?
On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>>> Only symbols are in packages.
>>> I don't see that this is a useful distinction, between "the method is
>>> in the package" and "the method's name is in the package". It amounts
>>> to the same thing.
>>
>> Really?
>
> Yes.
The above distinction isn't the true one. Yes, symbols are names, and reside
in packages. But they reside in packages by means of names of their own.
The distintion is this: "the method's name is in the package" versus
"the method name's name is in the package".
In Lisp there is a significant difference between "what is something's name"
versus "what is something's name called".
In some languages, a name is some compile-time identifier, which is resolved in
some package, and then from there we arrive straight at an entity like a type,
function or variable. The package itself /has/ functions, classes, et cetera.
A Lisp package contains entries which map identifiers to symbols. The symbols
themselves are names for things, but that is irrelevant the package system.
Symbols are not identifers in the sense of a character string like "foo". They
identify by means of their unique identities, which are addresses in the
machine's address space.
A naming system in which entities have names that are symbols, and in which
these symbols in turn have their own names which are character strings keyed
into a package, is different from a naming system in which things have names
that are identifiers in a package.
Kaz Kylheku wrote:
> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>
>>>>> Only symbols are in packages.
>>>> I don't see that this is a useful distinction, between "the method is
>>>> in the package" and "the method's name is in the package". It amounts
>>>> to the same thing.
>>> Really?
>> Yes.
>
> The above distinction isn't the true one.
I don't take kindly to people that call me a liar.
[rest of post deleted]
Treat me with respect next time you want me to pay any attention to what
you are saying.
On May 15, 7:22 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
[...]
> On the much more frequent occasion I wanted to
> add a new noun, I'd often be forced to change verbs that lived in
> pre-existing namespaces, and maybe even in more than one namespace; the
> code for my new noun would be scattered all over the codebase AND the
> namespaces within the system, rather than in exactly one place in each.
This, at least, is a potential problem, but in practice it's never
caused me any difficulty. Lisp development environments are quite
helpful when it comes to locating method definitions wherever they
might be.
> There's also going to be big differences in polymorphism. With an object
> oriented system, nouns can be subtypes of other nouns, and verb behavior
> can be inherited, with or without modification.
Same in Common Lisp. Classes can inherit from other classes, and
generic functions dispatch on the run-time class, respecting
inheritance relationships.
[...]
> If I created my Complex
> class and implemented Addable, code that did generic sums over Addables
> would automatically also work with Complex now. I wouldn't have to make
> any changes outside the Complex class.
> With Lisp, I'd need to change the system namespace's plus verb's
> dispatch table manually so that it knew about my Complex class, on the
> other hand.
Not at all. The necessary modification of the generic function is
handled automatically (really, CLOS would be remarkably useless if it
weren't) when you define the new method.
And there's no problem defining methods from one namespace on classes
from another namespace. You need to be able to do this to add methods
for user-defined classes to built-in generic functions (like PRINT-
OBJECT or INITIALIZE-INSTANCE).
> With Java I'd just have to define the implementations, naming them
> correctly, and stick "implements Number" somewhere and away I'd go.
In Common Lisp, you'd just write the four method definitions; you
wouldn't even have to mention the "implements Number" part.
[...]
Cheers,
Pillsy
On May 15, 9:50 pm, Pillsy <·········@gmail.com> wrote:
> On May 15, 7:22 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > On the much more frequent occasion I wanted to
> > add a new noun, I'd often be forced to change verbs that lived in
> > pre-existing namespaces, and maybe even in more than one namespace; the
> > code for my new noun would be scattered all over the codebase AND the
> > namespaces within the system, rather than in exactly one place in each.
>
> This, at least, is a *potential* problem, but in *practice* it's never
> caused me any difficulty. [emphasis mine]
My God, what a bunch of Pollyannas.
On May 15, 10:54 pm, Dangling Pointer <·········@gmail.com> wrote:
> On May 15, 9:50 pm, Pillsy <·········@gmail.com> wrote:
> > On May 15, 7:22 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > > On the much more frequent occasion I wanted to
> > > add a new noun, I'd often be forced to change verbs that lived in
> > > pre-existing namespaces, and maybe even in more than one namespace; the
> > > code for my new noun would be scattered all over the codebase AND the
> > > namespaces within the system, rather than in exactly one place in each.
> > This, at least, is a *potential* problem, but in *practice* it's never
> > caused me any difficulty. [emphasis mine]
> My God, what a bunch of Pollyannas.
My God, what an uninteresting rebutal.
Cheers,
Pillsy
Pillsy wrote:
> On May 15, 7:22 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> [...]
>> On the much more frequent occasion I wanted to
>> add a new noun, I'd often be forced to change verbs that lived in
>> pre-existing namespaces, and maybe even in more than one namespace; the
>> code for my new noun would be scattered all over the codebase AND the
>> namespaces within the system, rather than in exactly one place in each.
>
> This, at least, is a potential problem, but in practice it's never
> caused me any difficulty.
*deep sigh*
> Lisp development environments are quite
> helpful when it comes to locating method definitions wherever they
> might be.
What development environments? That curses-based museumstrosity you were
evangelizing half an hour ago? Surely ye jest?
>> There's also going to be big differences in polymorphism. With an object
>> oriented system, nouns can be subtypes of other nouns, and verb behavior
>> can be inherited, with or without modification.
>
> Same in Common Lisp. Classes can inherit from other classes, and
> generic functions dispatch on the run-time class, respecting
> inheritance relationships.
Inheritance relationships recorded where? Lisp seems to take a
Java-esque class and explode it, scattering bits of it all across the
codebase and maybe hiding some bits up its sleeve for good measure.
>> With Lisp, I'd need to change the system namespace's plus verb's
>> dispatch table manually so that it knew about my Complex class, on the
>> other hand.
>
> Not at all. The necessary modification of the generic function is
> handled automatically (really, CLOS would be remarkably useless if it
> weren't) when you define the new method.
You mean, the source code for a dispatch table you posted is
machine-generated, like yacc output? No wonder it looks like ... well,
what a lay person will probably imagine "yacc output" describes. ;)
I hate machine-generated code. I hatehateHATE having to *maintain*
machine-generated code. (Object code and .class files notwithstanding.)
It's always a mess, and you're always tempted to fix something in it
directly, and then the next time make runs, all your changes go bye-bye
as the code generator blithely overwrites every last byte of 'em.
Keeping it somewhat prettified is a Sisyphean task, since the boulder
rolls back down every time anyone builds that part of the codebase.
Finding the file that it's generated from can be a nuisance.
That's with bison parsers and Matisse GUIs and crap like that. Your Lisp
dispatch thingies (generic functions, did you say?) must get built from
snippets scattered all over the damn place. Finding all the code that
generates those must be nigh-impossible.
> And there's no problem defining methods from one namespace on classes
> from another namespace.
What about using the darn things? Let me guess, "there's no problem", by
which is meant "it is physically possible, though you'll need a few
tablets of Excedrin afterward and might want to save up a few sick days
first".
> You need to be able to do this to add methods
> for user-defined classes to built-in generic functions (like PRINT-
> OBJECT or INITIALIZE-INSTANCE).
Such a pain, when Java lets you just go
public class MyWhatsit {
@Override
public String toString () {
return "I'm a MyWhatsit!";
}
}
sticking this in your own namespace and not monkeying with any other
code anywhere (either manually, or by running some sort of
code-generator), yet if a MyWhatsit is subsequently passed to e.g.
String.valueOf(Object), out pops "I'm a MyWhatsit!".
It ain't real polymorphism until you can do that, *without* scribbling
outside the lines around the box your code is in.
>> With Java I'd just have to define the implementations, naming them
>> correctly, and stick "implements Number" somewhere and away I'd go.
>
> In Common Lisp, you'd just write the four method definitions; you
> wouldn't even have to mention the "implements Number" part.
Duck-typing? Well, it beats no typing at all I suppose.
Eh, wait a minute, you'd write the four method definitions and then run
that code-generator thingy to generate the new versions of the dispatch
tables.
Er, how does that code-generator resolve conflicts again? If someone
else makes a class, also calls it Complex, implements it differently
(r-theta instead of x-y say), and writes methods with the same four
names? Does it use the package the Complex class is in to keep the two
versions of each separate?
On May 15, 11:10 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > On May 15, 7:22 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
[...]
> >> On the much more frequent occasion I wanted to
> >> add a new noun, I'd often be forced to change verbs that lived in
> >> pre-existing namespaces, and maybe even in more than one namespace; the
> >> code for my new noun would be scattered all over the codebase AND the
> >> namespaces within the system, rather than in exactly one place in each.
> > This, at least, is a potential problem, but in practice it's never
> > caused me any difficulty.
> *deep sigh*
What? A mix of commonly used idioms, coding practices and tool support
allow you to avoid a potential problem when writing programs. That's a
pretty common state of affairs in software development.
> > Lisp development environments are quite
> > helpful when it comes to locating method definitions wherever they
> > might be.
> What development environments? That curses-based museumstrosity you were
> evangelizing half an hour ago? Surely ye jest?
No, Emacs + SLIME has convenient features for locating method
definitions in their source files. Just because the interface looks a
like something out of 1983 doesn't mean it doesn't work well.
> >> There's also going to be big differences in polymorphism. With an object
> >> oriented system, nouns can be subtypes of other nouns, and verb behavior
> >> can be inherited, with or without modification.
> > Same in Common Lisp. Classes can inherit from other classes, and
> > generic functions dispatch on the run-time class, respecting
> > inheritance relationships.
> Inheritance relationships recorded where?
In the class definition...? If I want to say that FOO is a subclass of
BAR, I just write
(defclass foo (bar)
;; This space for rent!.
)
[...]
> >> With Lisp, I'd need to change the system namespace's plus verb's
> >> dispatch table manually so that it knew about my Complex class, on the
> >> other hand.
> > Not at all. The necessary modification of the generic function is
> > handled automatically (really, CLOS would be remarkably useless if it
> > weren't) when you define the new method.
> You mean, the source code for a dispatch table you posted is
> machine-generated, like yacc output?
No, I mean, you never see any of it. All you do is write the message
definition and compile it and you're done, since methods can be added
or changed at run-time.
[...]
> I hate machine-generated code.
So do I. It's a very good thing that you don't have to use it to use
CLOS.
[...]
> Your Lisp
> dispatch thingies (generic functions, did you say?) must get built from
> snippets scattered all over the damn place. Finding all the code that
> generates those must be nigh-impossible.
You select the name of the generic function, hit Alt-., and a list
pops up listing all the methods for the generic function and their
classes. Then you click on the one you want, and you're taken to the
definition. It's really, really similar to looking up definitions in
Eclipse.
> > And there's no problem defining methods from one namespace on classes
> > from another namespace.
> What about using the darn things?
You just... use them?
> Let me guess, "there's no problem", by
> which is meant "it is physically possible, though you'll need a few
> tablets of Excedrin afterward and might want to save up a few sick days
> first".
No, I mean, "there's no problem", by which is meant that I can't even
figure out what problem you might be referring to.
> > You need to be able to do this to add methods
> > for user-defined classes to built-in generic functions (like PRINT-
> > OBJECT or INITIALIZE-INSTANCE).
> Such a pain, when Java lets you just go
> public class MyWhatsit {
> @Override
> public String toString () {
> return "I'm a MyWhatsit!";
> }
>
> }
> sticking this in your own namespace and not monkeying with any other
> code anywhere (either manually, or by running some sort of
> code-generator), yet if a MyWhatsit is subsequently passed to e.g.
> String.valueOf(Object), out pops "I'm a MyWhatsit!".
I'm really not seeing much difference between that and
(defclass my-whatsit () ())
(defmethod print-object ((object my-whatsit) stream)
(print-unreadable-object (obj stream)
(format stream "I'm a whatsit!")))
That's all you have to do. No monkeying with any other code anywhere
else. No code generation.
Neither fuss nor muss.
[...]
> >> With Java I'd just have to define the implementations, naming them
> >> correctly, and stick "implements Number" somewhere and away I'd go.
> > In Common Lisp, you'd just write the four method definitions; you
> > wouldn't even have to mention the "implements Number" part.
> Duck-typing? Well, it beats no typing at all I suppose.
> Eh, wait a minute, you'd write the four method definitions and then run
> that code-generator thingy to generate the new versions of the dispatch
> tables.
No, you write the four method definitions and then compile them. All
the machinery for doing the dispatch is handled by the Lisp
implementation transparently.
Cheers,
Pillsy
[...]
Pillsy wrote:
> On May 15, 11:10 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>
>> Pillsy wrote:
>
>>> On May 15, 7:22 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> [...]
>>>> On the much more frequent occasion I wanted to
>>>> add a new noun, I'd often be forced to change verbs that lived in
>>>> pre-existing namespaces, and maybe even in more than one namespace; the
>>>> code for my new noun would be scattered all over the codebase AND the
>>>> namespaces within the system, rather than in exactly one place in each.
>
>>> This, at least, is a potential problem, but in practice it's never
>>> caused me any difficulty.
>
>> *deep sigh*
>
> What?
Every time a serious problem is mentioned, you tend to dismiss it with
little more than a hand-wave. A can-do attitude is good to have, but
here it's verging on Pollyanna. You're liable to trip and pitch
headfirst down a six-hundred-foot chasm while staring up at the pretty
blue sky if you carry on like that.
>>> Lisp development environments are quite
>>> helpful when it comes to locating method definitions wherever they
>>> might be.
>
>> What development environments? That curses-based museumstrosity you were
>> evangelizing half an hour ago? Surely ye jest?
>
> No, Emacs + SLIME has convenient features for locating method
> definitions in their source files. Just because the interface looks a
> like something out of 1983 doesn't mean it doesn't work well.
I'm sure it does, by 1983 standards.
Call me when you've got a flying DeLorean and then we'll talk.
(It still beats vi and Windows Vista. Vista looks like something out of
1984. The book, that is.)
>>> Same in Common Lisp. Classes can inherit from other classes, and
>>> generic functions dispatch on the run-time class, respecting
>>> inheritance relationships.
>
>> Inheritance relationships recorded where?
>
> In the class definition...? If I want to say that FOO is a subclass of
> BAR, I just write
>
> (defclass foo (bar)
> ;; This space for rent!.
> )
Yet earlier someone was saying you'd omit to specify that Complex
inherited from Number.
This is absolutely fascinating. Now you're actually becoming visibly
incoherent. The next step I suppose is overt verbal violence, followed
eventually by a Hitler comparison, and then mass kill-filings.
>>> Not at all. The necessary modification of the generic function is
>>> handled automatically (really, CLOS would be remarkably useless if it
>>> weren't) when you define the new method.
>
>> You mean, the source code for a dispatch table you posted is
>> machine-generated, like yacc output?
>
> No, I mean, you never see any of it.
Oh, lovely. Machine-generated code you can't even find and read? It's
annoying enough to get bison-generated code to play nice with version
control. Your phantom dispatch tables are going to bedevil any serious
developer until his hair falls out and his nose gets all wrinkly.
>> I hate machine-generated code.
>
> So do I. It's a very good thing that you don't have to use it to use
> CLOS.
But ... but ... but ... but you just ...
Oh, aren't you the clever troll!
>> Your Lisp
>> dispatch thingies (generic functions, did you say?) must get built from
>> snippets scattered all over the damn place. Finding all the code that
>> generates those must be nigh-impossible.
>
> You select the name of the generic function, hit Alt-., and a list
> pops up listing all the methods for the generic function and their
> classes. Then you click on the one you want, and you're taken to the
> definition. It's really, really similar to looking up definitions in
> Eclipse.
You assume people are using some particular tool, with a fairly decent
interface, that I ain't never heard of. From all indications, a straw
poll here would show most of the other lispers to be using emacs or
something else equally primitive, though, and there might also be issues
with getting such a tool to work with different dialects of Lisp reliably.
>>> And there's no problem defining methods from one namespace on classes
>>> from another namespace.
>
>> What about using the darn things?
>
> You just... use them?
Limp. Very limp.
>> Let me guess, "there's no problem", by
>> which is meant "it is physically possible, though you'll need a few
>> tablets of Excedrin afterward and might want to save up a few sick days
>> first".
>
> No, I mean, "there's no problem", by which is meant that I can't even
> figure out what problem you might be referring to.
Fully-qualifying the fuckin' names! What the hell else could I be
referring to? :P
>>> You need to be able to do this to add methods
>>> for user-defined classes to built-in generic functions (like PRINT-
>>> OBJECT or INITIALIZE-INSTANCE).
>
>> Such a pain, when Java lets you just go
>
>> public class MyWhatsit {
>> @Override
>> public String toString () {
>> return "I'm a MyWhatsit!";
>> }
>>
>> }
>
>> sticking this in your own namespace and not monkeying with any other
>> code anywhere (either manually, or by running some sort of
>> code-generator), yet if a MyWhatsit is subsequently passed to e.g.
>> String.valueOf(Object), out pops "I'm a MyWhatsit!".
>
> I'm really not seeing much difference between that and
>
> (defclass my-whatsit () ())
>
> (defmethod print-object ((object my-whatsit) stream)
> (print-unreadable-object (obj stream)
> (format stream "I'm a whatsit!")))
>
> That's all you have to do. No monkeying with any other code anywhere
> else. No code generation.
Let me guess: no MANUAL code generation. Something in the toolchain does
it for you.
That's not quite the same thing. And there's no namespace-related stuff
in your code. OK, there was none in mine, either, but you can just slap
a "package foo;" at the top of it. Whereas yours requires you to
defmethod the pre-existing, in some widely used namespace, print-object
method, with who knows what potential risks if you screw it up.
Oh yeah, I forgot: you're perfect and simply will not ever screw it up.
Ever. :P
>>>> With Java I'd just have to define the implementations, naming them
>>>> correctly, and stick "implements Number" somewhere and away I'd go.
>
>>> In Common Lisp, you'd just write the four method definitions; you
>>> wouldn't even have to mention the "implements Number" part.
That was you! It's your own previous post you contradicted up there by
putting explicit subtyping declarations into some of your example code.
>> Duck-typing? Well, it beats no typing at all I suppose.
>
>> Eh, wait a minute, you'd write the four method definitions and then run
>> that code-generator thingy to generate the new versions of the dispatch
>> tables.
>
> No, you write the four method definitions and then compile them. All
> the machinery for doing the dispatch is handled by the Lisp
> implementation transparently.
Like a C++ vtable, then, except that you (or a bug in your code) can
screw with the vtables for objects from the standard library, the
vtables for MY objects, ...
On May 16, 3:19 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > On May 15, 11:10 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> >> Pillsy wrote:
[...]
> >>> This, at least, is a potential problem, but in practice it's never
> >>> caused me any difficulty.
> >> *deep sigh*
> > What?
> Every time a serious problem is mentioned, you tend to dismiss it with
> little more than a hand-wave.
One thing I've discovered is that the things I think are going to be
problems when I start learning a language (or don't know it at all
yet) end up being pretty different from the things that I actually
learn are problems after working with it for a while.
[...]
> >> What development environments? That curses-based museumstrosity you were
> >> evangelizing half an hour ago? Surely ye jest?
> > No, Emacs + SLIME has convenient features for locating method
> > definitions in their source files. Just because the interface looks a
> > like something out of 1983 doesn't mean it doesn't work well.
> I'm sure it does, by 1983 standards.
No, I mean, by 2009 standards. It just looks a little crufty.
[...]
> >> Inheritance relationships recorded where?
> > In the class definition...? If I want to say that FOO is a subclass of
> > BAR, I just write
> > (defclass foo (bar)
> > ;; This space for rent!.
> > )
> Yet earlier someone was saying you'd omit to specify that Complex
> inherited from Number.
I might, but if I wanted it to inherit from Number, I could certainly
choose to have it inherit from Number. I'm just not sure that's the
way to go from a design standpoint, though admittedly I haven't
thought about the question a whole lot..
In truth of fact, in Common Lisp, the built-in COMPLEX class actually
does inherit from the built-in NUMBER class.
[...]
> >> You mean, the source code for a dispatch table you posted is
> >> machine-generated, like yacc output?
> > No, I mean, you never see any of it.
> Oh, lovely. Machine-generated code you can't even find and read?
Well, I guess that's one way of describing compilation...? Still, it
strikes me as kind of a perverse one.
> It's annoying enough to get bison-generated code to play nice
> with version control.
Do you version-control object files and executables? That seems like
strange behavior to me.
[...]
> > You select the name of the generic function, hit Alt-., and a list
> > pops up listing all the methods for the generic function and their
> > classes. Then you click on the one you want, and you're taken to the
> > definition. It's really, really similar to looking up definitions in
> > Eclipse.
> You assume people are using some particular tool, with a fairly decent
> interface, that I ain't never heard of. From all indications, a straw
> poll here would show most of the other lispers to be using emacs or
> something else equally primitive, though, and there might also be issues
> with getting such a tool to work with different dialects of Lisp reliably.
The tool I was describing in that paragraph is called... Emacs.
[...]
> >> Let me guess, "there's no problem", by
> >> which is meant "it is physically possible, though you'll need a few
> >> tablets of Excedrin afterward and might want to save up a few sick days
> >> first".
> > No, I mean, "there's no problem", by which is meant that I can't even
> > figure out what problem you might be referring to.
> Fully-qualifying the fuckin' names! What the hell else could I be
> referring to? :P
Oh, no, most of the time, you can just use both packages (i.e.,
namespaces) in the package you're working in without having to fully
qualify anything. If there are clashes, you can specify which package
you want to use for a given unqualified name, and qualify the other
one.
[...]
> >> Such a pain, when Java lets you just go
> >> public class MyWhatsit {
> >> @Override
> >> public String toString () {
> >> return "I'm a MyWhatsit!";
> >> }
> >> }
> >> sticking this in your own namespace and not monkeying with any other
> >> code anywhere (either manually, or by running some sort of
> >> code-generator), yet if a MyWhatsit is subsequently passed to e.g.
> >> String.valueOf(Object), out pops "I'm a MyWhatsit!".
> > I'm really not seeing much difference between that and
> > (defclass my-whatsit () ())
> > (defmethod print-object ((object my-whatsit) stream)
> > (print-unreadable-object (obj stream)
> > (format stream "I'm a whatsit!")))
> > That's all you have to do. No monkeying with any other code anywhere
> > else. No code generation.
> Let me guess: no MANUAL code generation. Something in the toolchain does
> it for you.
Well, like I said, in Lisp we have this thing called a compiler.
Perhaps you've heard of them...?
> That's not quite the same thing. And there's no namespace-related stuff
> in your code. OK, there was none in mine, either, but you can just slap
> a "package foo;" at the top of it.
And I could just slap
(defpackage #:foo (:use #:cl))
at the top of mine.
> Whereas yours requires you to
> defmethod the pre-existing, in some widely used namespace, print-object
> method, with who knows what potential risks if you screw it up.
I know what potential risks. The potential risks are that something
could go wrong when you try to print an instance of MY-WHATSIT.
[...]
> >>> In Common Lisp, you'd just write the four method definitions; you
> >>> wouldn't even have to mention the "implements Number" part.
> That was you! It's your own previous post you contradicted up there by
> putting explicit subtyping declarations into some of your example code.
Yes, it was. Whether you decide to inherit or not is a matter of
choice.
[...]
> >> Eh, wait a minute, you'd write the four method definitions and then run
> >> that code-generator thingy to generate the new versions of the dispatch
> >> tables.
> > No, you write the four method definitions and then compile them. All
> > the machinery for doing the dispatch is handled by the Lisp
> > implementation transparently.
> Like a C++ vtable, then, except that you (or a bug in your code) can
> screw with the vtables for objects from the standard library, the
> vtables for MY objects, ...
Well, no. I could muck with the dispatch tables for the generic
functions in the standard library, but unless we're using a bizarrely
crappy and bug-ridded implementation, that won't hurt you any. The
methods you've defined on YOUR-WHATSIT will be invoked on YOUR-
WHATSIT, the methods I've defined on MY-WHATSIT will be invoked on MY-
WHATSIT, and there won't be any interference between the too.
Cheers,
Pillsy
"Seamus MacRae" wrote:
>> This is absolutely fascinating. Now you're actually becoming visibly
>> incoherent. The next step I suppose is overt verbal violence, followed
>> eventually by a Hitler comparison, and then mass kill-filings.
Well, "Seamus" invoked Godwin's Law here. This post got through before my
plonk, but it sure makes me glad I've started "mass kill-filing" him already.
>> Fully-qualifying the fuckin' names! What the hell else could I be
>> referring to? :P
And now "Seamus" goes all potty-mouth on us. He must really have some logic
behind his points for him to do that, eh?
--
Lew
Lew wrote:
> "Seamus MacRae" wrote:
>>> This is absolutely fascinating. Now you're actually becoming visibly
>>> incoherent. The next step I suppose is overt verbal violence,
>>> followed eventually by a Hitler comparison, and then mass kill-filings.
>
> Well, "Seamus" invoked Godwin's Law here. This post got through before
> my plonk, but it sure makes me glad I've started "mass kill-filing" him
> already.
>
>>> Fully-qualifying the fuckin' names! What the hell else could I be
>>> referring to? :P
>
> And now "Seamus" goes all potty-mouth on us. He must really have some
> logic behind his points for him to do that, eh?
Does this outpouring of nastiness serve any purpose in this debate, or
are you just being a lout and spoiling everyone else's fun in a bid for
attention or some such stupidity?
Pillsy wrote:
> On May 16, 3:19 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
>> Pillsy wrote:
>
>>> On May 15, 11:10 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Pillsy wrote:
> [...]
>>>>> This, at least, is a potential problem, but in practice it's never
>>>>> caused me any difficulty.
>
>>>> *deep sigh*
>
>>> What?
>
>> Every time a serious problem is mentioned, you tend to dismiss it with
>> little more than a hand-wave.
>
> One thing I've discovered is that the things I think are going to be
> problems when I start learning a language (or don't know it at all
> yet) end up being pretty different from the things that I actually
> learn are problems after working with it for a while.
This statement is also little more than a hand-wave. In a way it's even
less convincing than many of the other non-evidence-based arguments
against what I've said, in that it's entirely subjective.
>>>> What development environments? That curses-based museumstrosity you were
>>>> evangelizing half an hour ago? Surely ye jest?
>
>>> No, Emacs + SLIME has convenient features for locating method
>>> definitions in their source files. Just because the interface looks a
>>> like something out of 1983 doesn't mean it doesn't work well.
>
>> I'm sure it does, by 1983 standards.
>
> No, I mean, by 2009 standards. It just looks a little crufty.
"A little" crufty? Nevermind looks -- it also feels (more than) a little
crufty, like trying to drive a real full-size automobile using one of
those little gadgets for commanding radio-controlled toy cars*.
Well, emacs does, and I doubt there's anything that adding SLIME to
emacs can do to change that.
* James Bond did this in at least one movie. I wouldn't recommend that
any lesser man ever attempt it.
>>>> Inheritance relationships recorded where?
>
>>> In the class definition...? If I want to say that FOO is a subclass of
>>> BAR, I just write
>
>>> (defclass foo (bar)
>>> ;; This space for rent!.
>>> )
>
>> Yet earlier someone was saying you'd omit to specify that Complex
>> inherited from Number.
>
> I might, but if I wanted it to inherit from Number, I could certainly
> choose to have it inherit from Number. I'm just not sure that's the
> way to go from a design standpoint, though admittedly I haven't
> thought about the question a whole lot..
Taking it as a given that Complex should be a subtype of Number, how
else would you go about doing it?
Well, actually, I don't suppose that even makes sense. CLOS apparently
has a notion of subclass, but to have a notion of subTYPE you kind of
need, well, types. Subclassing Number lets you have Complex values
assignable to Number variables in Java. Since everything is assignable
to every variable in Lisp, this consideration goes away, and just having
both implement plus methods will let you use them interchangeably in
code using plus on variables.
So the lack of static typing saves you a little bit of work coding your
type system. You still ought to think through your type system, even if
your type system will be completely invisible to the compiler, or your
program won't work. And penny you saved writing "extends Number;" or its
equivalent up front is owed with interest down the line, as a dollar
spent debugging run-time errors to the effect "String does not
understand the method: plus".
> In truth of fact, in Common Lisp, the built-in COMPLEX class actually
> does inherit from the built-in NUMBER class.
I hate all-caps names, except on final static fields where they belong.
>>>> You mean, the source code for a dispatch table you posted is
>>>> machine-generated, like yacc output?
>
>>> No, I mean, you never see any of it.
>
>> Oh, lovely. Machine-generated code you can't even find and read?
>
> Well, I guess that's one way of describing compilation...?
This wasn't compilation; this was "defgeneric" forms generated by
something. (Macros?)
Anyway, if you "never see any of it" why did we all see that
(foo foo) (bar bar)
(foo foo) (baz baz)
stuff from Anonymous C Lisper's post a while back? Were we all
hallucinating, or is it not actually true that we NEVER see any of it?
>> It's annoying enough to get bison-generated code to play nice
>> with version control.
>
> Do you version-control object files and executables? That seems like
> strange behavior to me.
Bison generates C source files.
>>> You select the name of the generic function, hit Alt-., and a list
>>> pops up listing all the methods for the generic function and their
>>> classes. Then you click on the one you want, and you're taken to the
>>> definition. It's really, really similar to looking up definitions in
>>> Eclipse.
>
>> You assume people are using some particular tool, with a fairly decent
>> interface, that I ain't never heard of. From all indications, a straw
>> poll here would show most of the other lispers to be using emacs or
>> something else equally primitive, though, and there might also be issues
>> with getting such a tool to work with different dialects of Lisp reliably.
>
> The tool I was describing in that paragraph is called... Emacs.
You mean, there are two programs with the same name that are otherwise
as different as night and day? That's going to cause a lot of confusion.
Who thought this was a great idea? Bayer?
>>>> Let me guess, "there's no problem", by
>>>> which is meant "it is physically possible, though you'll need a few
>>>> tablets of Excedrin afterward and might want to save up a few sick days
>>>> first".
>
>>> No, I mean, "there's no problem", by which is meant that I can't even
>>> figure out what problem you might be referring to.
>
>> Fully-qualifying the fuckin' names! What the hell else could I be
>> referring to? :P
>
> Oh, no, most of the time, you can just use both packages (i.e.,
> namespaces) in the package you're working in without having to fully
> qualify anything. If there are clashes,
and there will be,
> you can specify which package you want to use for a given unqualified
> name, and qualify the other one.
What a nightmare. With Java, you just import java.util.List; and then
use List, List.add(), List.remove(), and so on. You would have us
separately import List, add, remove, and so on and then when we had List
and Set to use together, fully qualify one of List.add() and Set.add()
(since your Lisp add wouldn't "belong" to either List or Set, but to its
own top-level namespace).
It's as if instead of:
import java.util.List;
import java.util.Set;
List var1 = getList();
var1.add(x);
var1.remove(y);
Set var2 = getSet();
var2.add(x);
var2.remove(y);
we had to write:
import java.util.List;
import java.util.List.add;
import java.util.List.remove;
import java.util.Set;
List var1 = getList();
var1.add(x);
var1.remove(y);
Set var2 = getSet();
var2.java.util.Set.add(x);
var2.java.util.Set.remove(y);
Oh my fucking God I think I'm going to throw up.
Java's compiler is smart enough to know which add you mean by the type
of the expression to the left. Lisp's compiler obviously wouldn't have a
fucking clue what type either var1 or var2 will be at runtime -- they
could be Lists, Sets, cons cells, integers, or Christ alone knows what
else. So it doesn't know what add to use on var1, the one for lists, the
one for sets, or some other.
Option 1: generic "add" function. Now who owns the
(list list) (list list)
(set set) (set set)
stuff that dispatches it? Who gets read/write access to it? What happens
if someone fucks it up while trying to add another collection type?
Option 2: create separate "add" functions, necessarily in separate
namespaces.
Then we get the horror of the code up above with all of the extra
imports and qualifications, or rather their Lisp analogues.
>>>> Such a pain, when Java lets you just go
>
>>>> public class MyWhatsit {
>>>> @Override
>>>> public String toString () {
>>>> return "I'm a MyWhatsit!";
>>>> }
>
>>>> }
>
>>>> sticking this in your own namespace and not monkeying with any other
>>>> code anywhere (either manually, or by running some sort of
>>>> code-generator), yet if a MyWhatsit is subsequently passed to e.g.
>>>> String.valueOf(Object), out pops "I'm a MyWhatsit!".
>
>>> I'm really not seeing much difference between that and
>
>>> (defclass my-whatsit () ())
>
>>> (defmethod print-object ((object my-whatsit) stream)
>>> (print-unreadable-object (obj stream)
>>> (format stream "I'm a whatsit!")))
>
>>> That's all you have to do. No monkeying with any other code anywhere
>>> else. No code generation.
>
>> Let me guess: no MANUAL code generation. Something in the toolchain does
>> it for you.
>
> Well, like I said, in Lisp we have this thing called a compiler.
> Perhaps you've heard of them...?
The compiler compiles the
(foo foo) (bar bar)
(foo foo) (baz baz)
stuff, but what generates it? Apparently sometimes it's done manually.
Other times you've suggested it's auto-generated somehow, perhaps by
Lisp macros. Regardless, it gets modified to add a dispatch for
print-object. If it is modified manually, someone with write access to
that part of the code has to do the modification. Either everyone gets
this (and we get a train wreck) or one person does (and we get a
bottleneck). On the other hand, if it is macro-generated, anyone can
invoke macros that modify it (to add their own print-object dispatches,
say), and anyone can therefore invoke macros that potentially screw it
up, which puts us squarely back in train-wreck territory.
>> That's not quite the same thing. And there's no namespace-related stuff
>> in your code. OK, there was none in mine, either, but you can just slap
>> a "package foo;" at the top of it.
>
> And I could just slap
>
> (defpackage #:foo (:use #:cl))
>
> at the top of mine.
Which will do what? Put your print-object there? But print-object is in
a system namespace of some sort. If this makes your print-object and its
dispatch in foo, you can't call (print-object x) and get your
print-object for x a my-whatsit and the standard print-object for x an
integer, say. You need to call either foo's print-object or the system
print-object on x, so you need x to be only ever a my-whatsit or else
only ever something else. And without static types, it will be difficult
to see if the code is correct, and impossible for the compiler to check
it for you, regarding the type of x.
If, instead, it makes your print-object or its dispatch in the system
package, you've just monkeyed with the system package.
If, instead, it MOVES print-object to foo from the system package, an
awful lot of code is about to break spectacularly.
>> Whereas yours requires you to
>> defmethod the pre-existing, in some widely used namespace, print-object
>> method, with who knows what potential risks if you screw it up.
>
> I know what potential risks. The potential risks are that something
> could go wrong when you try to print an instance of MY-WHATSIT.
Changing the generic function, whether by hand or macro, means the
potential to make changes other than simple additions, either
intentionally or by accident.
> Yes, it was. Whether you decide to inherit or not is a matter of
> choice.
What use is inheritance then? You have no encapsulation. You have no
type system to speak of, as far as what can be in what variables and
what can be invoked on what. Just add Complex without a superclass, add
a dispatch to the plus generic function for Complexes, and call (plus x
y) with Complexes or with Numbers. Apparently saying that Complex
inherits from Number buys you nothing, except that maybe the edit to the
dispatch table is done by some macro instead of by hand, a very-arguable
slight reduction in the risk of mangling said dispatch table.
>>> No, you write the four method definitions and then compile them. All
>>> the machinery for doing the dispatch is handled by the Lisp
>>> implementation transparently.
>
>> Like a C++ vtable, then, except that you (or a bug in your code) can
>> screw with the vtables for objects from the standard library, the
>> vtables for MY objects, ...
>
> Well, no.
Well, yes. Returning to Anonymous C Lisper's frobnobdicate, if I can add
a dispatch to it, then I can screw with it. If I can add a dispatch to
print-object I can screw with print-object. And so forth.
> I could muck with the dispatch tables for the generic
> functions in the standard library, but unless we're using a bizarrely
> crappy and bug-ridded implementation, that won't hurt you any.
Impossible. If you can manually add (foo foo) (bar bar) to the thing you
can delete from it or otherwise edit it. If you can invoke a macro that
adds to it you can (define and then) invoke a macro that deletes from it
or otherwise edits it. (The deleting or other editing may be
unintentional, perhaps when trying to add something.)
> The methods you've defined on YOUR-WHATSIT will be invoked on YOUR-
> WHATSIT, the methods I've defined on MY-WHATSIT will be invoked on MY-
> WHATSIT, and there won't be any interference between the too.
Unless an error is made in your or my code.
But what are the odds of that, right?
["Followup-To:" header set to comp.lang.lisp.]
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
>> On May 16, 3:19 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>
>>> Pillsy wrote:
>>
>>>> On May 15, 11:10 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> Pillsy wrote:
>> [...]
>>>>>> This, at least, is a potential problem, but in practice it's never
>>>>>> caused me any difficulty.
>>
>>>>> *deep sigh*
>>
>>>> What?
>>
>>> Every time a serious problem is mentioned, you tend to dismiss it with
>>> little more than a hand-wave.
>>
>> One thing I've discovered is that the things I think are going to be
>> problems when I start learning a language (or don't know it at all
>> yet) end up being pretty different from the things that I actually
>> learn are problems after working with it for a while.
>
> This statement is also little more than a hand-wave. In a way it's even
> less convincing than many of the other non-evidence-based arguments
> against what I've said, in that it's entirely subjective.
>
>>>>> What development environments? That curses-based museumstrosity you were
>>>>> evangelizing half an hour ago? Surely ye jest?
>>
>>>> No, Emacs + SLIME has convenient features for locating method
>>>> definitions in their source files. Just because the interface looks a
>>>> like something out of 1983 doesn't mean it doesn't work well.
>>
>>> I'm sure it does, by 1983 standards.
>>
>> No, I mean, by 2009 standards. It just looks a little crufty.
>
> "A little" crufty? Nevermind looks -- it also feels (more than) a little
> crufty, like trying to drive a real full-size automobile using one of
> those little gadgets for commanding radio-controlled toy cars*.
>
> Well, emacs does, and I doubt there's anything that adding SLIME to
> emacs can do to change that.
>
> * James Bond did this in at least one movie. I wouldn't recommend that
> any lesser man ever attempt it.
>
>>>>> Inheritance relationships recorded where?
>>
>>>> In the class definition...? If I want to say that FOO is a subclass of
>>>> BAR, I just write
>>
>>>> (defclass foo (bar)
>>>> ;; This space for rent!.
>>>> )
>>
>>> Yet earlier someone was saying you'd omit to specify that Complex
>>> inherited from Number.
>>
>> I might, but if I wanted it to inherit from Number, I could certainly
>> choose to have it inherit from Number. I'm just not sure that's the
>> way to go from a design standpoint, though admittedly I haven't
>> thought about the question a whole lot..
>
> Taking it as a given that Complex should be a subtype of Number, how
> else would you go about doing it?
Are you asking about implementation strategies about how to add
this ANSI CL feature to Seamus MacRae Imaginary Lisp.
> Well, actually, I don't suppose that even makes sense. CLOS apparently
> has a notion of subclass, but to have a notion of subTYPE you kind of
> need, well, types.
Not really. Class and type are only an implementation distinction that
exists in languages for historic reasons. E.g. C++ has ``basic types''
and ``class types''. Lisp is the same way. Originally, everything had
type. When OO was introduced in the 1980's, eventually, everything
had a class as well.
What is the class of 3?
[2]> (class-of 3)
#<BUILT-IN-CLASS INTEGER>
What is the type of 3?
[3]> (type-of 3)
(INTEGER 0 16777215)
Class is understood to be a type concept related to participation in the object
system. Built-in things like symbols and numbers have both type and class. If
you don't want to use OO in your design, you can largely ignore that objects
have class.
A class object's type and class are the same thing:
(defclass foo () ())
(type-of (make-instance 'foo)) -> foo
Are complex numbers a subtype of numbers?
(subtypep 'number 'complex) -> T ;; Yes!
> assignable to Number variables in Java. Since everything is assignable
> to every variable in Lisp, this consideration goes away, and just having
> both implement plus methods will let you use them interchangeably in
> code using plus on variables.
>
> So the lack of static typing saves you a little bit of work coding your
> type system.
Lack of static typing saves work in the type system too? Wow. It does not only
saved work in the non-type-system parts of the program!
> You still ought to think through your type system, even if
There isn't a Lisp macro called THINK which will do this for you,
but I hear they are working on it.
> your type system will be completely invisible to the compiler, or your
> program won't work. And penny you saved writing "extends Number;" or its
> equivalent up front is owed with interest down the line, as a dollar
> spent debugging run-time errors to the effect "String does not
> understand the method: plus".
You keep asking people for rational evidence. Where is your rational
evidence that these errors are such a threat?
I agree that there is a nonzero probability that you will be
confronted with an error like ``foo does not understand the method bar''.
The questions are:
1. How much of a threat is this? Can we quantify this risk in numbers?
I.e. if we eliminate the problem, what is the benefit?
How important is this compared to all other risks facing the
development of this software?
2. What are the costs of preventing this problem with static typing?
Are there risks, and what are they?
You are asserting that there are no costs, or risks, only benefits,
as if you could banish type mismatch errors with static typing in such a way
that all else remains equal.
Don't accuse others of having no rational evidence, if you haven't
properly done the cost/benefit analysis.
People who have actual years of experience with dynamic typing find that the
actual threat from type mismatch errors is small compared to the inconvenience
of working with static typing.
>> In truth of fact, in Common Lisp, the built-in COMPLEX class actually
>> does inherit from the built-in NUMBER class.
>
> I hate all-caps names, except on final static fields where they belong.
Of course, you'd normally just write number and complex in your Lisp program,
but you can write in caps also. In discussion threads in the Lisp newsgroup, we
find it very useful to write symbol names in caps, because it's typographically
clear that the word is a symbol.
If fonts could be used, we could write COMPLEX in lower case letters instead,
but use a typewriter font.
The Lisp reader is configurable with respect to case treatment in symbol names.
The default behavior is to fold everything to upper case, for historic reasons.
So Foo, FoO, fOO, foo and FOO all denote the symbol object whose name is the
character string "FOO". The default behavior in the Lisp printer (also
customizeable) is to print the symbol as FOO.
>>>>> You mean, the source code for a dispatch table you posted is
>>>>> machine-generated, like yacc output?
>>
>>>> No, I mean, you never see any of it.
>>
>>> Oh, lovely. Machine-generated code you can't even find and read?
>>
>> Well, I guess that's one way of describing compilation...?
>
> This wasn't compilation; this was "defgeneric" forms generated by
> something. (Macros?)
Macros are a part of compilation.
What is the difference between, say:
synchronized (obj) { ... code .. }
and
(synchronized obj ... code ...)
Java's synchronized block construct is a de facto macro. The difference is
that it's hard-wired into the compiler. The compiler recognizes the
synchronized keyword and parses the construct into some kind of tree into which
it inserts monitor enter and leave calls, and a try/finally.
Lisp lets the programmer assign custom code transforming actions to symbols, so
the compiler is extended as part of the program. Thus we can write our own
synchronized block construct. This is done by writing a macro.
A macro does, in Lisp, exactly that which in another language
would be done by adding a new phrase structure rule to the
parser, along with a syntax-directed-translation action
to go with that rule.
A Lisp macro is even compiled to native code, so that it
runs fast at compile time.
The difference is that you don't have to rebuild the compiler to integrate this
custom syntax. It's just something that is defined in the program. The custom
syntax doesn't create any ambiguities in the grammar. It's denoted by a symbol.
The symbol can be put into a package. You are not adding a new reserved keyword
like ``synchronized'' to the language.
Lisp even has local macros restricted to a lexical scope.
>>> It's annoying enough to get bison-generated code to play nice
>>> with version control.
>>
>> Do you version-control object files and executables? That seems like
>> strange behavior to me.
>
> Bison generates C source files.
The point is that the C generated by bison is a derived object, not
a primary file.
The generated code isn't ``source''. The source is what is maintained
in the .y file.
So, there is the view that the generated code doesn't belong in version control.
You're having problems with Bison and version control because you have no clue
what should go into version control and what shouldn't.
>> The tool I was describing in that paragraph is called... Emacs.
>
> You mean, there are two programs with the same name that are otherwise
> as different as night and day?
I saw elsewhere in this thread that you were shown a screenshot of Emacs and
you still denied it was Emacs.
The only Emacs is Seamus MacRae Imaginary Emacs. Anything else is a lie
that someone made up, complete with fake screenshots created with
an image editor.
> The compiler compiles the
>
> (foo foo) (bar bar)
> (foo foo) (baz baz)
>
> stuff, but what generates it? Apparently sometimes it's done manually.
> Other times you've suggested it's auto-generated somehow, perhaps by
> Lisp macros. Regardless, it gets modified to add a dispatch for
> print-object.
An organized reference manual for Seamus MacRae Lisp would be helpful,
instead of the collage assembled from these fleeting glimpses of
what it is about.
Kaz Kylheku wrote:
> ["Followup-To:" header set to comp.lang.lisp.]
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> I might, but if I wanted it to inherit from Number, I could certainly
>>> choose to have it inherit from Number. I'm just not sure that's the
>>> way to go from a design standpoint, though admittedly I haven't
>>> thought about the question a whole lot..
>> Taking it as a given that Complex should be a subtype of Number, how
>> else would you go about doing it?
>
> Are you asking about implementation strategies about how to add
> this ANSI CL feature to Seamus MacRae Imaginary Lisp.
No; there's no such thing as SMIL anyway. I was asking Pillsy to clarify
something that he wrote, and how he would do something. And since you're
not Pillsy, it is very odd for you to jump in at this point.
>> Well, actually, I don't suppose that even makes sense. CLOS apparently
>> has a notion of subclass, but to have a notion of subTYPE you kind of
>> need, well, types.
>
> Not really.
Yes really.
> Lisp is the same way. Originally, everything had type.
In Lisp? Surely you jest. At base, it has no static types and precious
few dynamic ones (integer, maybe a few other numerics, cons cell,
string, symbol, nil, and little else).
> Are complex numbers a subtype of numbers?
>
> (subtypep 'number 'complex) -> T ;; Yes!
This seems to be checking some programmed-in notion of types, not
compile-time types of any kind. You could program this behavior in any
language.
>> assignable to Number variables in Java. Since everything is assignable
>> to every variable in Lisp, this consideration goes away, and just having
>> both implement plus methods will let you use them interchangeably in
>> code using plus on variables.
>>
>> So the lack of static typing saves you a little bit of work coding your
>> type system.
>
> Lack of static typing saves work in the type system too?
Maybe a bit. At the cost of lots of debugging later on, in big enough
systems.
>> You still ought to think through your type system, even if
>
> There isn't a Lisp macro called THINK which will do this for you
I meant *think*. With your head! Maybe a bit of a foreign concept to you?
>> your type system will be completely invisible to the compiler, or your
>> program won't work. And penny you saved writing "extends Number;" or its
>> equivalent up front is owed with interest down the line, as a dollar
>> spent debugging run-time errors to the effect "String does not
>> understand the method: plus".
>
> You keep asking people for rational evidence. Where is your rational
> evidence that these errors are such a threat?
I have stated it repeatedly. You keep ignoring it.
> I agree that there is a nonzero probability that you will be
> confronted with an error like ``foo does not understand the method bar''.
Well, there we are. I guess we are now in agreement.
So why am I still apparently only 1/3 of the way through your
interminably long post?
> 1. How much of a threat is this? Can we quantify this risk in numbers?
Easy: what would have been caught in seconds at compile time, or even
instantly in the IDE when editing (red squiggly underlines: another
feature untranslatable to a box of pure ASCII), instead isn't caught
until run-time and possibly far from the true location of the error.
Seconds of debugging becomes minutes at best, hours at worst.
Say the downside is 30 minutes.
Now note that type errors are an estimated 30% of bugs. So nearly 10
minutes per bug, total, saved with static types.
> 2. What are the costs of preventing this problem with static typing?
A bit more up-front keyboard typing. Maybe more thought as to what
should be what and going where during design and coding, but that will
pay off as an investment down the line.
> Are there risks, and what are they?
There's a risk you won't be able to mischievously sneak a Float into a
group of Strings...
> You are asserting that there are no costs, or risks, only benefits,
No, I am not. I am asserting that they balance out in favor of static
typing.
> Don't accuse others of having no rational evidence
Then get some and post it.
> People who have actual years of experience with dynamic typing find that the
> actual threat from type mismatch errors is small compared to the inconvenience
> of working with static typing.
This is the kind of worthless anecdotal "evidence" that all too many
people mistake for the real thing. Of course, no scientist worth his
salt will take it other than with a grain of same, and no court of law
will accept this kind of claim as admissible testimony, on the grounds
that it's hearsay.
>>>>>> You mean, the source code for a dispatch table you posted is
>>>>>> machine-generated, like yacc output?
>>>>> No, I mean, you never see any of it.
>>>> Oh, lovely. Machine-generated code you can't even find and read?
>>> Well, I guess that's one way of describing compilation...?
>> This wasn't compilation; this was "defgeneric" forms generated by
>> something. (Macros?)
>
> Macros are a part of compilation.
Macros are user-defined. Macro EXPANSION is a part of compilation,
probably one of the earliest parts.
> What is the difference between, say:
>
> synchronized (obj) { ... code .. }
>
> and
>
> (synchronized obj ... code ...)
>
> Java's synchronized block construct is a de facto macro. The difference is
> that it's hard-wired into the compiler.
You'll also find that all of Java's "de facto macros" lack multiple use
of any argument, and so don't run into the variable capture/global
variable/multiple evalaution trichotomy.'
>>>> It's annoying enough to get bison-generated code to play nice
>>>> with version control.
>>> Do you version-control object files and executables? That seems like
>>> strange behavior to me.
>> Bison generates C source files.
>
> The point is that the C generated by bison is
C, not assembly.
> You're having problems with Bison and version control because you have no clue
> what should go into version control and what shouldn't.
You're jumping to unwarranted conclusions about me. I don't have serious
problems with Bison and version control. I do anticipate there could be
serious problems with Lisp code rewriting the (foo foo) bits of itself
and version control.
>>> The tool I was describing in that paragraph is called... Emacs.
>> You mean, there are two programs with the same name that are otherwise
>> as different as night and day?
>
> I saw elsewhere in this thread that you were shown a screenshot of Emacs and
> you still denied it was Emacs.
I was shown a screenshot and told by a known hostile entity and probable
liar that it was emacs, and the screenshot showed something that
resembled emacs the way the Eiffel Tower resembles a tea saucer.
> The only Emacs is Seamus MacRae Imaginary Emacs.
I find that particularly unlikely to be true. I'm adding you to my list
of "probable liars" in this thread.
>> The compiler compiles the
>>
>> (foo foo) (bar bar)
>> (foo foo) (baz baz)
>>
>> stuff, but what generates it? Apparently sometimes it's done manually.
>> Other times you've suggested it's auto-generated somehow, perhaps by
>> Lisp macros. Regardless, it gets modified to add a dispatch for
>> print-object.
>
> An organized reference manual for Seamus MacRae Lisp would be helpful,
> instead of the collage assembled from these fleeting glimpses of
> what it is about.
I'm sorry, but I don't know of any "Seamus MacRae Lisp". I doubt it
exists. If it does, you'll have to ask someone else about it -- the name
is a total coincidence and I don't know beans about it.
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Kaz Kylheku wrote:
>> ["Followup-To:" header set to comp.lang.lisp.]
>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Pillsy wrote:
>>>> I might, but if I wanted it to inherit from Number, I could certainly
>>>> choose to have it inherit from Number. I'm just not sure that's the
>>>> way to go from a design standpoint, though admittedly I haven't
>>>> thought about the question a whole lot..
>>> Taking it as a given that Complex should be a subtype of Number, how
>>> else would you go about doing it?
>>
>> Are you asking about implementation strategies about how to add
>> this ANSI CL feature to Seamus MacRae Imaginary Lisp.
>
> No; there's no such thing as SMIL anyway.
Obviously, there is. It may not be implemented, or fully specified,
but it's whatever Lisp language you are talking about in this thread.
Being a competent engineer and all, you wouldn't be caught dead spewing
nonsense about a language you know nothing about, such as Common Lisp,
right?
> I was asking Pillsy to clarify
> something that he wrote, and how he would do something. And since you're
> not Pillsy, it is very odd for you to jump in at this point.
How do you know I am not Pillsy? Guessing again?
>>> Well, actually, I don't suppose that even makes sense. CLOS apparently
>>> has a notion of subclass, but to have a notion of subTYPE you kind of
>>> need, well, types.
>>
>> Not really.
>
> Yes really.
>
>> Lisp is the same way. Originally, everything had type.
>
> In Lisp? Surely you jest. At base, it has no static types and precious
> few dynamic ones (integer, maybe a few other numerics, cons cell,
There is no static type, only type. Static type is simply the situation when a
type is being analyzed or otherwise manipulated prior to run time.
When we use a constant like 42, we don't call that ``static valuing'',
implying that it's a different kind of value from the situation
when some variable x holds 42.
I don't understand ``precious few''. If a language has a precious few types,
but all values have a type, then everything has type, right?
How many types must a language have before it's typed?
My statement ``Originally, everything had type'' was meant in contrast to the
current Common Lisp situation, in which everything has /both/ a type and class.
This is very language specific. An OO language designed from scratch today
might have only a single concept: just class.
> string, symbol, nil, and little else).
Disclaimer: I'm writing strictly about Common Lisp (and in this case its
predecessors), not Seamus MacRae Lisp, which I know next to nothing about.
>> Are complex numbers a subtype of numbers?
>>
>> (subtypep 'number 'complex) -> T ;; Yes!
>
> This seems to be checking some programmed-in notion of types, not
> compile-time types of any kind.
Why have you chosen to contrast ``programmed-in notion'' against
``compile-time''?
In Common Lisp, the above is an expression, a call to subtypep. The subtypep
function takes two arguments which are types. Types are represented by symbols
(among other things). The symbol number represents the number type, and the
symbol complex represents the complex type.
If this expression is being compiled, then in fact we do have a situation in
which types are known at compile time: they are named right there! This is
actually a constant expression which can be compiled down to the constant T; the
compiler can know that subtypep is a standard CL function, and that it returns
T when applied to these particular arguments.
Anyway, the point was that Lisp has these types in that subtype relationship.
> You could program this behavior in any language.
Terrific. An example (e.g. Java) would go a long way here.
>>> assignable to Number variables in Java. Since everything is assignable
>>> to every variable in Lisp, this consideration goes away, and just having
>>> both implement plus methods will let you use them interchangeably in
>>> code using plus on variables.
>>>
>>> So the lack of static typing saves you a little bit of work coding your
>>> type system.
>>
>> Lack of static typing saves work in the type system too?
>
> Maybe a bit. At the cost of lots of debugging later on, in big enough
> systems.
You have asked for evidence when people claim that this isn't a big
problem. Where is your evidence that it is?
In computer programming, a lot of aspects of the behavior of a program
are susceptible to compile-time staging, not only type.
What is your rational justification for being obsessed with doing this with
type?
Type is the simplest, most trivial aspect of a computer program.
Errors in type are among the easiest to debug.
The burden of proof rests on those who claim that any property X of a computer
program should be simplified and staged to compile time.
>>> your type system will be completely invisible to the compiler, or your
>>> program won't work. And penny you saved writing "extends Number;" or its
>>> equivalent up front is owed with interest down the line, as a dollar
>>> spent debugging run-time errors to the effect "String does not
>>> understand the method: plus".
>>
>> You keep asking people for rational evidence. Where is your rational
>> evidence that these errors are such a threat?
>
> I have stated it repeatedly. You keep ignoring it.
Pardon me. Would you mind citing a Message-ID of the article containing
this evidence? I can't find it.
>> I agree that there is a nonzero probability that you will be
>> confronted with an error like ``foo does not understand the method bar''.
>
> Well, there we are. I guess we are now in agreement.
>
> So why am I still apparently only 1/3 of the way through your
> interminably long post?
I assure you that the post does terminate. In terms of raw volume, I think you
are winning. I have not posted here nearly as much as you. You're
single-handedly taking on what seems to be at least half a dozen people.
>> 1. How much of a threat is this? Can we quantify this risk in numbers?
>
> Easy: what would have been caught in seconds at compile time, or even
> instantly in the IDE when editing (red squiggly underlines: another
> feature untranslatable to a box of pure ASCII), instead isn't caught
> until run-time and possibly far from the true location of the error.
State-of-the art static typing systems also locate errors sometimes
far from the true location. You might want to Google for "Hindley-Milner"
to discover how typing is done in post-deluvial static languages.
> Seconds of debugging becomes minutes at best, hours at worst.
>
> Say the downside is 30 minutes.
>
> Now note that type errors are an estimated 30% of bugs.
Aha, numbers. Where do these numbers come from? Can you cite your source?
What exactly is a type error? If, in a static language, two declarations do not
match, is this considered a type error, and is that counted toward the 30%
statistic?
Would we have that type error in a dynamic language?
>> 2. What are the costs of preventing this problem with static typing?
>
> A bit more up-front keyboard typing.
Do you think that every dynamic program can become a static one,
with only a ``bit'' of extra keyboarding?
How much is a bit? 10% more code?
> Maybe more thought as to what
> should be what and going where during design and coding, but that will
> pay off as an investment down the line.
How about allowing the progrm to be easily changed with respect to
changing requirements? The world is a changing place.
>> Are there risks, and what are they?
>
> There's a risk you won't be able to mischievously sneak a Float into a
> group of Strings...
>
>> You are asserting that there are no costs, or risks, only benefits,
>
> No, I am not. I am asserting that they balance out in favor of static
> typing.
Based on what? Religious faith?
>> Don't accuse others of having no rational evidence
>
> Then get some and post it.
You first.
>> People who have actual years of experience with dynamic typing find that the
>> actual threat from type mismatch errors is small compared to the inconvenience
>> of working with static typing.
>
> This is the kind of worthless anecdotal "evidence" that all too many
> people mistake for the real thing.
It's better claims from people who have no experience with dynamic typing, and
are purely guessing.
>> What is the difference between, say:
>>
>> synchronized (obj) { ... code .. }
>>
>> and
>>
>> (synchronized obj ... code ...)
>>
>> Java's synchronized block construct is a de facto macro. The difference is
>> that it's hard-wired into the compiler.
>
> You'll also find that all of Java's "de facto macros" lack multiple use
> of any argument, and so don't run into the variable capture/global
> variable/multiple evalaution trichotomy.'
Yes, well these de-facto macros have to take that into account in their code
generation. The Java compiler, when faced with synchronized (expr) ... has to
generate code which evaluates expr to an object reference, and then store that
reference in some hidden variable. Then places in the expanded code which
require the value of the expression refer to the hidden variable; they do not
re-evaluate the original expr.
In macro systems, this is addressed in two ways. In the Scheme language,
which is a Lisp dialect, there are hygienic macros in which these issues are
taken care of automatically. Hygienic macros are cool, but some non-hygienic
things are awkward to do in them. In Common Lisp macros, hygiene is implemented
by the macro writer, in various ways.
A common strategy is to generate some unique symbols which are used to
name hidden variables.
Suppose we have a three-function API for locks:
(monitor-enter m) ;; enter monitor m
(monitor-leave m) ;; leave monitor m
(ensure-monitor o) ;; ensure object o has a monitor and return it
In Lisp we have the unwind-protect construct for running cleanup statements
no matter how an expression terminates; we will use this in the expansion.
Given the expression
(synchronized obj s1 s2 s3)
We want to generate code along these lines:
(let* ((hidden-obj obj)
(hidden-mon (ensure-monitor hidden-obj)))
(unwind-protect
(progn (monitor-enter hidden-mon)
s1 s2 s3)
(monitor-leave hidden-mon)))
Of course we won't call the hidden variables by these names; we will let the
compiler name them by calling the gensym function at macro-expansion time.
(defmacro synchronized (obj &body statements)
(let ((obj-var (gensym))
(mon-var (gensym)))
`(let* ((,obj-var ,obj)
(,mon-var (ensure-monitor ,obj-var)))
(unwind-protect
(progn (monitor-enter ,mon-var))
,@statements)
(monitor-leave ,mon-var))))
Expansion test:
[1]> (macroexpand '(synchronized a b c d))
(LET* ((#:G3131 A)
(#:G3132 (ENSURE-MONITOR #:G3131)))
(UNWIND-PROTECT (PROGN (MONITOR-ENTER #:G3132)) B C D)
(MONITOR-LEAVE #:G3132))
Looks good. So you will find that properly written Lisp macros share
this property of the properly written Java compiler features: no
unexpected capture, or multiple evaluation.
Oh, and by the way, there is one more piece to the hygiene puzzle. Note how
our macro expands to a body of code that uses some functions and operators.
There could be a problem if a function like ensure-monitor is locally
redefined. Typically this is dealt with using packages. It would really be,
say, (thread::ensure-monitor ...). Only you would probably not have to write
the explicit thread:: qualification because your defmacro would be in a file
where the thread package is in effect. Further, Conforming Lisp programs are
not allowed to redefine standard functions and operators like unwind-protect
and progn.
>>>>> It's annoying enough to get bison-generated code to play nice
>>>>> with version control.
>>>> Do you version-control object files and executables? That seems like
>>>> strange behavior to me.
>>> Bison generates C source files.
>>
>> The point is that the C generated by bison is
>
> C, not assembly.
What's the difference, in this context? Can your CPU run assembly?
I can feed either assembly or C to a compiler front end driver and get an
object file.
>> You're having problems with Bison and version control because you have no clue
>> what should go into version control and what shouldn't.
>
> You're jumping to unwarranted conclusions about me.
Is that so? I haven't ever had version control problems with yacc or bison files.
So the problem must be on your end. Somewhere between the keyboard and chair.
> I don't have serious
> problems with Bison and version control.
I don't have problems with Bison and version control, period.
> I do anticipate there could be
> serious problems with Lisp code rewriting the (foo foo) bits of itself
> and version control.
Maybe in Seamus MacRae Lisp, if you don't design it properly.
If that is supposed to be a statement about Common Lisp, then it's a very
poor, inaccurate guess.
The intermediate results of macroexpansion are not written to a file.
There isn't any more of a version control problem with (foo foo) rewriting
itself than there is a problem in Java with synchronized (foo) { bar; }
rewriting itself.
>>>> The tool I was describing in that paragraph is called... Emacs.
>>> You mean, there are two programs with the same name that are otherwise
>>> as different as night and day?
>>
>> I saw elsewhere in this thread that you were shown a screenshot of Emacs and
>> you still denied it was Emacs.
>
> I was shown a screenshot and told by a known hostile entity and probable
> liar that it was emacs, and the screenshot showed something that
> resembled emacs the way the Eiffel Tower resembles a tea saucer.
Funny, I looked at the PNG and saw only Emacs.
I didn't know Slime could do embedded graphics. I.e. evaluate a Lisp
expression, and the resulting value is a graphic. Cool.
I'm not an Emacs user, but I believe the PNG.
>> The only Emacs is Seamus MacRae Imaginary Emacs.
>
> I find that particularly unlikely to be true. I'm adding you to my list
> of "probable liars" in this thread.
What is a probable liar? Someone who offends you with facts that
don't agree with your pre-conceived notions?
Wouldn't it be easier to maintain a list of non-liars?
If you want to list probable liars one by one, you will eventually
need a few gigabytes of space to represent most of the entire world.
Just assume everyone is a liar. And, whatever you do, do not Google
up for a single fact to confirm or refute anything. The results of
search engines are all lies also.
> I'm sorry, but I don't know of any "Seamus MacRae Lisp".
Right; I will substitute the proper name as soon as you share it with us.
Kaz Kylheku wrote:
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> No; there's no such thing as SMIL anyway.
>
> Obviously, there is. It may not be implemented, or fully specified,
> but it's whatever Lisp language you are talking about in this thread.
>
> Being a competent engineer and all, you wouldn't be caught dead spewing
> nonsense about a language you know nothing about, such as Common Lisp,
> right?
There is at least one wrong premise in that argument ...
:-)
Arne
Arne Vajh�j wrote:
> Kaz Kylheku wrote:
>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> No; there's no such thing as SMIL anyway.
>>
>> Obviously, there is. It may not be implemented, or fully specified,
>> but it's whatever Lisp language you are talking about in this thread.
>
> There is at least one wrong premise in that argument ...
Narrowed it down for ya. The Lisp language I am talking about in this
thread is Common Lisp.
On May 22, 10:58 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Arne Vajhøj wrote:
> > Kaz Kylheku wrote:
> >> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>> No; there's no such thing as SMIL anyway.
>
> >> Obviously, there is. It may not be implemented, or fully specified,
> >> but it's whatever Lisp language you are talking about in this thread.
>
> > There is at least one wrong premise in that argument ...
>
> Narrowed it down for ya. The Lisp language I am talking about in this
> thread is Common Lisp.
Let me quote Seamus himself, in a message which you can view here:
http://groups.google.com/group/comp.lang.lisp/msg/ac9c8f90557a0bb7?hl=en
"I just said that. Why are you extracting little pieces of what I
said
and repeating them, apparently thinking that by doing so you are
successfully attacking me?"
By the way, Seamus, the fact that you /complain/ about how it's bad
that CLOS could be hacked-up independantly shows that you don't know
enough about Common Lisp to criticize it. The whole idea of Common
Lisp is that ANYTHING other than the 32 "axioms" of Lisp (QUOTE, ATOM,
EQ, CONS, CAR, CDR, COND, and the 25 special operators such as
TAGBODY, GO, CATCH, THROW, EVAL-WHEN, etc) can be hacked up on your
own. That is the whole mindset of CL.
If we talk about a compiler that makes good code for something, that's
just one of the perks that have accumulated over the years.
- Adlai
PS -- I don't see a qualifier in front of your name yet; are you sure
that you're :USEing :COMMON-LISP?
Adlai wrote:
> On May 22, 10:58 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Arne Vajh�j wrote:
>>> Kaz Kylheku wrote:
>>>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> No; there's no such thing as SMIL anyway.
>>>> Obviously, there is. It may not be implemented, or fully specified,
>>>> but it's whatever Lisp language you are talking about in this thread.
>>> There is at least one wrong premise in that argument ...
>> Narrowed it down for ya. The Lisp language I am talking about in this
>> thread is Common Lisp.
>
> Let me quote Seamus himself, in a message which you can view here:
> http://groups.google.com/group/comp.lang.lisp/msg/ac9c8f90557a0bb7?hl=en
>
> [irrelevant quote snipped]
Why are you responding essentially at random, instead of by addressing
what I've said?
> By the way, Seamus, the fact that you /complain/ about how it's bad
> that CLOS could be hacked-up independantly shows that you don't know
> enough about Common Lisp to criticize it.
No, the fact that you /complain/ about the above shows that you don't
know enough about me to criticize me.
I never said that it was "bad" that CLOS could be hacked up
independently. I said that it was incompatible with type checking and
some kinds of compiler optimizations that would be possible if the
compiler could make stronger assumptions about the object system the way
Java's can. That's a different statement than that it's "bad".
> The whole idea of Common
> Lisp is that ANYTHING other than the 32 "axioms" of Lisp (QUOTE, ATOM,
> EQ, CONS, CAR, CDR, COND, and the 25 special operators such as
> TAGBODY, GO, CATCH, THROW, EVAL-WHEN, etc) can be hacked up on your
> own. That is the whole mindset of CL.
If you're going to get into a language-core-simplicity pissing match,
Brainfuck has only eight operators and nothing else and is Turing complete.
Smalltalk only has about 12 and is actually taken seriously as a
programming language.
> PS -- I don't see a qualifier in front of your name yet; are you sure
> that you're :USEing :COMMON-LISP?
This is a newsgroup post, not a Common Lisp source file.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> I never said that it was "bad" that CLOS could be hacked up
>> independently. I said that it was incompatible with type checking and
>> some kinds of compiler optimizations that would be possible if the
>> compiler could make stronger assumptions about the object system the
>> way Java's can.
>
> But what makes you think real Lisp compilers can't do those things?
> CLOS is part of Common Lisp.
Because a user could conceivably use the core of CL without CLOS, and
even with an object system incompatible with CLOS, perhaps one that
resembles CLOS enough that the compiler cannot reliably tell the difference.
Any valid CL code has to compile flawlessly and run to spec. When CLOS
was developed as a CL library, it was made of valid CL code. Design
decisions were made in the process, that could perhaps have gone the
other way. Now suppose someone makes a clone of CLOS but changes one of
those design decisions and diverges things from there? The result, we
assume, is valid CL code, and moreover, this para-CLOS resembles CLOS,
with parts probably being identical. If the compiler assumes that
anything that "looks like" CLOS is CLOS, and that anything that "looks
like" CLOS client code (defining classes with the same syntax, invoking
methods, etc.) is CLOS client code, and based on those assumptions
rejects code that "uses CLOS wrong" or imposes CLOS semantics on some
things, then if you feed that implementation para-CLOS it will blow up
and fail to conform to the standard.
So the most it can do is optimize for the common case that it really is
CLOS but without going to far as to make the rare case, para-CLOS or
something like it, actually broken.
On May 22, 4:51 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
>
> >> I never said that it was "bad" that CLOS could be hacked up
> >> independently. I said that it was incompatible with type checking and
> >> some kinds of compiler optimizations that would be possible if the
> >> compiler could make stronger assumptions about the object system the
> >> way Java's can.
>
> > But what makes you think real Lisp compilers can't do those things?
> > CLOS is part of Common Lisp.
>
> Because a user could conceivably use the core of CL without CLOS, and
> even with an object system incompatible with CLOS, perhaps one that
> resembles CLOS enough that the compiler cannot reliably tell the difference.
>
> Any valid CL code has to compile flawlessly and run to spec. When CLOS
> was developed as a CL library, it was made of valid CL code. Design
> decisions were made in the process, that could perhaps have gone the
> other way. Now suppose someone makes a clone of CLOS but changes one of
> those design decisions and diverges things from there? The result, we
> assume, is valid CL code, and moreover, this para-CLOS resembles CLOS,
> with parts probably being identical. If the compiler assumes that
> anything that "looks like" CLOS is CLOS, and that anything that "looks
> like" CLOS client code (defining classes with the same syntax, invoking
> methods, etc.) is CLOS client code, and based on those assumptions
> rejects code that "uses CLOS wrong" or imposes CLOS semantics on some
> things, then if you feed that implementation para-CLOS it will blow up
> and fail to conform to the standard.
>
> So the most it can do is optimize for the common case that it really is
> CLOS but without going to far as to make the rare case, para-CLOS or
> something like it, actually broken.
There cannot be anything that looks like CLOS but is not CLOS, since
CLOS's functions and macros have names in the COMMON-LISP package and
as such cannot be redefined by portable programs. I.e. when the
compiler sees a call to CL:DEFCLASS, for example, it can safely assume
it's a CLOS class declaration. (In reality DEFCLASS is a macro so the
compiler will probably optimize the underlying functions used in its
expansion, but the principle is the same).
Alessio
Alessio Stalla wrote:
> On May 22, 4:51 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> I never said that it was "bad" that CLOS could be hacked up
>>>> independently. I said that it was incompatible with type checking and
>>>> some kinds of compiler optimizations that would be possible if the
>>>> compiler could make stronger assumptions about the object system the
>>>> way Java's can.
>>> But what makes you think real Lisp compilers can't do those things?
>>> CLOS is part of Common Lisp.
>> Because a user could conceivably use the core of CL without CLOS, and
>> even with an object system incompatible with CLOS, perhaps one that
>> resembles CLOS enough that the compiler cannot reliably tell the difference.
>>
>> Any valid CL code has to compile flawlessly and run to spec. When CLOS
>> was developed as a CL library, it was made of valid CL code. Design
>> decisions were made in the process, that could perhaps have gone the
>> other way. Now suppose someone makes a clone of CLOS but changes one of
>> those design decisions and diverges things from there? The result, we
>> assume, is valid CL code, and moreover, this para-CLOS resembles CLOS,
>> with parts probably being identical. If the compiler assumes that
>> anything that "looks like" CLOS is CLOS, and that anything that "looks
>> like" CLOS client code (defining classes with the same syntax, invoking
>> methods, etc.) is CLOS client code, and based on those assumptions
>> rejects code that "uses CLOS wrong" or imposes CLOS semantics on some
>> things, then if you feed that implementation para-CLOS it will blow up
>> and fail to conform to the standard.
>>
>> So the most it can do is optimize for the common case that it really is
>> CLOS but without going to far as to make the rare case, para-CLOS or
>> something like it, actually broken.
>
> There cannot be anything that looks like CLOS but is not CLOS
Patently false. When CLOS was being developed, at some point CLOS was in
a working state but not in its final form yet. This would constitute
legal CL code (else it wouldn't have been a working state) that looks
like CLOS but is not (quite yet) CLOS. Also, if a design decision had
been made slightly differently, the CLOS library would have been
slightly different, and this would have been legal CL code, resembling
our universe's CLOS, but not quite the same.
A conforming CL implementation obviously must accept all legal CL code.
I have proven from the fact of CLOS's own successful creation that
CLOS-resembling code that's not quite CLOS must exist in that set.
Or think of it this way: at some point relatively late in the
development of CLOS, there was some spot where they could have done
either X or Y. Suppose they did Y, and that led to CLOS. If you took the
same set of tools and compilers, developed a clone identically up to
that same point, then did X and continued from there in some logical
manner, you'd end up with a para-CLOS resembling CLOS that also would
compile and run on those tools and compilers.
Which we assume are compliant with the CL standard.
Ergo, a compiler that will not compile a runnable para-CLOS is not
compliant with the standard.
So either you are wrong here, or no compilers are compliant with the CL
standard anymore! (And which of these possibilities seems more plausible?)
> when the compiler sees a call to CL:DEFCLASS, for example, it can
> safely assume it's a CLOS class declaration.
As I have just proved, it cannot, though it can optimize for the common
case that it is such a declaration, unless it is not standards
conformant -- and, in particular, nonconformant in the severe manner of
rejecting code that would have been accepted by the implementation the
CLOS developers were working on when CLOS was first being written.
On May 22, 6:20 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 22, 4:51 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Paul Foley (http://public.xdi.org/=pf) wrote:
> >>> Seamus MacRae <··········@live.ca.nospam> writes:
> >>>> I never said that it was "bad" that CLOS could be hacked up
> >>>> independently. I said that it was incompatible with type checking and
> >>>> some kinds of compiler optimizations that would be possible if the
> >>>> compiler could make stronger assumptions about the object system the
> >>>> way Java's can.
> >>> But what makes you think real Lisp compilers can't do those things?
> >>> CLOS is part of Common Lisp.
> >> Because a user could conceivably use the core of CL without CLOS, and
> >> even with an object system incompatible with CLOS, perhaps one that
> >> resembles CLOS enough that the compiler cannot reliably tell the difference.
>
> >> Any valid CL code has to compile flawlessly and run to spec. When CLOS
> >> was developed as a CL library, it was made of valid CL code. Design
> >> decisions were made in the process, that could perhaps have gone the
> >> other way. Now suppose someone makes a clone of CLOS but changes one of
> >> those design decisions and diverges things from there? The result, we
> >> assume, is valid CL code, and moreover, this para-CLOS resembles CLOS,
> >> with parts probably being identical. If the compiler assumes that
> >> anything that "looks like" CLOS is CLOS, and that anything that "looks
> >> like" CLOS client code (defining classes with the same syntax, invoking
> >> methods, etc.) is CLOS client code, and based on those assumptions
> >> rejects code that "uses CLOS wrong" or imposes CLOS semantics on some
> >> things, then if you feed that implementation para-CLOS it will blow up
> >> and fail to conform to the standard.
>
> >> So the most it can do is optimize for the common case that it really is
> >> CLOS but without going to far as to make the rare case, para-CLOS or
> >> something like it, actually broken.
>
> > There cannot be anything that looks like CLOS but is not CLOS
>
> Patently false. When CLOS was being developed, at some point CLOS was in
> a working state but not in its final form yet. This would constitute
> legal CL code (else it wouldn't have been a working state) that looks
> like CLOS but is not (quite yet) CLOS. Also, if a design decision had
> been made slightly differently, the CLOS library would have been
> slightly different, and this would have been legal CL code, resembling
> our universe's CLOS, but not quite the same.
>
> A conforming CL implementation obviously must accept all legal CL code.
> I have proven from the fact of CLOS's own successful creation that
> CLOS-resembling code that's not quite CLOS must exist in that set.
>
> Or think of it this way: at some point relatively late in the
> development of CLOS, there was some spot where they could have done
> either X or Y. Suppose they did Y, and that led to CLOS. If you took the
> same set of tools and compilers, developed a clone identically up to
> that same point, then did X and continued from there in some logical
> manner, you'd end up with a para-CLOS resembling CLOS that also would
> compile and run on those tools and compilers.
>
> Which we assume are compliant with the CL standard.
>
> Ergo, a compiler that will not compile a runnable para-CLOS is not
> compliant with the standard.
>
> So either you are wrong here, or no compilers are compliant with the CL
> standard anymore! (And which of these possibilities seems more plausible?)
>
> > when the compiler sees a call to CL:DEFCLASS, for example, it can
> > safely assume it's a CLOS class declaration.
>
> As I have just proved, it cannot, though it can optimize for the common
> case that it is such a declaration, unless it is not standards
> conformant -- and, in particular, nonconformant in the severe manner of
> rejecting code that would have been accepted by the implementation the
> CLOS developers were working on when CLOS was first being written.
An awesome example of proof-by-fantasy.
CLOS was a library, and then it has been standardized. Of course the
current CL compilers don't know anything about CLOS-the-library; they
do know about CLOS-the-part-of-Common-Lisp, though. What is so strange
about this?
By your line of reasoning, the compiler could not know anything about
those parts of CL implemented in CL! And those are quite a lot in most
implementations.
Alessio Stalla wrote:
> On May 22, 6:20 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> As I have just proved, it cannot, though it can optimize for the common
>> case that it is such a declaration, unless it is not standards
>> conformant -- and, in particular, nonconformant in the severe manner of
>> rejecting code that would have been accepted by the implementation the
>> CLOS developers were working on when CLOS was first being written.
>
> An awesome example of proof-by-fantasy.
No, it's called proof-by-logic. Oh, I forgot, apparently they don't have
logic where you come from.
> CLOS was a library, and then it has been standardized.
This is irrelevant.
Let's start over from the beginning.
First, there is a Standard. The CL Standard. This Standard has existed
for most of CL's history.
Then there are compilers. Compilers that conform to The Standard must do
certain things. In particular there is a set of possible source files
they must accept as valid and compile without error. Some subset of
these compile to binaries that, when run, will do something useful.
Now, CLOS started as one set of such source files. Obviously these were
ones that The Standard considers valid.
Furthermore, there must be a lot of other possible valid source files
"close to" those ones in some sense, many of which would produce
CLOS-resembling object systems that worked okay. Anything that could
plausibly have been CLOS itself had the development team done some
things slightly differently will be among them. So will incomplete but
working-with-some-features-missing pre-1.0 versions of the CLOS that
actually got made. All of these are necessarily valid according to The
Standard.
And therefore conforming CL compilers must accept them all, because The
Standard says they must.
Still with me?
> By your line of reasoning, the compiler could not know anything about
> those parts of CL implemented in CL! And those are quite a lot in most
> implementations.
That's not the same. Those parts were developed before The Standard was
finalized, when the language itself was still being developed. So when
The Standard was created, on whatever date it was created, it could take
those parts into account. But it predates CLOS.
On May 22, 7:00 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> But it predates CLOS.
False. CLOS IS part of the CL standard. See here:
http://www.lispworks.com/documentation/HyperSpec/Body/07_.htm
This is the HTMLized version of the CL standard, and it describes
CLOS.
Alessio Stalla wrote:
> On May 22, 7:00 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> But it predates CLOS.
>
> False.
False. Wikipedia says CL was standardized in 1986. (Shockingly recent
for something that had already existed for a couple of decades before
that.) Meanwhile http://dreamsongs.com/CLOS.html says "In the late
1980s, a group of us designed CLOS."
The "late 1980s" would seem likely to mean 1987-1989, inclusive; 1986
would be in the mid-1980s. Indeed, at that link the dates mentioned for
major early publications are 1987 and 1988.
Besides, you yourself said CLOS was initially built as a library for
ANSI Common Lisp. That cannot have occurred prior to the very existence
of ANSI Common Lisp (as opposed to just Lisp) and, therefore, the standard.
Seamus MacRae <··········@live.ca.nospam> writes:
> Alessio Stalla wrote:
> > On May 22, 6:20 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> As I have just proved, it cannot, though it can optimize for the common
> >> case that it is such a declaration, unless it is not standards
> >> conformant -- and, in particular, nonconformant in the severe manner of
> >> rejecting code that would have been accepted by the implementation the
> >> CLOS developers were working on when CLOS was first being written.
> > An awesome example of proof-by-fantasy.
>
> No, it's called proof-by-logic. Oh, I forgot, apparently they don't have
> logic where you come from.
Except that your proof has several flaws:
1) It proceeds from false premises, therefore no conclusions are valid.
2) It falls into the tertium non datur fallacy
By the way, there is an interesting aphorism at http://tinyurl.com/9b5a8
--
Thomas A. Russ, USC/Information Sciences Institute
On May 22, 2:50 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
> > Alessio Stalla wrote:
> > > On May 22, 6:20 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > >> As I have just proved, it cannot, though it can optimize for the common
> > >> case that it is such a declaration, unless it is not standards
> > >> conformant -- and, in particular, nonconformant in the severe manner of
> > >> rejecting code that would have been accepted by the implementation the
> > >> CLOS developers were working on when CLOS was first being written.
> > > An awesome example of proof-by-fantasy.
>
> > No, it's called proof-by-logic. Oh, I forgot, apparently they don't have
> > logic where you come from.
>
> Except that your proof has several flaws:
>
> 1) It proceeds from false premises, therefore no conclusions are valid.
> 2) It falls into the tertium non datur fallacy
>
> By the way, there is an interesting aphorism athttp://tinyurl.com/9b5a8
Calling Seamus a liar behind his back in a group he doesn't read? How
low can you get?
On Sat, 11 Jul 2009 07:54:10 -0700, Series Expansion wrote:
> Calling Seamus a liar behind his back in a group he doesn't read?
How can you make that assumption, when he had clearly posted the
orriginal message to the group in which the reply was made? Why would
anyone post to a group that they don't read? That's just asking for
replies that they won't see.
--
Andrew
Andrew Reilly wrote:
> On Sat, 11 Jul 2009 07:54:10 -0700, Series Expansion wrote:
>
>> Calling Seamus a liar behind his back in a group he doesn't read?
>
> How can you make that assumption, when he had clearly posted the
> orriginal message to the group in which the reply was made?
I had crossposted it and was clearly a Java programmer.
Series Expansion wrote:
> On May 22, 2:50 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>> Alessio Stalla wrote:
>>>> On May 22, 6:20 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> As I have just proved, it cannot, though it can optimize for the common
>>>>> case that it is such a declaration, unless it is not standards
>>>>> conformant -- and, in particular, nonconformant in the severe manner of
>>>>> rejecting code that would have been accepted by the implementation the
>>>>> CLOS developers were working on when CLOS was first being written.
>>>> An awesome example of proof-by-fantasy.
>>> No, it's called proof-by-logic. Oh, I forgot, apparently they don't have
>>> logic where you come from.
>> Except that your proof has several flaws
No, it does not.
The rest of your post has been deleted unread.
Have a nice day.
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Alessio Stalla wrote:
>>> On May 22, 6:20 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> As I have just proved, it cannot, though it can optimize for the common
>>>> case that it is such a declaration, unless it is not standards
>>>> conformant -- and, in particular, nonconformant in the severe manner of
>>>> rejecting code that would have been accepted by the implementation the
>>>> CLOS developers were working on when CLOS was first being written.
>>> An awesome example of proof-by-fantasy.
>> No, it's called proof-by-logic. Oh, I forgot, apparently they don't have
>> logic where you come from.
>
> Except that your proof has several flaws
It does not.
The rest of your ad hominem post has been deleted unread. Have a nice day.
On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
> Any valid CL code has to compile flawlessly and run to spec. When CLOS
> was developed as a CL library, it was made of valid CL code.
When CLOS was in this state, that was long ago. Today, it's part of the
language spec.
> Design decisions were made in the process, that could perhaps have gone the
> other way. Now suppose someone makes a clone of CLOS but changes one of
> those design decisions and diverges things from there? The result, we
> assume, is valid CL code, and moreover, this para-CLOS resembles CLOS,
> with parts probably being identical.
The CLOS in a modern Lisp implementation is no longer just a bunch of portable
CL code; it is deeply integrated.
> If the compiler assumes that
> anything that "looks like" CLOS is CLOS
The compiler is a computer program, not a guessing moron by the name of Seamus
MacRae. It isn't guided by vague impressions of what something looks like.
The situation you describe is impossible (or rather would be the result of a
stupendously spectactular implementation bug).
You can't redefine standard Lisp macros and functions. Doing so renders the
program nonconforming to the ANSI Common Lisp standard. If you want to have a
parallel CLOS whose elements are named by symbols which are similar to those of
CLOS, it has to live in its own package.
So you end up with, say, MYCLOS:DEFCLASS, which is a completely different
symbol, not in any way related to COMMON-LISP:DEFCLASS.
There is no way that the Lisp implementation could mistake PCL:DEFCLASS for the
real DEFCLASS.
You're again making up bullshit and presenting it as fact.
Kaz Kylheku wrote:
> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
[snip]
Please stop posting five minutes after I post. Post, then wait a day or
so. That way maybe I'll actually be able to get caught up.
>> Any valid CL code has to compile flawlessly and run to spec. When CLOS
>> was developed as a CL library, it was made of valid CL code.
>
> When CLOS was in this state, that was long ago.
Time is irrelevant. Valid CL code is valid CL code.
>> Design decisions were made in the process, that could perhaps have gone the
>> other way. Now suppose someone makes a clone of CLOS but changes one of
>> those design decisions and diverges things from there? The result, we
>> assume, is valid CL code, and moreover, this para-CLOS resembles CLOS,
>> with parts probably being identical.
>
>> If the compiler assumes that
>> anything that "looks like" CLOS is CLOS
>
> The compiler is a computer program, not a guessing moron by the name of Seamus
> MacRae.
Fuck you. Rest of post mostly deleted unread.
> You can't redefine standard Lisp macros and functions. Doing so renders the
> program nonconforming to the ANSI Common Lisp standard. If you want to have a
> parallel CLOS whose elements are named by symbols which are similar to those of
> CLOS, it has to live in its own package.
If this were true, then it would have been impossible to create CLOS in
the first place.
> You're again making up bullshit and presenting it as fact.
No, you're the liar. You will keep your attitude in check and remain
civil in the future, or every time you are not I will remind you, and
everyone, that you are a liar. (The lie you told having been the last
quoted line above.)
On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
> Kaz Kylheku wrote:
>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
> [snip]
>
> Please stop posting five minutes after I post. Post, then wait a day or
Stop posting shit that anyone with two brain cells can debunk in five seconds.
> so. That way maybe I'll actually be able to get caught up.
Good luck.
>>> Any valid CL code has to compile flawlessly and run to spec. When CLOS
>>> was developed as a CL library, it was made of valid CL code.
>>
>> When CLOS was in this state, that was long ago.
>
> Time is irrelevant. Valid CL code is valid CL code.
If time is irrelevant, then don't complain about me posting X minutes
after you.
>> You can't redefine standard Lisp macros and functions. Doing so renders the
>> program nonconforming to the ANSI Common Lisp standard. If you want to have a
>> parallel CLOS whose elements are named by symbols which are similar to those of
>> CLOS, it has to live in its own package.
>
> If this were true, then it would have been impossible to create CLOS in
> the first place.
There is so far exactly one ANSI standard codifying Common Lisp. That standard
has CLOS in it. Before that standard, there was a draft language, which went
through changes. The predecessors to CLOS were obviously not developed in ANSI
CL, which did not exist. Those predecesors are not valid ANSI CL code.
No program conforming to 1994 ANSI Common Lisp can redefine the bindings of the
standard symbols in the common-lisp package.
The experimentation laeding to CLOS was done in dialects which preceded ANSI
Common Lisp, which did not have CLOS support in the compiler, and did not
already have, say, a defclass symbol in the common-lisp package bound to a
macro (if indeed they even had a common-lisp package!).
Time might not be relevant, but software and language version is relevant.
Doh.
Kaz Kylheku wrote:
> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Kaz Kylheku wrote:
>>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>> [snip]
>>
>> Please stop posting five minutes after I post. Post, then wait a day or
>
> Stop posting shit
Stop being rude, insulting, vulgar, and demanding.
>> so. That way maybe I'll actually be able to get caught up.
>
> Good luck.
Your insincere remark has been ignored for the record.
>>>> Any valid CL code has to compile flawlessly and run to spec. When CLOS
>>>> was developed as a CL library, it was made of valid CL code.
>>> When CLOS was in this state, that was long ago.
>> Time is irrelevant. Valid CL code is valid CL code.
>
> If time is irrelevant, then don't complain about me posting X minutes
> after you.
Time is irrelevant to some things and relevant to others. Or had the
possibility of such a thing never occurred to you?
>>> You can't redefine standard Lisp macros and functions. Doing so renders the
>>> program nonconforming to the ANSI Common Lisp standard. If you want to have a
>>> parallel CLOS whose elements are named by symbols which are similar to those of
>>> CLOS, it has to live in its own package.
>> If this were true, then it would have been impossible to create CLOS in
>> the first place.
>
> There is so far exactly one ANSI standard codifying Common Lisp. That standard
> has CLOS in it.
That is clearly impossible, since that standard was published in 1986
and CLOS was still being developed into 1988. Unless you mean to suggest
that the specification for CLOS, published in 1988, was then couriered
via time machine to an ANSI committee at or prior to the date of 1986 so
that it could be included in the CL standard, then you shall have to
admit you are mistaken.
[much deleted that was dependent on a false premise]
> Doh.
My sentiments exactly.
Seamus MacRae wrote:
> Kaz Kylheku wrote:
>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Kaz Kylheku wrote:
>>>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> [snip]
>>>
>>> Please stop posting five minutes after I post. Post, then wait a day or
>>
>> Stop posting shit
>
> Stop being rude, insulting, vulgar, and demanding.
>
>>> so. That way maybe I'll actually be able to get caught up.
>>
>> Good luck.
>
> Your insincere remark has been ignored for the record.
How can you both ignore something *and* reply to it at the
same time??
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Kaz Kylheku wrote:
>>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Kaz Kylheku wrote:
>>>>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> [snip]
>>>>
>>>> Please stop posting five minutes after I post. Post, then wait a day or
>>>
>>> Stop posting shit
>>
>> Stop being rude, insulting, vulgar, and demanding.
>>
>>>> so. That way maybe I'll actually be able to get caught up.
>>>
>>> Good luck.
>>
>> Your insincere remark has been ignored for the record.
>
> How can you both ignore something *and* reply to it at the
> same time??
I have many mysterious powers, not the least of which is apparently the
capacity to tie *you* in knots with what was meant to be a simple and
humorous remark.
Seamus MacRae wrote:
> That is clearly impossible, since that standard was published in 1986
> and CLOS was still being developed into 1988. Unless you mean to suggest
> that the specification for CLOS, published in 1988, was then couriered
> via time machine to an ANSI committee at or prior to the date of 1986 so
> that it could be included in the CL standard, then you shall have to
> admit you are mistaken.
One of the actual Lisp knowledgeable will have to correct me if
I am wrong but I thought that the ANSI committee started the
work in 1986 and completed in 1992/94.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> That is clearly impossible, since that standard was published in 1986
>> and CLOS was still being developed into 1988. Unless you mean to
>> suggest that the specification for CLOS, published in 1988, was then
>> couriered via time machine to an ANSI committee at or prior to the
>> date of 1986 so that it could be included in the CL standard, then you
>> shall have to admit you are mistaken.
>
> One of the actual Lisp knowledgeable will have to correct me if
> I am wrong but I thought that [you're a liar, Seamus!]
I am not.
On 23 maio, 02:36, Seamus MacRae <··········@live.ca.nospam> wrote:
> Arne Vajhøj wrote:
> > Seamus MacRae wrote:
> >> That is clearly impossible, since that standard was published in 1986
> >> and CLOS was still being developed into 1988. Unless you mean to
> >> suggest that the specification for CLOS, published in 1988, was then
> >> couriered via time machine to an ANSI committee at or prior to the
> >> date of 1986 so that it could be included in the CL standard, then you
> >> shall have to admit you are mistaken.
>
> > One of the actual Lisp knowledgeable will have to correct me if
> > I am wrong but I thought that [you're a liar, Seamus!]
>
> I am not.
Don't you know the difference between being a liar and being mistaken?
Every time someone says you are mistaken, you listen that you are a
liar and get angry about it without any motive.
You are not a liar, but you are mistaken. Common Lisp was made ANSI in
1994:
http://www.lispworks.com/documentation/common-lisp.html
http://www.techstreet.com/cgi-bin/detail?product_id=56214
And CLOS IS part of it:
http://www.lispworks.com/documentation/HyperSpec/Body/07_.htm
gugamilare wrote:
> On 23 maio, 02:36, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Arne Vajh�j wrote:
>>> One of the actual Lisp knowledgeable will have to correct me if
>>> I am wrong but I thought that [you're a liar, Seamus!]
>> I am not.
>
> Don't you know the difference between [etc]
More personal attacks? Why can you not focus on the matters that are
actually relevant here, such as CLOS.
In fact, hadn't you earlier declared that you were quitting this thread?
Yet you have made several posts in the past 48 hours.
> liar and get angry about it without any motive.
I do not get angry; I calmly point out how illogical your ad hominem
attacks are. They do not prove that Lisp is superior to Java, or furnish
any support at all for that conclusion. Indeed, they are entirely
irrelevant to the conclusion you wish people to draw.
> [another ad hominem attack deleted]
I found (and, unfortunately, lost again) a reference to CL being
standardized in 1986. Your implication that there is no such reference
is an implication that I lied about having found one, and therefore
constitutes yet another personal attack.
Furthermore, no such remarks are valid arguments in favor of Lisp over
Java; indeed, even if your accusations about me were true, they still
would not provide a reason for considering Lisp to be superior to Java,
and I would continue to maintain that it is not.
Your logic is lacking, and you will convince no-one of Lisp's alleged
superiority as long as that remains the case. (Not that your arguments
becoming more rational would guarantee anything. But it would improve
your odds, which are presently a flat zero.)
[rest deleted unread]
Seamus MacRae wrote:
> Please stop posting five minutes after I post. Post, then wait a day or
> so. That way maybe I'll actually be able to get caught up.
Your problem. Not our problem.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Please stop posting five minutes after I post. Post, then wait a day
>> or so. That way maybe I'll actually be able to get caught up.
>
> Your problem. Not our problem.
Then I will make it your problem.
Seamus MacRae wrote:
> Kaz Kylheku wrote:
>> You're again making up bullshit and presenting it as fact.
>
> No, you're the liar. You will keep your attitude in check and remain
> civil in the future,
Check:
http://en.wikipedia.org/wiki/Hypocrisy
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> No, you're the liar. You will keep your attitude in check and remain
>> civil in the future,
>
> Check:
> http://en.wikipedia.org/wiki/Hypocrisy
That is not either keeping your attitude in check nor remaining civil.
You have failed. Please start over and try again from scratch.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Seamus MacRae wrote:
>>> No, you're the liar. You will keep your attitude in check and remain
>>> civil in the future,
>>
>> Check:
>> http://en.wikipedia.org/wiki/Hypocrisy
>
> That is not either keeping your attitude in check nor remaining civil.
> You have failed. Please start over and try again from scratch.
So you missed the point again.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Seamus MacRae wrote:
>>>> No, you're the liar. You will keep your attitude in check and remain
>>>> civil in the future,
>>>
>>> Check:
>>> http://en.wikipedia.org/wiki/Hypocrisy
>>
>> That is not either keeping your attitude in check nor remaining civil.
>> You have failed. Please start over and try again from scratch.
>
> So you missed the point again.
No. YOU missed the point. Indeed, you missed the point of this entire
thread. This thread is about how Lisp stacks up against Java, remember?
Kaz Kylheku wrote:
> On 2009-05-22, Pascal J. Bourguignon <···@informatimago.com> wrote:
>> Kaz Kylheku <········@gmail.com> writes:
>>
>>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Please, just stop answering to them.
I shall reply to this here since Motzarella didn't see fit to receive
Pascal's post.
I will continue "answering to them" (or rather, to *you*, as you,
Pascal, are one of "them") for as long as you continue to publicly
insinuate negative things about me, and other nonsense, that I feel the
need to correct. Somebody has to set the record straight when one of you
tells a whopper, and hardly anybody else seems to be willing to do it,
hence my volunteering.
> Wakarimashita!
Excuse me?
> Appropriate plonking applied.
If you're now plonking each other, you really should stop this invasion
of comp.lang.java.programmer and get your own house in order over in
comp.lang.lisp.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Kaz Kylheku wrote:
>>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> No; there's no such thing as SMIL anyway.
>>>
>>> Obviously, there is. It may not be implemented, or fully specified,
>>> but it's whatever Lisp language you are talking about in this thread.
>>>
>>> Being a competent engineer and all, you wouldn't be caught dead spewing
>>> nonsense about a language you know nothing about, such as Common Lisp,
>>> right?
>>
>> There is at least one wrong premise in that argument ...
>
> Narrowed it down for ya. The Lisp language I am talking about in this
> thread is Common Lisp.
I was not commenting on Lisp dialects at all!
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Kaz Kylheku wrote:
>>>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> No; there's no such thing as SMIL anyway.
>>>>
>>>> Obviously, there is. It may not be implemented, or fully specified,
>>>> but it's whatever Lisp language you are talking about in this thread.
> >>>
>>>> Being a competent engineer and all, you wouldn't be caught dead spewing
>>>> nonsense about a language you know nothing about, such as Common Lisp,
>>>> right?
>>>
>>> There is at least one wrong premise in that argument ...
>>
>> Narrowed it down for ya. The Lisp language I am talking about in this
>> thread is Common Lisp.
>
> I was not commenting
Then please go ahead and not comment. I won't mind complete silence from
you. Not one bit.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Seamus MacRae wrote:
>>> Arne Vajh�j wrote:
>>>> Kaz Kylheku wrote:
>>>>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> No; there's no such thing as SMIL anyway.
>>>>>
>>>>> Obviously, there is. It may not be implemented, or fully specified,
>>>>> but it's whatever Lisp language you are talking about in this thread.
>> >>>
>>>>> Being a competent engineer and all, you wouldn't be caught dead
>>>>> spewing
>>>>> nonsense about a language you know nothing about, such as Common Lisp,
>>>>> right?
>>>>
>>>> There is at least one wrong premise in that argument ...
>>>
>>> Narrowed it down for ya. The Lisp language I am talking about in this
>>> thread is Common Lisp.
>>
>> I was not commenting on Lisp dialects at all!
>
> Then please go ahead and not comment. I won't mind complete silence from
> you. Not one bit.
I was commenting on something else!
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Seamus MacRae wrote:
>>>> Arne Vajh�j wrote:
>>>>> Kaz Kylheku wrote:
>>>>>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>>> No; there's no such thing as SMIL anyway.
>>>>>>
>>>>>> Obviously, there is. It may not be implemented, or fully specified,
>>>>>> but it's whatever Lisp language you are talking about in this thread.
>>> >>>
>>>>>> Being a competent engineer and all, you wouldn't be caught dead
>>>>>> spewing
>>>>>> nonsense about a language you know nothing about, such as Common
>>>>>> Lisp,
>>>>>> right?
>>>>>
>>>>> There is at least one wrong premise in that argument ...
>>>>
>>>> Narrowed it down for ya. The Lisp language I am talking about in
>>>> this thread is Common Lisp.
>>>
>>> I was not commenting
>>
>> Then please go ahead and not comment. I won't mind complete silence
>> from you. Not one bit.
>
> I was commenting
Now you're just contradicting yourself.
Kaz Kylheku wrote:
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Kaz Kylheku wrote:
>>> ["Followup-To:" header set to comp.lang.lisp.]
>>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Pillsy wrote:
>>>>> I might, but if I wanted it to inherit from Number, I could certainly
>>>>> choose to have it inherit from Number. I'm just not sure that's the
>>>>> way to go from a design standpoint, though admittedly I haven't
>>>>> thought about the question a whole lot..
>>>> Taking it as a given that Complex should be a subtype of Number, how
>>>> else would you go about doing it?
>>> Are you asking about implementation strategies about how to add
>>> this ANSI CL feature to Seamus MacRae Imaginary Lisp.
>> No; there's no such thing as SMIL anyway.
>
> Obviously, there is.
Well, I've never heard of it. Though if it exists despite that, the name
is quite a remarkable coincidence, wouldn't you say?
> It may not be implemented, or fully specified,
> but it's whatever Lisp language you are talking about in this thread.
No, the Lisp language I'm talking about in this thread is Common Lisp,
and a lot of the premises of my statements in this thread have in fact
been statements about Common Lisp made by comp.lang.lisp regulars during
the course of this thread. If you disagree with some of those premises
it is because, as has been mentioned several times before, you disagree
among yourselves. I have nothing to do with it and you should get your
own house in order before looking to cast blame elsewhere.
> [some kind of ad hominem]
As with all such arguments, proves nothing about the matter under debate.
>> I was asking Pillsy to clarify
>> something that he wrote, and how he would do something. And since you're
>> not Pillsy, it is very odd for you to jump in at this point.
>
> How do you know I am not Pillsy? Guessing again?
No. You use different names, different computers, different news
services, and do not agree 100% with one another. (You use slrn on Linux
and the eternal-september.org NNTP service, whereas he uses Firefox on a
Mac to post via Google Groups.)
Do at least try to think before leaping to the attack. It would save you
many embarrassing stumbles like that last one.
>>> Lisp is the same way. Originally, everything had type.
>> In Lisp? Surely you jest. At base, it has no static types and precious
>> few dynamic ones (integer, maybe a few other numerics, cons cell,
>
> There is no static type
I just said that. Why are you extracting little pieces of what I said
and repeating them, apparently thinking that by doing so you are
successfully attacking me? For that matter, why attack me at all? I pose
no threat to you. I also cannot be made to provide money, goods of
value, or similarly by insulting me. You cannot coerce me nor can I harm
you here so neither of the logical reasons for attacking, either to
plunder resources by force or to neutralize a threat, seem to apply. It
follows that your reasons for attacking are ILlogical, most likely
emotional. You would be better served by getting therapy for your issues
than by continuing to lash out at strangers via usenet. We're not here
to be your stress-relievers nor is that going to do any long term good
anyway, though it might be momentarily cathartic for you.
> I don't understand ``precious few''. If a language has a precious few types,
> but all values have a type, then everything has type, right?
> How many types must a language have before it's typed?
Once again, you miss my point, I suspect intentionally. The type system
the compiler natively knows about is small and finite. It's a bit like
if Java had only int, double, boolean, and all those other primitive
types, and Object, and the compiler didn't know Exception from
Enumeration, just that they were both Objects. You just invoked methods
on objects and got a runtime exception if the actual run-time type
didn't have a method with that name.
Fortunately Java is not like that but in any system where the compiler
and language spec have no specific recognition of individual
user-defined classes as types all type checking (and dispatch of
methods!) has to be done at runtime.
>> string, symbol, nil, and little else).
>
> Disclaimer: I'm writing strictly about Common Lisp (and in this case its
> predecessors), not Seamus MacRae Lisp, which I know next to nothing about.
For the umpteenth time, there is no Seamus MacRae Lisp, at least so far
as I know, and even if there is, it's irrelevant. Why do you keep
bringing it up as if it were relevant? Note that of all the people in
this thread, you are the one who keeps mentioning it where previously
only Common Lisp had been under discussion. You keep bringing the
subject up, not I.
I think it is a red herring you've dredged up out of the deeps in order
to muddy the waters.
>>> Are complex numbers a subtype of numbers?
>>>
>>> (subtypep 'number 'complex) -> T ;; Yes!
>> This seems to be checking some programmed-in notion of types, not
>> compile-time types of any kind.
>
> Why have you chosen to contrast ``programmed-in notion'' against
> ``compile-time''?
Because they're different. I could create a Java class, FooObject, that
had a String field "type" and a name in this, and its own internal
dispatch mechanism based on the name, so you'd call
someFooObject.do(methName) and depending on methName and
someFooObject.type a different Runnable (say) would get invoked.
This would be a first step towards creating a user-added object system
inside of Java. You wouldn't want to do it, because it would be slow and
inefficient and Java gives you a perfectly decent object system for free
that is much more efficient. But you could do this.
And guess what: it would be completely invisible to javac! So the
programmed-in notion type in the "type" field of the FooObject class is
not compile-time. Even when the "type" field came from a string literal
in some code somewhere, and so was a constant, it would still not be
something javac knew anything about, save that it was a field of that
class of type String. It would be up to program code to reason about the
intended semantics of that field; javac would be agnostic of these
semantics.
Similarly, CLOS is built on top of Common Lisp in the same manner as
FooObject with its explicit type field and its explicit dispatch system
coded in the host language. CLOS classes are a "programmed-in notion"
type system. Oh, I'm sure they've tweaked things to make sure it's much
more efficient than FooObject likely ever could be, using macros to do
as much as possible at compile time for example. And as someone has
mentioned, some CL implementations have a compiler that optimizes
certain kinds of CLOS use. But a conforming CL implementation can't
change the semantics of CLOS or any other code -- optimizations that
affect only performance are one thing, but actually changing behavior is
another. So everything that CL's standard says must compile, must
compile; everything it says must behave a certain way at runtime, must
behave that way at runtime. The implementation therefore must pretend it
doesn't know beans about CLOS, except for performance optimizations,
even if it actually does (so that it can do those optimizations).
Not only that, implementations are widespread that genuinely don't know
anything about CLOS.
The compiler therefore must be agnostic about types other than the
primitive type system I mentioned, the one analogous to
Java's-primitive-types-plus-Object. Except for the optimizer, which in
SOME cases may know a BIT more.
Keep in mind, also, that anyone can bolt on their own non-CLOS object
system that might look similar to CLOS, including constructing its
objects in almost the same way and storing classes and class information
in almost the same way. Any such system that is legal CL code must
compile and run flawlessly in all conforming implementations, which
means not only can they not do anything BUT tweak the speed of CLOS
code, but even these optimizations will be of strictly limited scope.
They cannot, for instance, outright break code that triggers them but
isn't really CLOS; pessimize it by making assumptions true of CLOS but
false of the custom object system, maybe, but not outright break it. In
particular the compiler cannot produce diagnostics for code that appears
to be bad or questionable CLOS code because it might be legitimate
non-CLOS code masquerading as bad CLOS code, and if so it has to work as
it would if compiled with a no-frills basic CL compiler. So the
optimizations that can be performed amount to a) laying out data in
memory and possibly emulating some data structures using different data
structures, while preserving semantics; and b) optimizing for the
common-in-CLOS case in various ways. Both might pessimize quasi-CLOS
systems, and neither should actually break anything.
(With respect to data layout, some Lisps fake constructed-in-one-go
lists that are likely to be immutable by using arrays instead of linked
lists in memory. Doing so pessimizes things if the list is subsequently
subjected to deletion other than at its head or most other modifying
operations other than changing the car values in the list. It does not
however make the semantics wrong and optimizes for the common case for
these types of list. Yes, I do know more about Lisp than you gave me
credit for. Perhaps it's time you gave up?)
> In Common Lisp, the above is an expression, a call to subtypep. The subtypep
> function takes two arguments which are types.
Actually, like any Lisp function it takes any argument types. It *hopes*
they are types, and presumably generates some sort of exception at
runtime if one of them is not...
> If this expression is being compiled, then in fact we do have a situation in
> which types are known at compile time: they are named right there!
This notion of "known at compile time" is meaningless. If
someFooObject.type = "scuzz"
is being compiled, the "scuzz" type is "known at compile time" to javac,
since it is "named right there", but javac doesn't know it from any
other string literal. Similarly a conforming CL implementation can't
safely make assumptions about the purpose of a symbol: maybe the coder
intends it to name a type in some high-up layer of program design but
maybe they do not. Assuming it's a type and enforcing anything based on
those assumptions, or making certain kinds of decisions based on those
assumptions, will break conforming code, making the implementation
NONconforming. The most it can do is *guess* that the symbol names a
type of some sort and then do something that will make the code run
faster if the guess proves to be right but that will not alter its
behavior (speed and memory-use aside) even in the case that the guess
proves to be wrong. It can, for instance, organize the code such that if
the symbol IS a type name, the CPU's branch prediction will speed things
up a lot (method dispatch perhaps?), but the code will still work even
if it's not. Cache misses is another area. If the guess suggests a
particular branch of an if will execute much more often than the other,
it can make the machine code do an "if (predicate) goto far-away;
probably common case; RET; far-away: probably rare case" and this might
reduce cache misses versus the other way around, even if it means
negating the predicate used in the input code and exchanging the two
branches. If the guess is wrong, maybe the result is more cache misses
instead of fewer, or no change, but the code still works.
> This is actually a constant expression which can be compiled down to
> the constant T; the compiler can know that subtypep is a standard CL
> function, and that it returns T when applied to these particular
> arguments.
Surely it cannot. What if subtypep is not what it expected because
someone wrote their own version instead of using CLOS? After all it's
perfectly legal CL, just not legal CLOS. One of you provided an example
earlier of replacing car and cdr with content-of-address-register and
content-of-decrement-register, which changed aspects of the language.
Someone could likewise change subtypep to subtypeq (preferring "query"
to "predicate" perhaps) or make subtypep do something else.
> Anyway, the point was that Lisp has these types in that subtype relationship.
No, CLOS has these types in that subtype relationship. Lisp itself has a
bunch of cons cells and symbols and a function that might, in theory,
mean anything, even if they do in this case happen to mean that.
>> You could program this behavior in any language.
>
> Terrific. An example (e.g. Java) would go a long way here.
See above, or grep post for "FooObject". Just a sketch of the start of
an implementation mind you, without any code even, just description.
>>>> So the lack of static typing saves you a little bit of work coding your
>>>> type system.
>>> Lack of static typing saves work in the type system too?
>> Maybe a bit. At the cost of lots of debugging later on, in big enough
>> systems.
>
> You have asked for evidence when people claim that this isn't a big
> problem. Where is your evidence that it is?
Your side is the one making the extraordinary claim, and therefore the
one required to furnish extraordinary evidence. The burden of proof is
on the party making the extravagant, unusual, counterintuitive,
counter-commonsense, or counter-many-peoples'-experience claim and not
on the party making the conventional claim.
> In computer programming, a lot of aspects of the behavior of a program
> are susceptible to compile-time staging, not only type.
This statement is true but irrelevant. We are discussing type; what ELSE
can be made part of the static, compiler-groks-it set of stuff is not
important now. It's not, after all, like they tend to be mutually
exclusive, so having the compiler enforce type safety means not being
able to have it do or check something else.
> What is your rational justification for being obsessed with doing this with
> type?
Is this a trick question?
It's meaningless, because the formulation of the question presupposes
something that is false, namely, that I am obsessed with anything at all.
I need no rational justification for being something that I am not.
Moreover, I need supply you with no rational justification for anything
whatsoever. You have no authority over me, and therefore I need not ever
justify anything to you. That you apparently believe otherwise is
disturbing.
Furthermore, we are discussing Java vs. Lisp. Trying to change the
subject from that to me (e.g., asking what my justification is for X) is
illegitimate, perhaps an intentional attempt to cloud the issue and
certainly not part of any rational argument on the topic originally at
hand. It matters not a whit to the truth or falsity of any statement
about Java or Lisp what my reasons are for thinking anything, if that
statement is objective; and if it is subjective, then there can be no
fruitful arguing over its truth-value anyway!
> Type is the simplest, most trivial aspect of a computer program.
> Errors in type are among the easiest to debug.
Yes, because type safety is present in most programming languages.
Except that Lisp is not one of that set, and so type errors are not
"among the easiest to debug" in Lisp.
Nice try, moving from specific to general when the specific case is
exceptional in some way. Too bad I'm hip to your rhetorical bag of
tricks and know how to counter each and every one of 'em.
For those who really, really still fall for that old gag and need a
specific disproof of what this guy implied, just note that if a program
creates a list intended to be of integers, drops a Frog in there, waits
quite a long time doing other things, and then somewhere else in the
program some other code receives that list and tries to tot up the
numbers for whatever reason, the explosion will happen quite far from
the place and time of the error. The stack trace will point to nowhere
near where the type error actually occurred, and the poor maintenance
programmer will have to resort to a) sprinkling debug prints liberally
around the site of the crash, b) once it's localized to that particular
list getting noninteger objects in it, tracing the data flow to find all
the places it gets list references from; c) in all code that inserts
into any list that might subsequently reach that method, add debug
prints to catch any addition of a noninteger to the list and make the
program dump core then&there; and then d) run it and stress it until the
crash reproduces again, hopefully this time pointing to the erroneous
insertion. And then he has to find out how the Frog got *there*!
I've done this. Java still lacks compile-time type-safety for
nulls-not-getting-where-they-don't-belong. With generics Java finally
catches it as soon as you try to put a Frog into a List<Integer> before
even running the program but it still can't catch you putting a null in.
So I've had to track down where spurious nulls snuck into things using
exactly the kind of debugging described, and believe me, it's a LOT more
work than seeing a red squiggly underline in NetBeans and immediately
knowing a) that there's a bug and b) what and where it is.
Untyped collections and holders are particularly bad because of the time
and space shifting they enable between initial type error and symptoms
emerging. A wrong-type object (or a null) in a collection can be a
ticking bomb that goes unnoticed for weeks. The collection might even be
schlepped over the network or persisted across sessions in between error
occurring and subsequent detonation.
> The burden of proof rests on those who claim that any property X of a computer
> program should be simplified and staged to compile time.
Another rhetorical trick, this time some kind of strawman argument. Who
said anything about "simplified and"?
>>> You keep asking people for rational evidence. Where is your rational
>>> evidence that these errors are such a threat?
>> I have stated it repeatedly. You keep ignoring it.
>
> Pardon me. Would you mind citing a Message-ID of the article containing
> this evidence? I can't find it.
Read almost any post by me to this thread. Or just read the above, where
I restated one strong argument supporting the case, with eyewitness
testimony for evidence (it doesn't get much better than that; juries
LOVE eyewitness testimony, sometimes even more than they love forensics).
>>> I agree that there is a nonzero probability that you will be
>>> confronted with an error like ``foo does not understand the method bar''.
>> Well, there we are. I guess we are now in agreement.
>>
>> So why am I still apparently only 1/3 of the way through your
>> interminably long post?
>
> I assure you that the post does terminate.
Obviously, if it did not, it would not have been possible for me to have
been 1/3 of the way through it. Therefore your statement conveys no
information that I did not already know, and thus it is useless.
Perhaps if you avoided placing useless baggage like this, and like the
various snide asides, ad hominem quips, and pointless personal questions
(e.g. "how do you justify thinking xyz?", then your posts would be of a
more tractable length.
> In terms of raw volume, I think you are winning.
Oh, you'll find that I'm just full of surprises. I type well in excess
of 500cpm on a good day, among other things.
> I have not posted here nearly as much as you. You're single-handedly
> taking on what seems to be at least half a dozen people.
Only because several people ganged up on me for some inexplicable
reason. And I'm not quite single-handed. Though we do not know each
other and are not coordinating our efforts, it seems Series Expansion is
on my side rather than yours. For a time Lew was as well, before getting
bitten by that raccoon or whatever it was and developing that
unfortunate case of lyssavirus.
>>> 1. How much of a threat is this? Can we quantify this risk in numbers?
>> Easy: what would have been caught in seconds at compile time, or even
>> instantly in the IDE when editing (red squiggly underlines: another
>> feature untranslatable to a box of pure ASCII), instead isn't caught
>> until run-time and possibly far from the true location of the error.
>
> State-of-the art static typing systems also locate errors sometimes
> far from the true location.
I can think of three cases where this seems particularly likely to occur.
1. Systems with a lot of type inference and implicit typing, like
ML-family languages. Java has explicit types on everything.
2. Systems lacking type parametrization. Collections suffer from
the ticking-bomb problem in C and older Javas. Java 5 and 6
and C++ provide tools to type collections and avoid this]
problem.
3. Cases where the type system was intentionally subverted. Using
variables of type Object and lots of last-minute casting,
instanecof tests, or explicit type fields in Java, for instance.
>> Seconds of debugging becomes minutes at best, hours at worst.
>>
>> Say the downside is 30 minutes.
>>
>> Now note that type errors are an estimated 30% of bugs.
>
> Aha, numbers. Where do these numbers come from? Can you cite your source?
Wikipedia: http://en.wikipedia.org/wiki/Type_system
"Advocates ... have suggested that almost all bugs can be considered
type errors, if the types used in a program are properly declared by the
programmer or correctly inferred by the compiler.[2]"
Note the existence of a citation. It's to a paper the link to which is
broken, but which CiteSeer has indexed, so it's real. The claim there is
essentially 100%. I thought that outlandish enough to reduce it by more
than a factor of three, more generous of me than had I split the
difference and said 50%.
Furthermore, Pierce has a nice description of the subjective effects of
static type checks in Types and Programming Languages: "In practice,
static typechecking exposes a surprisingly broad range of errors.
Programmers working in richly typed languages often remark that their
programs tend to "just work" once they pass the typechecker, much more
often than they feel they have a right to expect. One possible
explanation for this is that not only trivial mental slips ... but also
deeper conceptual errors ... will often manifest as inconsistencies at
the level of types."
> What exactly is a type error?
It is when an object is used where it cannot possibly work because it is
semantically the wrong kind of object. I thought everyone here woukd
know this.
> Would we have that type error in a dynamic language?
Of course, but the compiler wouldn't detect it. It could only ever
manifest as a run time failure of some sort.
>>> 2. What are the costs of preventing this problem with static typing?
>> A bit more up-front keyboard typing.
>
> Do you think that every dynamic program can become a static one,
> with only a ``bit'' of extra keyboarding?
Of course not. However, that's comparing apples and oranges. The proper
apples-to-apples comparison is to develop two programs with the same
requirements, one using static typing and one eschewing it.
> How much is a bit? 10% more code?
Type names can be autocompleted pretty intelligently by any decent IDE.
Time spent programming is dominated by thinking, not typing, anyway.
>> Maybe more thought as to what
>> should be what and going where during design and coding, but that will
>> pay off as an investment down the line.
>
> How about allowing the progrm to be easily changed with respect to
> changing requirements?
That's one reason why we have OO and polymorphism. If we need more than
one type of Frob we can subclass it. If we need bignums we can generify
to Number or just search and replace* on some type names and operators,
test, and fix anything that got wonky.
* Being smart enough about it to not use bignum loop indices or other
such stupidity. The compiler will catch it if we fuck up and change an
array index.
More usually, requirement changes mean we still have a Person type but
it holds some new or different data. This means changes to the class,
and some changes to client code of that class, but not typically a
drastic overhaul of the type system.
>>> Are there risks, and what are they?
>> There's a risk you won't be able to mischievously sneak a Float into a
>> group of Strings...
>>
>>> You are asserting that there are no costs, or risks, only benefits,
>> No, I am not. I am asserting that they balance out in favor of static
>> typing.
>
> Based on what? Religious faith?
No. You should know me better than that by now. Evidence and experience,
of course, and I also provided a few citations for you to chew on, above.
>>> Don't accuse others of having no rational evidence
>> Then get some and post it.
>
> You first.
I already did, but I have yet to see any from you.
>> This is the kind of worthless anecdotal "evidence" that all too many
>> people mistake for the real thing.
>
> It's better claims from people who have no experience with dynamic typing, and
> are purely guessing.
I'm doing nothing of the sort and I have experience on both sides of the
fence, though with more Smalltalk than Lisp experience on the dynamic side.
You shouldn't make assumptions about me and then attack those
assumptions. When they turn out to be wrong, and they will, you will end
up looking foolish.
>>> Java's synchronized block construct is a de facto macro. The difference is
>>> that it's hard-wired into the compiler.
>> You'll also find that all of Java's "de facto macros" lack multiple use
>> of any argument, and so don't run into the variable capture/global
>> variable/multiple evalaution trichotomy.
>
> Yes, well these de-facto macros have to take that into account in their code
> generation. The Java compiler, when faced with synchronized (expr) ... has to
> generate code which evaluates expr to an object reference, and then store that
> reference in some hidden variable.
At least it CAN. Make "some hidden variable" that has no name, that is.
If the programmer had to implement "synchronized" they'd have to create
an explicit variable, which would have to have a name, which would then
be able to collide, or would be global.
Certainly multiple evaluation was not an option even regardless of side
effects. The expression's value might change and then it might raise one
semaphore and then lower another, breaking things. (Consider, for example:
while (node != null) {
Node x = anotherNode();
synchronized (node) {
// do things with node and x
node = node.next;
}
}
Make a macro of this that just goes "{lock(node); body unlock(node);}"
and you get this:
{
lock(node);
// do things with node and x
node = node.next;
unlock(node);
}
Oops: locked one node and unlocked another.
OK, lets try "{Node x = node; lock(x); body unlock(x);}":
{
Node x = node;
lock(x);
// do things with node and x
node = node.next;
unlock(x);
}
Oops: Now we lock and unlock the same object, and it's the right
opbject, but the // do things with node and x code now uses the wrong x.
Nice job!
Of course "Node x = node; {lock(x); body unlock(x);}" is even worse as
it clobbers the value returned by anotherNode() AND has the above
problem. Then there's "static Node x = node; {lock(x); body unlock(x);}"
(pretending we can make a local static variable like in C). Now it's not
reentrant (x will get clobbered if // do things with node and x ends up
invoking the same macro again, which it will if if synchronizes on
ANYTHING ELSE, and nested synchronized blocks are very common!!) and
it's not threadsafe. Let's make it threadsafe at least, shall we?
"static Node x; static final Object lock = new Object(); synchronized
(lock) { lock(x); body unlock(x);}"
...
uh-oh.
OK, time to give up. Java's "synchronized" cannot be made a user-defined
macro without some kind of catastrophic failure or another happening.
Every attempt to fix one problem causes another. It's like a bump in the
rug that pops up somewhere else whenever you try to smooth it away. I
think this is what Series was getting at before he disappeared from the
face of the planet, too.
So no, synchronized isn't quite like a predefined macro, because it can
use nameless variables, a luxury user-written code in the language
cannot have, for once you've made an anonymous reference how do you use
it again? You can't. A literal C-preprocessor-style macro that just
replaces its calls with itself and the formal parameters in the result
with the actual parameters certainly can't, because the variable name
"x" would be hard-coded and could always collide with something. But
even a Lisp-style macro can't, which can compute its replacement. In
while (node != null) {
Node x = anotherNode();
synchronized (node) {
// do things with node and x
node = node.next;
}
}
no function of the name "node" and the code snippet
"// do things with node and x
node = node.next"
can reliably compute a name that will not cause a problem at that site.
OK, it could avoid using "x" after seeing "x" in the // do things with
node and x part, and at first it looks like you've won (but only if a
lot of very complex code is added to the macro just to compute a safe
name at each call site), until you realize that the need to be able to
nest synchronized blocks means the need to be able to nest macros.
Uh-oh.
Because now // do things with node and x can be a macro call that does
not have a literal "x" in it, but produces "x" by some more indirect
method, and determining whether it will ever produce an expression
containing "x" as a variable name or not is going to be equivalent to
the halting problem.
You're sunk.
The key advantage javac has over your precious Lisp macro is that javac
can compute its "x" from the entire code for the method, not just the
expression in parentheses and the body of the synchronized block. That,
and it needn't worry about macros computing variable names on the fly in
ways it can't predict. Even ignoring the fact that it also doesn't have
to. Lisp macros necessarily can nest and necessarily have tunnel vision.
>> C, not assembly.
>
> What's the difference
Unbelievable. Literally unbelievable. I had to pinch myself to make sure
I was not dreaming.
Is someone really arguing with me, on the topic of computer science,
that shrugs and says "what's the difference" when someone says "C, not
assembly"?
I think we're done here.
>>> You're having problems with Bison and version control because you have no clue
>>> what should go into version control and what shouldn't.
>> You're jumping to unwarranted conclusions about me.
>
> Is that so?
Yep!
> [ad hominem argument]
Calling me names does not an argument in favor of Lisp make.
In fact, you're providing circumstantial evidence in favor of Java, by
way of "Lisp programmers are a rude and surly lot, long on
trash-talking, short on logic skills, and prone to magnify every minor
disagreement of opinion into World War III. Who'd EVER want to have to
work alongside some, or risk becoming that way themselves?" The first
sentence there may not be true, but it is not an unreasonable hypothesis
based on what I have observed here recently, and every time you throw
another insult at me, you furnish one more data point that helps make a
statistical case for its being true.
>> I don't have serious
>> problems with Bison and version control.
>
> I don't have problems with Bison and version control, period.
Of course not, since Lisp coding doesn't tend to involve Bison.
>> I do anticipate there could be
>> serious problems with Lisp code rewriting the (foo foo) bits of itself
>> and version control.
>
> Maybe in Seamus MacRae Lisp
Seamus MacRae lisp, if it even exists, is irrelevant here. I was talking
about Common Lisp. Please do not keep trying to change the subject.
> If that is supposed to be a statement about Common Lisp, then [insults
> me]
One more data point.
> The intermediate results of macroexpansion are not written to a file.
Who said they were? We were talking about a (presumably implemented in
Lisp) pre-processor that altered the code, remember? One that one of you
mentioned a week or so ago.
>>>>> The tool I was describing in that paragraph is called... Emacs.
>>>> You mean, there are two programs with the same name that are otherwise
>>>> as different as night and day?
>>> I saw elsewhere in this thread that you were shown a screenshot of Emacs and
>>> you still denied it was Emacs.
>> I was shown a screenshot and told by a known hostile entity and probable
>> liar that it was emacs, and the screenshot showed something that
>> resembled emacs the way the Eiffel Tower resembles a tea saucer.
>
> Funny, I looked at the PNG and saw only Emacs.
Tunnel vision can be a sign of stroke, certain poisonings, and incipient
heart failure. Seek medical help.
> I didn't know Slime could do embedded graphics.
I didn't know 3 + 3 = 17. And I still don't.
> I'm not an Emacs user, but I believe the PNG.
Don't believe every picture you see on a Web site. Especially if it
shows something implausible like a kangaroo with wings dive-bombing a
tennis court, the phrase "all your base" spelled out by craters on the
moon, or embedded graphics in an application running in an xterm.
>>> The only Emacs is Seamus MacRae Imaginary Emacs.
>> I find that particularly unlikely to be true. I'm adding you to my list
>> of "probable liars" in this thread.
>
> What is a probable liar? Someone who offends you with facts that
> don't agree with your pre-conceived notions?
Someone who makes such obviously false statements as "the only Emacs is
Seamus MacRae Imaginary Emacs". Let's see, there's the original, there's
GOSMACS, there's ... oh, hell, do we even need more than one, let alone
two, let alone still more counterexamples to prove your statement false?
And I'm sure you've heard of at least one of those counterexamples
before which means you weren't merely mistaken, you were, indeed, lying.
And since when is "an application running in an xterm cannot display
true graphics" a "pre-conceived notion" rather than "bleeding obvious"?
> Wouldn't it be easier to maintain a list of non-liars?
There are far too many of them.
> If you want to list probable liars one by one, you will eventually
> need a few gigabytes of space to represent most of the entire world.
I deal with very few on a regular basis.
> Just assume everyone is a liar.
Why should I? I know it's false, since, for instance, I'm not one.
>> I'm sorry, but I don't know of any "Seamus MacRae Lisp".
>
> Right; I will substitute the proper name as soon as you share it with us.
Common Lisp!! What else have we been discussing for what feels like
weeks now?
I think you're feeling additional symptoms of your incipient stroke.
Dial 9-1-1 before it's too late.
On 16 maio, 04:19, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > You select the name of the generic function, hit Alt-., and a list
> > pops up listing all the methods for the generic function and their
> > classes. Then you click on the one you want, and you're taken to the
> > definition. It's really, really similar to looking up definitions in
> > Eclipse.
>
> You assume people are using some particular tool, with a fairly decent
> interface, that I ain't never heard of. From all indications, a straw
> poll here would show most of the other lispers to be using emacs or
> something else equally primitive, though, and there might also be issues
> with getting such a tool to work with different dialects of Lisp reliably.
Guess what? This IS a feature of Emacs + Slime - and I have used this
feature many, many times. You can assume EVERYONE here uses Emacs +
Slime, because the people who don't will say otherwise - since Emacs +
Slime IS the "standard" way to program in CL - not the only one, but
the most used one.
> >>> And there's no problem defining methods from one namespace on classes
> >>> from another namespace.
>
> >> What about using the darn things?
>
> > You just... use them?
>
> Limp. Very limp.
Such a shame what a strange reaction people who never learned CL have
when they hear about what it is possible to do with it.
>
> >> Let me guess, "there's no problem", by
> >> which is meant "it is physically possible, though you'll need a few
> >> tablets of Excedrin afterward and might want to save up a few sick days
> >> first".
>
> > No, I mean, "there's no problem", by which is meant that I can't even
> > figure out what problem you might be referring to.
>
> Fully-qualifying the fuckin' names! What the hell else could I be
> referring to? :P
>
You really NEVER have to do that, and, even when you do have to, it is
using much letters than you might be thinking about now.
> > > I'm really not seeing much difference between that and
>
> > (defclass my-whatsit () ())
>
> > (defmethod print-object ((object my-whatsit) stream)
> > (print-unreadable-object (obj stream)
> > (format stream "I'm a whatsit!")))
>
> > That's all you have to do. No monkeying with any other code anywhere
> > else. No code generation.
>
> Let me guess: no MANUAL code generation. Something in the toolchain does
> it for you.
>
> That's not quite the same thing. And there's no namespace-related stuff
> in your code. OK, there was none in mine, either, but you can just slap
> a "package foo;" at the top of it. Whereas yours requires you to
> defmethod the pre-existing, in some widely used namespace, print-object
> method, with who knows what potential risks if you screw it up.
>
> Oh yeah, I forgot: you're perfect and simply will not ever screw it up.
> Ever. :P
You bet. Just like you won't screw anything up with pointers (which,
believe me, are much more dangerous than this). You insist in this
thing of screwing everything up. With manual pointer manipulation
(and, not the case of Java, but handling allocation and dis-allocation
of memory) is MUCH more dangerous than ANYTHING in Lisp. Believe it or
not.
gugamilare wrote:
> On 16 maio, 04:19, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> You select the name of the generic function, hit Alt-., and a list
>>> pops up listing all the methods for the generic function and their
>>> classes. Then you click on the one you want, and you're taken to the
>>> definition. It's really, really similar to looking up definitions in
>>> Eclipse.
>> You assume people are using some particular tool, with a fairly decent
>> interface, that I ain't never heard of. From all indications, a straw
>> poll here would show most of the other lispers to be using emacs or
>> something else equally primitive, though, and there might also be issues
>> with getting such a tool to work with different dialects of Lisp reliably.
>
> Guess what? This IS a feature of Emacs + Slime
What, a decent interface? Impossible. Trying to graft a decent interface
onto emacs would be like trying to graft an oak tree branch onto a
petunia for God's sake, and trying to do it from inside the editor's
internal scripting language would be like trying to create a "petunia
tree" by adding the gene for lignifying cellulose to the poor plant.
More likely you'd get a dead petunia, or one that tried to eat
Manhattan, rather than a nice new patch of shade in the summer heat.
> Emacs + Slime IS the "standard" way to program in CL - not the only one,
> but the most used one.
If you're trying to sell Java programmers on Lisp, you're doing a
terrible job of it by making statements like this one. We Java
programmers mostly prefer to use things like Eclipse and NetBeans; these
are to emacs as day is to night. (And, having used all three at various
times within the past four years, I can say this with some confidence.
NetBeans maybe has the slight edge on Eclipse, too.)
>>>>> And there's no problem defining methods from one namespace on classes
>>>>> from another namespace.
>>>> What about using the darn things?
>>> You just... use them?
>> Limp. Very limp.
>
> Such a shame what a strange reaction people who never learned CL have
> when they hear about what it is possible to do with it.
Possible isn't the issue. Easy is. Lots of slapping scope operators and
fully-qualifying things everywhere was one of the things that put me off
C++ and inspired me to be rather creative in "extract class" refactoring
of some JEE projects just so I could avoid ever using java.util.Date and
javax.sql.Date in the same source file.
>>>> Let me guess, "there's no problem", by
>>>> which is meant "it is physically possible, though you'll need a few
>>>> tablets of Excedrin afterward and might want to save up a few sick days
>>>> first".
>>> No, I mean, "there's no problem", by which is meant that I can't even
>>> figure out what problem you might be referring to.
>> Fully-qualifying the fuckin' names! What the hell else could I be
>> referring to? :P
>
> You really NEVER have to do that
Inconsistent with the previous batch of quoted text.
> and, even when you do have to, it is
> using much letters than you might be thinking about now.
"Using much letters" is exactly what I'd prefer to avoid. AND NOT BY
"USING MUCH PUNCTUATION" INSTEAD!!
Nevermind the extra typing, *readability* is impacted. Especially by too
much cryptic punctuation. C++ got pretty bad for that, toward the end.
Java has so far managed to mostly avoid it. So far.
>> That's not quite the same thing. And there's no namespace-related stuff
>> in your code. OK, there was none in mine, either, but you can just slap
>> a "package foo;" at the top of it. Whereas yours requires you to
>> defmethod the pre-existing, in some widely used namespace, print-object
>> method, with who knows what potential risks if you screw it up.
>>
>> Oh yeah, I forgot: you're perfect and simply will not ever screw it up.
>> Ever. :P
>
> You bet.
I guess we're done here then.
> You insist in this thing of screwing everything up.
Yep. Definitely done here.
> With manual pointer manipulation
> (and, not the case of Java, but handling allocation and dis-allocation
> of memory) is MUCH more dangerous than ANYTHING in Lisp. Believe it or
> not.
Congratulations. You've just convinced me that Lisp is better than C.
But Java still rules the roost.
Seamus MacRae <··········@live.ca.nospam> writes:
> Every time a serious problem is mentioned, you tend to dismiss it with
> little more than a hand-wave. A can-do attitude is good to have, but
> here it's verging on Pollyanna. You're liable to trip and pitch
> headfirst down a six-hundred-foot chasm while staring up at the pretty
> blue sky if you carry on like that.
Well, if you were to actually LEARN something about Common Lisp first,
perhaps you wouldn't raise so-called "problems" that don't really
exist. I fail to see what sort of response you would otherwise expect.
I mean, what would your response be if someone were to say:
"Java method overrides cause all sorts of problems. If you want
to override an inherited method, first you have to go in and
manually modify the dispatch table, so that your the right
method will be found."
> >>> Same in Common Lisp. Classes can inherit from other classes, and
> >>> generic functions dispatch on the run-time class, respecting
> >>> inheritance relationships.
> >
> >> Inheritance relationships recorded where?
> > In the class definition...? If I want to say that FOO is a subclass of
> > BAR, I just write
> > (defclass foo (bar)
> > ;; This space for rent!.
> > )
>
> Yet earlier someone was saying you'd omit to specify that Complex
> inherited from Number.
Well, it turns out that the inheritance specification is optional. You
only need to specify that inheritance if you actuallly need to inherit
anything. If you are going to implement ALL of the methods, then it
doesn't matter if you inherit from number of not. You would get the
same dispatch.
Flexibility. It's all about flexibility.
> This is absolutely fascinating. Now you're actually becoming visibly
> incoherent.
> >>> Not at all. The necessary modification of the generic function is
> >>> handled automatically (really, CLOS would be remarkably useless if it
> >>> weren't) when you define the new method.
> >
> >> You mean, the source code for a dispatch table you posted is
> >> machine-generated, like yacc output?
> > No, I mean, you never see any of it.
>
> Oh, lovely. Machine-generated code you can't even find and read? It's
> annoying enough to get bison-generated code to play nice with version
> control. Your phantom dispatch tables are going to bedevil any serious
> developer until his hair falls out and his nose gets all wrinkly.
So I assume that you are in the habit of examining the Java method
dispatch tables? Sure, they exist somewhere in the code. But you never
ever look at them. I've been programming Java for quite a while (in
addition to Lisp and a number of other languages), but I've never looked
at the Java dispatch tables. I wouldn't even know where to find them.
Where are they? Do you examine the byte-code the compiler emits, too?
> >> I hate machine-generated code.
> > So do I. It's a very good thing that you don't have to use it to use
> > CLOS.
>
> But ... but ... but ... but you just ...
I think you're being deliberately obtuse.
> Oh, aren't you the clever troll!
>
> >> Your Lisp
> >> dispatch thingies (generic functions, did you say?) must get built from
> >> snippets scattered all over the damn place. Finding all the code that
> >> generates those must be nigh-impossible.
Yet, amazinginly enough, Common Lisp compilers do it all the time.
> > You select the name of the generic function, hit Alt-., and a list
> > pops up listing all the methods for the generic function and their
> > classes. Then you click on the one you want, and you're taken to the
> > definition. It's really, really similar to looking up definitions in
> > Eclipse.
>
> You assume people are using some particular tool, with a fairly decent
> interface, that I ain't never heard of. From all indications, a straw
> poll here would show most of the other lispers to be using emacs or
> something else equally primitive, though, and there might also be issues
> with getting such a tool to work with different dialects of Lisp
> reliably.
Well, the Emacs-based tools do that.
So do other IDEs, such as Allegro's and LispWorks.
But it really doesn't matter what tool it is, because you seem to be
quite able to imagine defects and malign technologies that you've never
bothered to understand, so what difference would it make if you had
heard of the particular systems?
> >>> And there's no problem defining methods from one namespace on classes
> >>> from another namespace.
> >
> >> What about using the darn things?
> > You just... use them?
>
> Limp. Very limp.
But true, very true.
You just invoke the function the same way as any other lisp function.
> >> Let me guess, "there's no problem", by
> >> which is meant "it is physically possible, though you'll need a few
> >> tablets of Excedrin afterward and might want to save up a few sick days
> >> first".
> > No, I mean, "there's no problem", by which is meant that I can't even
> > figure out what problem you might be referring to.
>
> Fully-qualifying the fuckin' names! What the hell else could I be
> referring to? :P
You don't have to do it.
You seem to be getting frustrated that all of your putative objects are
really just whisps of smoke that don't exist in real usage. The
standard answer to your so-called problems really is that it isn't a
problem, because, frankly, it isn't.
Fully qualified names are no more of a problem in Common Lisp than they
are in Java. You occassionally need them if there is a specific
potential naming conflict, but otherwise various importing mechanisms
eliminate the need for it.
> >>> You need to be able to do this to add methods
> >>> for user-defined classes to built-in generic functions (like PRINT-
> >>> OBJECT or INITIALIZE-INSTANCE).
> >
> >> Such a pain, when Java lets you just go
> >
> >> public class MyWhatsit {
> >> @Override
> >> public String toString () {
> >> return "I'm a MyWhatsit!";
> >> }
> >>
> >> }
> >
> >> sticking this in your own namespace and not monkeying with any other
> >> code anywhere (either manually, or by running some sort of
> >> code-generator), yet if a MyWhatsit is subsequently passed to e.g.
> >> String.valueOf(Object), out pops "I'm a MyWhatsit!".
> > I'm really not seeing much difference between that and
> > (defclass my-whatsit () ())
> > (defmethod print-object ((object my-whatsit) stream)
> > (print-unreadable-object (obj stream)
> > (format stream "I'm a whatsit!")))
> > That's all you have to do. No monkeying with any other code anywhere
> > else. No code generation.
>
> Let me guess: no MANUAL code generation. Something in the toolchain does
> it for you.
Well, the only manual code generation is writing the specific part that
applies to the method you want. The linkage to the rest of the system
is handled by the compiler. The same way that you don't have to
manually link up your Java class hierarchy, or figure out the details of
the method dispatch. The language infrastructure does that.
> That's not quite the same thing. And there's no namespace-related stuff
> in your code. OK, there was none in mine, either, but you can just slap
> a "package foo;" at the top of it. Whereas yours requires you to
> defmethod the pre-existing, in some widely used namespace, print-object
> method, with who knows what potential risks if you screw it up.
There are no more risks doing that than doing any other programming
task. You are just adding a method to the name. It's just like adding
a subclass, in many ways.
> Oh yeah, I forgot: you're perfect and simply will not ever screw it
> up. Ever. :P
Not any more than in any other programming language.
> >> Eh, wait a minute, you'd write the four method definitions and then run
> >> that code-generator thingy to generate the new versions of the dispatch
> >> tables.
> > No, you write the four method definitions and then compile them. All
> > the machinery for doing the dispatch is handled by the Lisp
> > implementation transparently.
>
> Like a C++ vtable, then, except that you (or a bug in your code) can
> screw with the vtables for objects from the standard library, the
> vtables for MY objects, ...
No, not like C++ vtables. They work differently.
But you can't screw them up any more than you can screw up the method
dispatch tables that Java generates internally. And dispatch tables
don't belong to classes!
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Every time a serious problem is mentioned, you tend to dismiss it with
>> little more than a hand-wave. A can-do attitude is good to have, but
>> here it's verging on Pollyanna. You're liable to trip and pitch
>> headfirst down a six-hundred-foot chasm while staring up at the pretty
>> blue sky if you carry on like that.
>
> Well, if you were to actually LEARN something about Common Lisp first
There's no call for this rudeness.
> perhaps you wouldn't raise so-called "problems" that don't really
> exist.
But they do exist.
> I mean, what would your response be if someone were to say:
> "Java method overrides cause all sorts of problems. If you want
> to override an inherited method, first you have to go in and
> manually modify the dispatch table, so that your the right
> method will be found."
The thing is, you DON'T have to manually modify Java dispatch tables. In
fact a dynamic linker makes them at runtime. Lisp, on the other hand,
has this
(foo foo) (bar bar)
(foo foo) (baz baz)
stuff explicitly in the source code. It's like faking C++ virtual
methods in C all over again! Everything old is new again! Amaze your
friends!
>>>>> Same in Common Lisp. Classes can inherit from other classes, and
>>>>> generic functions dispatch on the run-time class, respecting
>>>>> inheritance relationships.
>>>> Inheritance relationships recorded where?
>>> In the class definition...? If I want to say that FOO is a subclass of
>>> BAR, I just write
>>> (defclass foo (bar)
>>> ;; This space for rent!.
>>> )
>> Yet earlier someone was saying you'd omit to specify that Complex
>> inherited from Number.
>
> Well, it turns out that the inheritance specification is optional.
And, to judge by other recent posts, useless.
> You only need to specify that inheritance if you actuallly need to
> inherit anything. If you are going to implement ALL of the methods,
> then it doesn't matter if you inherit from number of not. You
> would get the same dispatch.
OK, maybe one use, inheriting un-overridden methods. One very weak use.
All the really good stuff (encapsulation, is-a relationships with type
safety, etc.) apparently goes right out the window with Lisp.
> Flexibility. It's all about flexibility.
Flexibility at the expense of type-safety and encapsulation.
Wonderful for the lone hacker. Terrible for the team effort.
>>>>> Not at all. The necessary modification of the generic function is
>>>>> handled automatically (really, CLOS would be remarkably useless if it
>>>>> weren't) when you define the new method.
>>>> You mean, the source code for a dispatch table you posted is
>>>> machine-generated, like yacc output?
>>> No, I mean, you never see any of it.
>> Oh, lovely. Machine-generated code you can't even find and read? It's
>> annoying enough to get bison-generated code to play nice with version
>> control. Your phantom dispatch tables are going to bedevil any serious
>> developer until his hair falls out and his nose gets all wrinkly.
>
> So I assume that you are in the habit of examining the Java method
> dispatch tables?
Not the same thing. As Anonymous C Lisper told us earlier in the thread,
Lisp's are part of the *source code*, like tables of function pointers
in C. Remember the post with
(foo foo) (bar bar)
(foo foo) (baz baz)
?
> Sure, they exist somewhere in the code.
Not in Java. Java has run-time loading, which creates them on the fly.
Even C++ doesn't have them in the *source* code.
>>>> I hate machine-generated code.
>>> So do I. It's a very good thing that you don't have to use it to use
>>> CLOS.
>> But ... but ... but ... but you just ...
>
> I think you're being deliberately obtuse.
And I think you're being deliberately rude.
>>>> Your Lisp
>>>> dispatch thingies (generic functions, did you say?) must get built from
>>>> snippets scattered all over the damn place. Finding all the code that
>>>> generates those must be nigh-impossible.
>
> Yet, amazinginly enough, Common Lisp compilers do it all the time.
The fuckin' foo-foo shit was in SOURCE CODE, remember??? Sheesh!
Besides I'm more worried about the programmers finding it rather than
the tool-chain; if a bug creeps in it will be a real pain to track down.
This is one reason why very few languages put dispatch tables in the
freaking source code, either putting them in the executable (C++ linker)
or generating them on the fly (Java classloader and JVM "magic").
>> You assume people are using some particular tool, with a fairly decent
>> interface, that I ain't never heard of. From all indications, a straw
>> poll here would show most of the other lispers to be using emacs or
>> something else equally primitive, though, and there might also be issues
>> with getting such a tool to work with different dialects of Lisp
>> reliably.
>
> Well, the Emacs-based tools do that.
Pull the other one.
> So do other IDEs, such as Allegro's and LispWorks.
The phrase "other IDEs" is incongruous here, when no previous IDE had
been mentioned. It would be like saying TextPad did something, and so
did "other IDEs" such as Eclipse and NetBeans.
> But it really doesn't matter what tool it is, because you seem to be
> quite able to imagine defects and malign technologies that you've never
> bothered to understand, so what difference would it make if you had
> heard of the particular systems?
Back to personal attacks and accusations, then, is it? Or hadn't you
noticed that I am arguing largely based on the things that YOU
(collective) have said are true of Lisp? Either my arguments are valid,
then, or you (collective) have been mistaken quite a lot. Take your
(collective) pick.
>>>>> And there's no problem defining methods from one namespace on classes
>>>>> from another namespace.
>>>> What about using the darn things?
>>> You just... use them?
>> Limp. Very limp.
> But true, very true.
> You just invoke the function the same way as any other lisp function.
The devil is in the details.
No, please don't. Seeing the syntax for scoping all this stuff at once
will probably cause me to herniate something throwing up, and I'm all
out of sick days this month after a nasty bout of diarrhoea much of last
week (why do you think I disappeared from this thread for days?) that I
now suspect was induced by the horrible abuse of variable capture
graphically described in post #371. There should be mandatory viewer
discretion warnings on that sort of shit!
>>>> Let me guess, "there's no problem", by
>>>> which is meant "it is physically possible, though you'll need a few
>>>> tablets of Excedrin afterward and might want to save up a few sick days
>>>> first".
>>> No, I mean, "there's no problem", by which is meant that I can't even
>>> figure out what problem you might be referring to.
>> Fully-qualifying the fuckin' names! What the hell else could I be
>> referring to? :P
>
> You don't have to do it.
Of course you can.
> You seem to be getting frustrated that all of your putative objects are
> really just whisps of smoke that don't exist in real usage.
If this is what CLOS use does to your objects, then I want no part of
it, y'hear? No part of it!
("Whisps of smoke that don't exist in real usage" is a very eloquent way
of saying nil, though -- gotta remember that to use that someday.)
> The standard answer to your so-called problems really is that it isn't
> a problem, because, frankly, it isn't.
>
> Fully qualified names are no more of a problem in Common Lisp than they
> are in Java.
Given that you need to qualify twice as much stuff, I find this
unsupported assertion difficult to believe.
> You occassionally need them if there is a specific
> potential naming conflict, but otherwise various importing mechanisms
> eliminate the need for it.
"Occasionally", here, meaning every three lines of code on average, or
only every four?
>>> That's all you have to do. No monkeying with any other code anywhere
>>> else. No code generation.
>> Let me guess: no MANUAL code generation. Something in the toolchain does
>> it for you.
>
> Well, the only manual code generation is writing the specific part that
> applies to the method you want.
For instance, (foo foo) (quux quux) (body), or whatever it was?
> The linkage to the rest of the system is handled by the compiler. The
> same way that you don't have to manually link up your Java class
> hierarchy, or figure out the details of the method dispatch. The
> language infrastructure does that.
Except that with multiple dispatch, it's going to have some very hairy
rules for any auto-generated dispatches. No wonder Anonymous C Lisper
prefers his generic functions to use manual dispatch then.
Figuring out what does what to what and scoping everything correctly was
a nightmare with C++ multiple inheritance. I'm guessing that was nothing
compared to the mess created by multiple dispatch without manual
dispatch table creation. (And manual dispatch table creation, meanwhile,
has colossal scaling problems. Then again so does understanding what's
going on in a big enough class hierarchy with multiple inheritance or
multiple dispatch!)
>> That's not quite the same thing. And there's no namespace-related stuff
>> in your code. OK, there was none in mine, either, but you can just slap
>> a "package foo;" at the top of it. Whereas yours requires you to
>> defmethod the pre-existing, in some widely used namespace, print-object
>> method, with who knows what potential risks if you screw it up.
>
> There are no more risks doing that than doing any other programming
> task. You are just adding a method to the name. It's just like adding
> a subclass, in many ways.
Except for the "another piece of code halfway across the repository is
affected by the change" bit, of course. (The bit with (foo foo) or
similar in it.)
>> Oh yeah, I forgot: you're perfect and simply will not ever screw it
>> up. Ever. :P
>
> Not any more than in any other programming language.
It's the magnitude of the consequences of the screwups that concerns me,
and the amount of work it will take to track down and fix things.
>>>> Eh, wait a minute, you'd write the four method definitions and then run
>>>> that code-generator thingy to generate the new versions of the dispatch
>>>> tables.
>>> No, you write the four method definitions and then compile them. All
>>> the machinery for doing the dispatch is handled by the Lisp
>>> implementation transparently.
>> Like a C++ vtable, then, except that you (or a bug in your code) can
>> screw with the vtables for objects from the standard library, the
>> vtables for MY objects, ...
>
> No
Yes, according to the previous description given.
> But you can't screw them up any more than you can screw up the method
> dispatch tables that Java generates internally.
Sure you can, unless the file containing the (foo foo) (baz baz) stuff
is made read-only by the sysadmin, and then how do you add a new
dispatch when you need one?
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Thomas A. Russ wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>
>>>> Every time a serious problem is mentioned, you tend to dismiss it with
>>>> little more than a hand-wave. A can-do attitude is good to have, but
>>>> here it's verging on Pollyanna. You're liable to trip and pitch
>>>> headfirst down a six-hundred-foot chasm while staring up at the pretty
>>>> blue sky if you carry on like that.
>>> Well, if you were to actually LEARN something about Common Lisp first
>> There's no call for this rudeness.
>>
>>> perhaps you wouldn't raise so-called "problems" that don't really
>>> exist.
>> But they do exist.
>
> Only in your head.
Personal attacks such as this will not help you to rationally address
the issues that I have raised. You will need to discuss the issues
themselves, not your personal opinion of me, in order to successfully
address those issues.
>> The thing is, you DON'T have to manually modify Java dispatch
>> tables. In fact a dynamic linker makes them at runtime. Lisp, on the
>> other hand, has this
>>
>> (foo foo) (bar bar)
>> (foo foo) (baz baz)
>>
>> stuff explicitly in the source code. It's like faking C++ virtual
>> methods in C all over again! Everything old is new again! Amaze your
>> friends!
>
> I don't know what you're talking about, but I /suspect/ you've
> misinterpreted something...
If you'd only focus on the subject matter of the discussion, instead of
being distracted uselessly by your uncharitable thoughts and
*suspicions* about other people here ...
> if you're talking about something like
>
> (defmethod whatever ((foo foo) (bar bar) (baz baz)) ...)
I am not. It started with "defgeneric".
>>> Well, it turns out that the inheritance specification is optional.
>> And, to judge by other recent posts, useless.
>
> Of course it's not useless. But since methods belong to generic
> functions, not classes, you don't have to inherit from a class just to
> get access to its namespace to define your own methods for functions
> defined in that class.
Indeed, it seems inheriting from a class gets you very little in Lisp.
In Lisp, you gain access to no namespace; you can break its
encapsulation anyway, and you can have polymorphic dispatch anyway; and
there is no is-a type relationship enforced by the compiler. About all
you get is the least useful OO feature: inheritance of unoverridden
base-class methods.
On May 20, 3:21 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
>
> >> Thomas A. Russ wrote:
> >>> Seamus MacRae <··········@live.ca.nospam> writes:
>
> >>>> Every time a serious problem is mentioned, you tend to dismiss it with
> >>>> little more than a hand-wave. A can-do attitude is good to have, but
> >>>> here it's verging on Pollyanna. You're liable to trip and pitch
> >>>> headfirst down a six-hundred-foot chasm while staring up at the pretty
> >>>> blue sky if you carry on like that.
> >>> Well, if you were to actually LEARN something about Common Lisp first
> >> There's no call for this rudeness.
>
> >>> perhaps you wouldn't raise so-called "problems" that don't really
> >>> exist.
> >> But they do exist.
>
> > Only in your head.
>
> Personal attacks such as this will not help you to rationally address
> the issues that I have raised. You will need to discuss the issues
> themselves, not your personal opinion of me, in order to successfully
> address those issues.
>
> >> The thing is, you DON'T have to manually modify Java dispatch
> >> tables. In fact a dynamic linker makes them at runtime. Lisp, on the
> >> other hand, has this
>
> >> (foo foo) (bar bar)
> >> (foo foo) (baz baz)
>
> >> stuff explicitly in the source code. It's like faking C++ virtual
> >> methods in C all over again! Everything old is new again! Amaze your
> >> friends!
>
> > I don't know what you're talking about, but I /suspect/ you've
> > misinterpreted something...
>
> If you'd only focus on the subject matter of the discussion, instead of
> being distracted uselessly by your uncharitable thoughts and
> *suspicions* about other people here ...
>
> > if you're talking about something like
>
> > (defmethod whatever ((foo foo) (bar bar) (baz baz)) ...)
>
> I am not. It started with "defgeneric".
>
> >>> Well, it turns out that the inheritance specification is optional.
> >> And, to judge by other recent posts, useless.
>
> > Of course it's not useless. But since methods belong to generic
> > functions, not classes, you don't have to inherit from a class just to
> > get access to its namespace to define your own methods for functions
> > defined in that class.
>
> Indeed, it seems inheriting from a class gets you very little in Lisp.
It gets you more or less what it gets you in Java:
- the subclass intherits the slots (fields) of the superclass
- the methods applicable on the superclass are also applicable on the
subclass
- the subclass can have its own slots
- the subclass can have methods specialized on it
> In Lisp, you gain access to no namespace;
Because there's no need to, since namespaces are not tied to classes.
> you can break its encapsulation anyway,
You can in Java too, using reflection.
> and you can have polymorphic dispatch anyway;
And this is a Good Thing.
> and there is no is-a type relationship enforced by the compiler.
There is a "is-a" relationship. The compiler does not enforce it due
to dynamic typing, but that's another story.
> About all you get is the least useful OO feature: inheritance of unoverridden
> base-class methods.
Read carefully what I wrote above and ask yourself if your statement
above is true.
Cheers,
Alessio
Alessio Stalla wrote:
> On May 20, 3:21 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Indeed, it seems inheriting from a class gets you very little in Lisp.
>
> It gets you more or less what it gets you in Java:
>
> - the subclass intherits the slots (fields) of the superclass
> - the methods applicable on the superclass are also applicable on the
> subclass
> - the subclass can have its own slots
Delegation gets you these too.
> - the subclass can have methods specialized on it
Generic functions get you this too, and with multiple dispatch if you
want it.
>> In Lisp, you gain access to no namespace;
>> you can break its encapsulation anyway,
>
> You can in Java too, using reflection.
Java doesn't encourage you to.
>> and you can have polymorphic dispatch anyway;
>> and there is no is-a type relationship enforced by the compiler.
>
> There is a "is-a" relationship.
Perhaps in the programmer's mind, but it may as well just be part of the
project documentation and not be in the source code and it would still
do as good a job in a language whose compiler does not and cannot
enforce type-safety. Variables are untyped, so can hold any value
whatsoever at least insofar as the compiler is concerned, so there's no
need to inherit so that your class's instances will be assignable to
particular variables declared as being of a supertype; there's no such
thing as a variable type anyway.
>> About all you get is the least useful OO feature: inheritance of unoverridden
>> base-class methods.
>
> Read carefully what I wrote above and ask yourself if your statement
> above is true.
Your public insinuation that I'm a liar is rude and unwelcome. Please
refrain from engaging in such behavior in the future.
On May 20, 5:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 20, 3:21 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Indeed, it seems inheriting from a class gets you very little in Lisp.
>
> > It gets you more or less what it gets you in Java:
>
> > - the subclass intherits the slots (fields) of the superclass
> > - the methods applicable on the superclass are also applicable on the
> > subclass
> > - the subclass can have its own slots
>
> Delegation gets you these too.
Yes, and that's true in Java, too. That's totally orthogonal to the
claim that "inheriting from a class gets you very little in Lisp".
> > - the subclass can have methods specialized on it
>
> Generic functions get you this too, and with multiple dispatch if you
> want it.
Sure, but generic functions respect class hierarchy! If I have a
method specialized on A, it will be invoked on A and its subclasses,
unless there's a more specific method for one of the subclasses. So
subclassing gives you access to the behavior of methods, that you
wouldn't have if you didn't subclass. Just like in Java.
> >> In Lisp, you gain access to no namespace;
> >> you can break its encapsulation anyway,
>
> > You can in Java too, using reflection.
>
> Java doesn't encourage you to.
Neither does Lisp.
> >> and you can have polymorphic dispatch anyway;
> >> and there is no is-a type relationship enforced by the compiler.
>
> > There is a "is-a" relationship.
>
> Perhaps in the programmer's mind,
and in the class hierarchy, which exists in the system's state and not
only in the programmer's mind...
> but it may as well just be part of the
> project documentation and not be in the source code
(defclass A (B) ()) is source code, and declares that every A "is-a"
B: every thing you can do with a B, you can do with an A too.
> and it would still
> do as good a job in a language whose compiler does not and cannot
> enforce type-safety. Variables are untyped, so can hold any value
> whatsoever at least insofar as the compiler is concerned, so there's no
> need to inherit so that your class's instances will be assignable to
> particular variables declared as being of a supertype; there's no such
> thing as a variable type anyway.
But there's a *value* type, and the fact that object X is of class A
or B *does* change runtime behavior, or else classes would be
completely useless. If there's a DRAW method specialized on SHAPE, and
my object is of class CIRCLE, whether CIRCLE inherits or not from
SHAPE *does* change what will happen when I call DRAW with it as a
parameter. I completely fail to see your point here.
> >> About all you get is the least useful OO feature: inheritance of unoverridden
> >> base-class methods.
>
> > Read carefully what I wrote above and ask yourself if your statement
> > above is true.
>
> Your public insinuation that I'm a liar is rude and unwelcome. Please
> refrain from engaging in such behavior in the future.
I'm not saying you're a liar; I'm saying that some of your assumptions
are objectively wrong, and I'm trying to give you evidence of that. I
can stop if you want - I don't get nothing back if you understand.
Alessio
Alessio Stalla wrote:
> On May 20, 5:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> On May 20, 3:21 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Indeed, it seems inheriting from a class gets you very little in Lisp.
>>> It gets you more or less what it gets you in Java:
>>> - the subclass intherits the slots (fields) of the superclass
>>> - the methods applicable on the superclass are also applicable on the
>>> subclass
>>> - the subclass can have its own slots
>> Delegation gets you these too.
>
> Yes, and that's true in Java, too.
Not as nicely as I'll bet you can do it with Lisp macros or just
diddling those dispatch tables.
> That's totally orthogonal to the claim that "inheriting from a class
> gets you very little in Lisp".
It is not.
>>> - the subclass can have methods specialized on it
>> Generic functions get you this too, and with multiple dispatch if you
>> want it.
>
> Sure
>
>>>> In Lisp, you gain access to no namespace;
>>>> you can break its encapsulation anyway,
>>> You can in Java too, using reflection.
>> Java doesn't encourage you to.
>
> Neither does Lisp.
Only because in Lisp there seems to be no encapsulation to break.
>>>> and you can have polymorphic dispatch anyway;
>>>> and there is no is-a type relationship enforced by the compiler.
>>> There is a "is-a" relationship.
>> Perhaps in the programmer's mind,
>
> and in the class hierarchy, which exists in the system's state and not
> only in the programmer's mind...
but which does NOT exist for the compiler. It's just data, like dates in
a java.util.Calendar.
>> but it may as well just be part of the
>> project documentation and not be in the source code
>
> (defclass A (B) ()) is source code, and declares that every A "is-a"
> B: every thing you can do with a B, you can do with an A too.
My point, which you are intentionally trying not to get, is that if that
doesn't *do* much useful beyond save a peck of typing and document the
relationship, then you might as well just document the relationship.
>> and it would still
>> do as good a job in a language whose compiler does not and cannot
>> enforce type-safety. Variables are untyped, so can hold any value
>> whatsoever at least insofar as the compiler is concerned, so there's no
>> need to inherit so that your class's instances will be assignable to
>> particular variables declared as being of a supertype; there's no such
>> thing as a variable type anyway.
>
> But there's a *value* type, and the fact that object X is of class A
> or B *does* change runtime behavior, or else classes would be
> completely useless.
It changes runtime behavior in ways I just explained how you could
accomplish by other means, using the powers of the macros YOU have been
touting.
> If there's a DRAW method specialized on SHAPE, and
> my object is of class CIRCLE, whether CIRCLE inherits or not from
> SHAPE *does* change what will happen when I call DRAW with it as a
> parameter.
Not if you manually diddle the dispatch table in lieu of subclassing SHAPE.
> I completely fail to see your point here.
That is obvious. Perhaps you should clean your reading glasses.
>>>> About all you get is the least useful OO feature: inheritance of unoverridden
>>>> base-class methods.
>>> Read carefully what I wrote above and ask yourself if your statement
>>> above is true.
>> Your public insinuation that I'm a liar is rude and unwelcome. Please
>> refrain from engaging in such behavior in the future.
>
> [naught left but flamage]
Well, this is becoming increasingly useless.
On May 20, 8:33 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 20, 5:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Alessio Stalla wrote:
> >>> On May 20, 3:21 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Indeed, it seems inheriting from a class gets you very little in Lisp.
> >>> It gets you more or less what it gets you in Java:
> >>> - the subclass intherits the slots (fields) of the superclass
> >>> - the methods applicable on the superclass are also applicable on the
> >>> subclass
> >>> - the subclass can have its own slots
> >> Delegation gets you these too.
>
> > Yes, and that's true in Java, too.
>
> Not as nicely as I'll bet you can do it with Lisp macros or just
> diddling those dispatch tables.
Ah, you mean the DEFGENERIC and DEFMETHOD macros?
> > That's totally orthogonal to the claim that "inheriting from a class
> > gets you very little in Lisp".
>
> It is not.
Then, by the same principle inheriting from a class gets you very
little in Java. I don't believe that.
> >>> - the subclass can have methods specialized on it
> >> Generic functions get you this too, and with multiple dispatch if you
> >> want it.
>
> > Sure
>
> >>>> In Lisp, you gain access to no namespace;
> >>>> you can break its encapsulation anyway,
> >>> You can in Java too, using reflection.
> >> Java doesn't encourage you to.
>
> > Neither does Lisp.
>
> Only because in Lisp there seems to be no encapsulation to break.
There can be slots named with internal symbols. These are private,
since you cannot import those symbols in your own package. There is a
way to get at them, just like there is reflection in Java, but it's
generally considered bad practice.
> >>>> and you can have polymorphic dispatch anyway;
> >>>> and there is no is-a type relationship enforced by the compiler.
> >>> There is a "is-a" relationship.
> >> Perhaps in the programmer's mind,
>
> > and in the class hierarchy, which exists in the system's state and not
> > only in the programmer's mind...
>
> but which does NOT exist for the compiler. It's just data, like dates in
> a java.util.Calendar.
Which Lisp compiler(s) have you studied to be sure about this?
> >> but it may as well just be part of the
> >> project documentation and not be in the source code
>
> > (defclass A (B) ()) is source code, and declares that every A "is-a"
> > B: every thing you can do with a B, you can do with an A too.
>
> My point, which you are intentionally trying not to get, is that if that
> doesn't *do* much useful beyond save a peck of typing and document the
> relationship, then you might as well just document the relationship.
My point, instead, it's that it's NOT documentation because IT HAS
EFFECTS on the behavior of the program!
(defmethod m ((x some-class)) 42)
(defclass c1 () ())
(defclass c2 (some-class) ())
(m (make-instance 'c1)) => error, no applicable method!
(m (make-instance 'c2)) => 42
> >> and it would still
> >> do as good a job in a language whose compiler does not and cannot
> >> enforce type-safety. Variables are untyped, so can hold any value
> >> whatsoever at least insofar as the compiler is concerned, so there's no
> >> need to inherit so that your class's instances will be assignable to
> >> particular variables declared as being of a supertype; there's no such
> >> thing as a variable type anyway.
>
> > But there's a *value* type, and the fact that object X is of class A
> > or B *does* change runtime behavior, or else classes would be
> > completely useless.
>
> It changes runtime behavior in ways I just explained how you could
> accomplish by other means, using the powers of the macros YOU have been
> touting.
I'm already using those powers, by using the macros DEFCLASS,
DEFGENERIC, and DEFMETHOD. I could accomplish the same things with
other means maybe, but why, since there's a perfectly working built-in
solution?
> > If there's a DRAW method specialized on SHAPE, and
> > my object is of class CIRCLE, whether CIRCLE inherits or not from
> > SHAPE *does* change what will happen when I call DRAW with it as a
> > parameter.
>
> Not if you manually diddle the dispatch table in lieu of subclassing SHAPE.
>
> > I completely fail to see your point here.
>
> That is obvious. Perhaps you should clean your reading glasses.
Where in the code I posted do you see a dispatch table?
> >>>> About all you get is the least useful OO feature: inheritance of unoverridden
> >>>> base-class methods.
> >>> Read carefully what I wrote above and ask yourself if your statement
> >>> above is true.
> >> Your public insinuation that I'm a liar is rude and unwelcome. Please
> >> refrain from engaging in such behavior in the future.
>
> > [naught left but flamage]
>
> Well, this is becoming increasingly useless.
Man, you're right on this one.
Alessio Stalla wrote:
> On May 20, 8:33 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> That's totally orthogonal to the claim that "inheriting from a class
>>> gets you very little in Lisp".
>> It is not.
>
> Then, by the same principle inheriting from a class gets you very
> little in Java.
No, for reasons I've already explained. In Java you get:
* Assignability to references of the base type(s) (compile-time "is-a")
(no Lisp equivalent),
* Polymorphism (in Lisp you can easily get this without inheritance),
* Tidy delegation of unspecialized methods to base type(s) (in Lisp
you can get this without inheritance with a bit of work),
* Documentation of is-a relationship (in Lisp you can get this with
actual documentation), and
* Access to protected members of base type(s) (no Lisp equivalent).
>>>>> - the subclass can have methods specialized on it
>>>> Generic functions get you this too, and with multiple dispatch if you
>>>> want it.
>>> Sure
>>>>>> In Lisp, you gain access to no namespace;
>>>>>> you can break its encapsulation anyway,
>>>>> You can in Java too, using reflection.
>>>> Java doesn't encourage you to.
>>> Neither does Lisp.
>> Only because in Lisp there seems to be no encapsulation to break.
>
> There can be slots named with internal symbols. These are private,
> since you cannot import those symbols in your own package.
So, private in Lisp == "has to fully qualify name" rather than actually
private. How fascinating.
>>> and in the class hierarchy, which exists in the system's state and not
>>> only in the programmer's mind...
>> but which does NOT exist for the compiler. It's just data, like dates in
>> a java.util.Calendar.
>
> Which Lisp compiler(s) have you studied to be sure about this?
The ones that know about numbers, strings, symbols, cons cells,
functions, macros, and very little else*. You know -- Lisp compilers!
>>>> but it may as well just be part of the
>>>> project documentation and not be in the source code
>>> (defclass A (B) ()) is source code, and declares that every A "is-a"
>>> B: every thing you can do with a B, you can do with an A too.
>> My point, which you are intentionally trying not to get, is that if that
>> doesn't *do* much useful beyond save a peck of typing and document the
>> relationship, then you might as well just document the relationship.
>
> My point, instead, it's that it's NOT documentation because IT HAS
> EFFECTS on the behavior of the program!
Effects that I have now had to explain THREE TIMES Lisp lets you get
anyway, unlike Java where you *have* to implement an interface or extend
a class.
> (m (make-instance 'c1)) => error, no applicable method!
Yep. Kablooey!
>> It changes runtime behavior in ways I just explained how you could
>> accomplish by other means, using the powers of the macros YOU have been
>> touting.
>
> I'm already using those powers
Strange then that when it suits you you appear to suddenly forget they
ever existed.
>>> If there's a DRAW method specialized on SHAPE, and
>>> my object is of class CIRCLE, whether CIRCLE inherits or not from
>>> SHAPE *does* change what will happen when I call DRAW with it as a
>>> parameter.
>> Not if you manually diddle the dispatch table in lieu of subclassing SHAPE.
>>
>>> I completely fail to see your point here.
>> That is obvious. Perhaps you should clean your reading glasses.
>
> Where in the code I posted do you see a dispatch table?
I'm thinking of the one in the code Anonymous C Lisper posted. You
neglected to include one in your earlier posts.
>>>>>> About all you get is the least useful OO feature: inheritance of unoverridden
>>>>>> base-class methods.
>>>>> Read carefully what I wrote above and ask yourself if your statement
>>>>> above is true.
>>>> Your public insinuation that I'm a liar is rude and unwelcome. Please
>>>> refrain from engaging in such behavior in the future.
>>> [naught left but flamage]
>> Well, this is becoming increasingly useless.
>
> [implied insult]
Useless.
* Except parentheses. Lots and lots of parentheses. They're experts in
those.
On May 20, 11:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > Which Lisp compiler(s) have you studied to be sure about this?
>
> The ones that know about numbers, strings, symbols, cons cells,
> functions, macros, and very little else*. You know -- Lisp compilers!
uh...
First of all, Lisp has multidimensional arrays. Strings and bit-
vectors are special cases of the more general array type, which has
been mentioned in this thread already.
Secondly, not all Lisp compilers are the same. The halfway-decent ones
have CLOS built in -- in other words, it's implemented much more
efficiently and natively than the original CLOS libraries.
Have some self respect and do your research before you make a fool of
yourself again.
On 20 maio, 17:54, Adlai <·········@gmail.com> wrote:
> On May 20, 11:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> > Alessio Stalla wrote:
> > > Which Lisp compiler(s) have you studied to be sure about this?
>
> > The ones that know about numbers, strings, symbols, cons cells,
> > functions, macros, and very little else*. You know -- Lisp compilers!
I don't know which Lisp you tried, but it must be a very bad one.
> uh...
> First of all, Lisp has multidimensional arrays. Strings and bit-
> vectors are special cases of the more general array type, which has
> been mentioned in this thread already.
You still have forgotten to mention hash-tables, functions,
conditions, structures, pathnames, many kinds of streams, classes,
methods, generic functions (yes, those are Lisp objects as well), and
implementation-specific types like foreign data, sockets, gray-
streams, locks, threads, ...
http://www.lispworks.com/documentation/HyperSpec/Body/04_bc.htm
On May 21, 12:18 am, gugamilare <··········@gmail.com> wrote:
> On 20 maio, 17:54, Adlai <·········@gmail.com> wrote:
>
> > On May 20, 11:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> > > Alessio Stalla wrote:
> > > > Which Lisp compiler(s) have you studied to be sure about this?
>
> > > The ones that know about numbers, strings, symbols, cons cells,
> > > functions, macros, and very little else*. You know -- Lisp compilers!
>
> I don't know which Lisp you tried, but it must be a very bad one.
>
> > uh...
> > First of all, Lisp has multidimensional arrays. Strings and bit-
> > vectors are special cases of the more general array type, which has
> > been mentioned in this thread already.
>
> You still have forgotten to mention hash-tables, functions,
> conditions, structures, pathnames, many kinds of streams, classes,
> methods, generic functions (yes, those are Lisp objects as well), and
> implementation-specific types like foreign data, sockets, gray-
> streams, locks, threads, ...
>
> http://www.lispworks.com/documentation/HyperSpec/Body/04_bc.htm
Yeah, but we don't use those anyways because we just party like it's
1969...
I have a feeling that alienating Seamus might be the healthiest thing
for everybody involved. It would save him many of those trips to the
pharmacy for tylenol.
Adlai wrote:
> On May 21, 12:18 am, gugamilare <··········@gmail.com> wrote:
>> You still have forgotten to mention hash-tables, functions,
>> conditions, structures, pathnames, many kinds of streams, classes,
>> methods, generic functions (yes, those are Lisp objects as well), and
>> implementation-specific types like foreign data, sockets, gray-
>> streams, locks, threads, ...
The point being missed here is that if you make a class foo, and a
subclass bar, foo and bar do NOT join this set. They are not put on an
equal footing with rationals and conses and symbols, so "rationals and
conses and symbols and foos" would be a sensible grouping. Not like how
Java makes Foo and Bar have an equal footing with String and Integer
and, more importantly, have the uniformity in the type system that the
same basic rules apply to all reference types. And most importantly of
all, the compiler is free to REASON about Foos and Bars instead of only
being able to reason about Objects.
> I have a feeling that alienating Seamus might be the healthiest thing
Now we have an overt act of incitement of hostility here. This might
even be illegal in some parts of the world. Including the United States
-- ever heard of Lori Drew?
Shame on you, Adlai, and on anyone else who ever says such an awful
thing as "I think alienating <person> might be the healthiest thing" and
apparently means it as a recommendation.
On May 22, 11:23 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Adlai wrote:
> > On May 21, 12:18 am, gugamilare <··········@gmail.com> wrote:
> >> You still have forgotten to mention hash-tables, functions,
> >> conditions, structures, pathnames, many kinds of streams, classes,
> >> methods, generic functions (yes, those are Lisp objects as well), and
> >> implementation-specific types like foreign data, sockets, gray-
> >> streams, locks, threads, ...
>
> The point being missed here is that if you make a class foo, and a
> subclass bar, foo and bar do NOT join this set. They are not put on an
> equal footing with rationals and conses and symbols, so "rationals and
> conses and symbols and foos" would be a sensible grouping. Not like how
> Java makes Foo and Bar have an equal footing with String and Integer
> and, more importantly, have the uniformity in the type system that the
> same basic rules apply to all reference types. And most importantly of
> all, the compiler is free to REASON about Foos and Bars instead of only
> being able to reason about Objects.
Actually, they are. Everything has a type in Lisp, and since CLOS was
added to the language standard, everything has a class. Lisp had this
idea before Ruby, Java, or Blub.[1]
>
> > I have a feeling that alienating Seamus might be the healthiest thing
>
> Now we have an overt act of incitement of hostility here. This might
> even be illegal in some parts of the world. Including the United States
> -- ever heard of Lori Drew?
>
> Shame on you, Adlai, and on anyone else who ever says such an awful
> thing as "I think alienating <person> might be the healthiest thing" and
> apparently means it as a recommendation.
Come on Seamus, please recognize some humor. I realize that you can't
see my face or hear my tone of thought as I type posts, but please try
and take everything with a grain of salt. Also, note that you cut off
my quote mid-sentance -- something that you got a bit ticked-off about
when somebody did that to you only a few posts ago.
- Adlai
[1] http://paulgraham.com/avg.html
Adlai wrote:
> On May 22, 11:23 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Adlai wrote:
>>> On May 21, 12:18 am, gugamilare <··········@gmail.com> wrote:
>>>> You still have forgotten to mention hash-tables, functions,
>>>> conditions, structures, pathnames, many kinds of streams, classes,
>>>> methods, generic functions (yes, those are Lisp objects as well), and
>>>> implementation-specific types like foreign data, sockets, gray-
>>>> streams, locks, threads, ...
>> The point being missed here is that if you make a class foo, and a
>> subclass bar, foo and bar do NOT join this set. They are not put on an
>> equal footing with rationals and conses and symbols, so "rationals and
>> conses and symbols and foos" would be a sensible grouping. Not like how
>> Java makes Foo and Bar have an equal footing with String and Integer
>> and, more importantly, have the uniformity in the type system that the
>> same basic rules apply to all reference types. And most importantly of
>> all, the compiler is free to REASON about Foos and Bars instead of only
>> being able to reason about Objects.
>
> [calls me a liar]
This is getting tiresome.
>>> I have a feeling that alienating Seamus might be the healthiest thing
>> Now we have an overt act of incitement of hostility here. This might
>> even be illegal in some parts of the world. Including the United States
>> -- ever heard of Lori Drew?
>>
>> Shame on you, Adlai, and on anyone else who ever says such an awful
>> thing as "I think alienating <person> might be the healthiest thing" and
>> apparently means it as a recommendation.
>
> Come on Seamus, please recognize some humor.
I didn't find anything about that thrice-damned incitement to be
humorous in the least, so if it was meant as such, you'll forgive me for
not recognizing it.
Next time, I recommend that your humor actually be funny -- then it's
less likely to go unidentified.
> I realize that you can't see my face or hear my tone of thought as I
> type posts, but please try and take everything with a grain of salt.
Rest assured that I have been doing so for quite a while now. And I now
qualify for a bulk discount from my supplier too.
> Also, note that you cut off my quote mid-sentance -- something that
> you got a bit ticked-off about when somebody did that to you only a
> few posts ago.
The difference being that the instance that ticked me off did so in such
a manner as to misrepresent what I'd said.
Seamus MacRae <··········@live.ca.nospam> writes:
> Adlai wrote:
> > [calls me a liar]
>
> This is getting tiresome.
Hamlet, Act 3, scene 2, 230.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Adlai wrote:
>>> [calls me a liar]
>> This is getting tiresome.
>
> Hamlet, Act 3, scene 2, 230.
Incoherent.
Seamus MacRae <··········@live.ca.nospam> writes:
> Adlai wrote:
> > On May 21, 12:18 am, gugamilare <··········@gmail.com> wrote:
> >> You still have forgotten to mention hash-tables, functions,
> >> conditions, structures, pathnames, many kinds of streams, classes,
> >> methods, generic functions (yes, those are Lisp objects as well), and
> >> implementation-specific types like foreign data, sockets, gray-
> >> streams, locks, threads, ...
>
> The point being missed here is that if you make a class foo, and a
> subclass bar, foo and bar do NOT join this set.
Um, could you cite the part of the Common Lisp specification that
supports this statement?
All I could find was
"Defining a new class also causes a type of the same name to be
defined."
which seems to say exactly the opposite of what you claim.
See http://www.lispworks.com/documentation/HyperSpec/Body/m_defcla.htm
Perhaps it is time for you to actually read the specification before you
proceed to make pronoucements of what is, or is not, in Common Lisp.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 22, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
> > Adlai wrote:
> > > On May 21, 12:18 am, gugamilare <··········@gmail.com> wrote:
> > >> You still have forgotten to mention hash-tables, functions,
> > >> conditions, structures, pathnames, many kinds of streams, classes,
> > >> methods, generic functions (yes, those are Lisp objects as well), and
> > >> implementation-specific types like foreign data, sockets, gray-
> > >> streams, locks, threads, ...
>
> > The point being missed here is that if you make a class foo, and a
> > subclass bar, foo and bar do NOT join this set.
>
> Um, could you cite the part of the Common Lisp specification that
> supports this statement?
>
> All I could find was
> "Defining a new class also causes a type of the same name to be
> defined."
> which seems to say exactly the opposite of what you claim.
>
> Seehttp://www.lispworks.com/documentation/HyperSpec/Body/m_defcla.htm
>
> Perhaps it is time for you to actually read the specification before you
> proceed to make pronoucements of what is, or is not, in Common Lisp.
Calling Seamus a liar behind his back seems to be your favorite
pastime.
gugamilare wrote:
> On 20 maio, 17:54, Adlai <·········@gmail.com> wrote:
>> On May 20, 11:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>
>>> Alessio Stalla wrote:
>>>> Which Lisp compiler(s) have you studied to be sure about this?
>>> The ones that know about numbers, strings, symbols, cons cells,
>>> functions, macros, and very little else*. You know -- Lisp compilers!
>
> I don't know which Lisp you tried, but it must be a very bad one.
It's Common Lisp. Which has, as you should well know, rational, float,
complex, symbol, cons cell, vector, and stream. Rational includes the
integers and vector includes the strings.
That's it.
> You still have forgotten to mention hash-tables, functions,
> conditions, structures, pathnames, many kinds of streams, classes,
> methods, generic functions (yes, those are Lisp objects as well), and
> implementation-specific types like foreign data, sockets, gray-
> streams, locks, threads, ...
None of these are fundamental. Hash-tables are implemented on vectors.
Functions are lists, i.e. ultimately made of cons cells, at least
semantically, though the compiler may generate code that actually
represents them differently as an optimization. Most of the rest are
ultimately built out of conses or arrays.
Adlai wrote:
> On May 20, 11:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> Which Lisp compiler(s) have you studied to be sure about this?
>> The ones that know about numbers, strings, symbols, cons cells,
>> functions, macros, and very little else*. You know -- Lisp compilers!
>
> uh...
> First of all, Lisp has multidimensional arrays. Strings and bit-
> vectors are special cases of the more general array type, which has
> been mentioned in this thread already.
Yes, but the most frequently encountered example is the string, so I
said "strings".
> Secondly, not all Lisp compilers are the same. The halfway-decent ones
> have CLOS built in -- in other words, it's implemented much more
> efficiently and natively than the original CLOS libraries.
But to be standards-compliant, it must behave semantically (if not
speed-wise or memory-consumption-wise) identically to a basic,
bog-standard Lisp compiler and separate CLOS library. And then it can't
actually do anything else with CLOS-related knowledge BUT optimize.
> Have some self respect and do your research before you make a fool of
> yourself again.
This vicious personal attack has no business being here. It does not
advance your case for Lisp over Java nor does it accomplish any other
worthwhile goal, unless you consider alienating people to be a
worthwhile goal.
On May 20, 4:59 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Adlai wrote:
> > On May 20, 11:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Alessio Stalla wrote:
> >>> Which Lisp compiler(s) have you studied to be sure about this?
> >> The ones that know about numbers, strings, symbols, cons cells,
> >> functions, macros, and very little else*. You know -- Lisp compilers!
>
> > uh...
> > First of all, Lisp has multidimensional arrays. Strings and bit-
> > vectors are special cases of the more general array type, which has
> > been mentioned in this thread already.
>
> Yes, but the most frequently encountered example is the string, so I
> said "strings".
>
Please stop these vicious personal attacks!
> > Secondly, not all Lisp compilers are the same. The halfway-decent ones
> > have CLOS built in -- in other words, it's implemented much more
> > efficiently and natively than the original CLOS libraries.
>
> But to be standards-compliant, it must behave semantically (if not
> speed-wise or memory-consumption-wise) identically to a basic,
> bog-standard Lisp compiler and separate CLOS library. And then it can't
> actually do anything else with CLOS-related knowledge BUT optimize.
>
What would it do other than optimize?
There's this thing called the meta object protocol that is kind of
neat.
I bet you could implement Java.
> > Have some self respect and do your research before you make a fool of
> > yourself again.
>
> This vicious personal attack has no business being here. It does not
> advance your case for Lisp over Java nor does it accomplish any other
> worthwhile goal, unless you consider alienating people to be a
> worthwhile goal.
Seriously I think you need to declare the troll accomplished and find
someone new to bait... this is getting old.
No one believes that you actually consider that to be a /vicious/
personal attack.
I'm quite please that I got you all to say frobnobdicate over and
over, however.
Gave me a chuckle, anyway..
··················@gmail.com wrote:
> On May 20, 4:59 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Adlai wrote:
>>> On May 20, 11:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Alessio Stalla wrote:
>>>>> Which Lisp compiler(s) have you studied to be sure about this?
>>>> The ones that know about numbers, strings, symbols, cons cells,
>>>> functions, macros, and very little else*. You know -- Lisp compilers!
>>> uh...
>>> First of all, Lisp has multidimensional arrays. Strings and bit-
>>> vectors are special cases of the more general array type, which has
>>> been mentioned in this thread already.
>> Yes, but the most frequently encountered example is the string, so I
>> said "strings".
>>
> Please stop these vicious personal attacks!
What?
That's a complete non-sequitur. There's no personal attack in my
statement. How can "yes, but the most frequently encountered example is
the string, so I said strings" *possibly* constitute a personal attack
against you or anybody else?
>>> Secondly, not all Lisp compilers are the same. The halfway-decent ones
>>> have CLOS built in -- in other words, it's implemented much more
>>> efficiently and natively than the original CLOS libraries.
>> But to be standards-compliant, it must behave semantically (if not
>> speed-wise or memory-consumption-wise) identically to a basic,
>> bog-standard Lisp compiler and separate CLOS library. And then it can't
>> actually do anything else with CLOS-related knowledge BUT optimize.
>
> What would it do other than optimize?
Irrelevant. Anything else would break compatibility with CL, by making
some valid CL code (particularly CL code that is not valid if assumed to
be CLOS code but that is not CLOS code) not work correctly or else not
compile.
>> This vicious personal attack has no business being here. It does not
>> advance your case for Lisp over Java nor does it accomplish any other
>> worthwhile goal, unless you consider alienating people to be a
>> worthwhile goal.
>
> Seriously I think you need to declare the troll accomplished and find
> someone new to bait
Another personal attack! You should learn how to properly debate
something. Calling your opponent names is tantamount to admitting you've
lost the argument.
> No one believes that you actually consider that to be a /vicious/
> personal attack.
Why? Lots of people consider being called a fool, especially in public
and before an audience, to be a vicious personal attack, because it is
one. So it isn't exactly hard to believe. There's no reason not to take
my statement that I am one of them at face value, since it's not a
particularly implausible claim and since there is circumstantial
evidence in favor of it, and none against the alternative. None of you
know me anyway, so why would you have any preconceived notions whether I
do or don't consider it "vicious"?
Your behavior is mystifying. Many of your beliefs are mystifying. And
this has nothing whatsoever to do with either Java or Lisp.
> I'm quite please that I got you all to say frobnobdicate over and
> over, however.
>
> Gave me a chuckle, anyway..
This suggests ego and the derivation of gratification from exerting some
sort of influence or dominance, rather than reason, motivates your
actions here. This is not good.
Arne Vajh�j wrote:
> Adlai wrote:
>> Have some self respect and do your research before you make a fool of
>> yourself again.
>
> Optimist !
These pointless jabs and pokes do not advance your case for Lisp. All
they do is make the both of you look like mean-spirited, egotistical
idiots that, lacking rational arguments that will sway me, resort to
chest-beating and rudeness in a primal, instinctive attempt to get their
way by dominance instead.
Unfortunately for you, that does not work on me, here in this
environment. If you want to convince me you will need to use EVIdence.
If you have none, then you cannot convince me and will have to accept
that fact and agree to disagree with me.
Them's the breaks.
On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
> Arne Vajhøj wrote:
>> Adlai wrote:
>>> Have some self respect and do your research before you make a fool of
>>> yourself again.
>>
>> Optimist !
>
> These pointless jabs and pokes do not advance your case for Lisp. All
I'm a comp.lang.lisp regular, and most of the names behind these jabs and pokes
are completely new to me.
For instance, let's see, looking at Arne's posting history on Google Groups,
it's concentrated Java and C# newsgroups, and in a small sample of it
I have not discovered Lisp advocacy.
[Nice to meet you, Arne.]
It looks like you're attracting jabs and pokes from your comp.lang.java fellows.
Kaz Kylheku wrote:
> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Arne Vajhøj wrote:
>>> Adlai wrote:
>>>> Have some self respect and do your research before you make a fool of
>>>> yourself again.
>>> Optimist !
>> These pointless jabs and pokes do not advance your case for Lisp. All
>
> I'm a comp.lang.lisp regular, and most of the names behind these jabs and pokes
> are completely new to me.
It is a well-known fact that, however they might be disavowed by its
mainstream, the extremists of a movement have a tendency to tarnish the
image of that movement if they act in a violent or otherwise uncivilized
manner.
It therefore is wise for those participating in a movement to try to
keep their own side's extremists in check, lest they give them all a bad
name.
> For instance, let's see, looking at Arne's posting history on Google Groups,
> it's concentrated Java and C# newsgroups, and in a small sample of it
> I have not discovered Lisp advocacy.
I just did the same check. It seems he has a tendency to flame people
throughout comp.* and has had for years. He mixes these with a
smattering of on-topic posts, which probably prevents him losing his net
access for being a tosser. (A spot-check of 20 randomly selected posts
of his had 7 presumptively on-topic-and-useful posts across four grouos,
two in comp.lang.java.programmer, and 13 flames and otherwise off-topic
posts. Two were bitching about some spam. Seven were in a single thread
in comp.lang.java.programmer and were flames; the thread has over 5000
posts and Google needed some coaxing to display it, at first insisting
that the thread did not exist. The other four ranged from rude and
snappy replies to various newbies in newsgroups to outright flames.
> [Nice to meet you, Arne.]
To judge by his posting history and my own recent experience, no, it is
not nice to meet Arne.
> It looks like you're attracting jabs and pokes from your
> comp.lang.java fellows.
They probably don't like that this thread is largely about Lisp now, and
hence off-topic there.
Unfortunately, I've been publicly badmouthed there and so I must
publicly respond there to explain why I'm actually in the right here, so
they will have to either ignore or learn to tolerate the off-topic posts
until this dies down. Posting their own flames in here will only prolong
matters, as I end up having to respond to those, too, and some of them
draw yet more responses like this latest one drew a reply from you.
Double unfortunately, Arne appears not to be the tolerant type. If he'd
just set his newsreader to mark this thread read automatically, we'd all
be a lot happier.
Seamus MacRae wrote:
> Kaz Kylheku wrote:
>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Arne Vajhøj wrote:
>>>> Adlai wrote:
>>>>> Have some self respect and do your research before you make a fool of
>>>>> yourself again.
>>>> Optimist !
>>> These pointless jabs and pokes do not advance your case for Lisp. All
>>
>> I'm a comp.lang.lisp regular, and most of the names behind these jabs
>> and pokes
>> are completely new to me.
>
> It is a well-known fact that, however they might be disavowed by its
> mainstream, the extremists of a movement have a tendency to tarnish the
> image of that movement if they act in a violent or otherwise uncivilized
> manner.
>
> It therefore is wise for those participating in a movement to try to
> keep their own side's extremists in check, lest they give them all a bad
> name.
>
>> For instance, let's see, looking at Arne's posting history on Google
>> Groups,
>> it's concentrated Java and C# newsgroups, and in a small sample of it
>> I have not discovered Lisp advocacy.
>
> I just did the same check. It seems he has a tendency to flame people
> throughout comp.* and has had for years.
So you accused me of advocating for Lisp because you think I flame
people.
Brilliant piece of logic.
Worthy of Monty Python.
>> [Nice to meet you, Arne.]
>
> To judge by his posting history and my own recent experience, no, it is
> not nice to meet Arne.
I consider you saying that to be an honor.
>> It looks like you're attracting jabs and pokes from your
>> comp.lang.java fellows.
>
> They probably don't like that this thread is largely about Lisp now, and
> hence off-topic there.
So the people from cljp attack you because they consider the thread
off-topic.
Another brilliant piece of logic.
> Unfortunately, I've been publicly badmouthed there and so I must
> publicly respond there to explain why I'm actually in the right here,
That sounds familiar.
Arne
Arne Vajhøj wrote:
> Seamus MacRae wrote:
>> Kaz Kylheku wrote:
>>> For instance, let's see, looking at Arne's posting history on Google
>>> Groups,
>>> it's concentrated Java and C# newsgroups, and in a small sample of it
>>> I have not discovered Lisp advocacy.
>>
>> I just did the same check. It seems he has a tendency to flame people
>> throughout comp.* and has had for years.
>
> So you accused me of advocating for Lisp because you think I flame
> people.
No. I accused you of flaming people because you flame people.
How can anyone "accuse" anyone of advocating for Lisp, when advocating
for Lisp is not inherently wrong in the manner that being a chronic
flamer is?
The only time anyone inferred that you were advocating for Lisp was when
you insulted and argued with the two remaining Java advocates in the
thread and with none of the Lisp advocates. This implies the choice of a
particular side.
> Worthy of Monty Python.
Why, thank you.
>>> [Nice to meet you, Arne.]
>>
>> To judge by his posting history and my own recent experience, no, it
>> is not nice to meet Arne.
>
> I consider you saying that to be an honor.
You take pride in being a brutish, angry man whose primary means of
self-expression is the put-down?
>>> It looks like you're attracting jabs and pokes from your
>>> comp.lang.java fellows.
>>
>> They probably don't like that this thread is largely about Lisp now,
>> and hence off-topic there.
>
> So the people from cljp attack you because they consider the thread
> off-topic.
I'm glad you have reached the same conclusion.
>> Unfortunately, I've been publicly badmouthed there and so I must
>> publicly respond there to explain why I'm actually in the right here,
>
> That sounds familiar.
Since it is normal human nature, it would be unless you were from Pluto
or something.
Seamus MacRae wrote:
> Arne Vajhøj wrote:
>> Seamus MacRae wrote:
>>> Unfortunately, I've been publicly badmouthed there and so I must
>>> publicly respond there to explain why I'm actually in the right here,
>>
>> That sounds familiar.
>
> Since it is normal human nature, it would be unless you were from Pluto
> or something.
Arne referred to your hang-up about having to "correct" every posting
disagreeing with you. He is familiar with that from previous encounters
with your other aliases (Twisted, Jerry Gerrone, etc, etc, in absurdum).
Your behaviour is, fortunately, not normal human behaviour.
The really interesting thing in this trash is how fast the various
"entities" respond, just check the posting time. Perhaps the fricken
idiot humans still posting can check that and see exactly how good
Eliza-Expansion or whatisname have been coded. Java is good for
something it appears.
I declare Turing Test victory!
On May 23, 6:04 pm, GP lisper <····@ClouDancer.com> wrote:
> The really interesting thing in this trash is how fast the various
> "entities" respond, just check the posting time. Perhaps the fricken
> idiot humans still posting can check that and see exactly how good
> Eliza-Expansion or whatisname have been coded. Java is good for
> something it appears.
>
> I declare Turing Test victory!
Actually, I think Eliza is too big a compliment for these folks... I
would guess Henley.
To read about Henley, look at section 8.8 of ANSI Common Lisp by Paul
Graham. This book is not available online, though the code is, so you
could look the code up there... or just seach the text "henley" on one
of these pages:
http://www.perlmonks.org/?node_id=494297
http://www.cs.northwestern.edu/academics/courses/325/exercises/graham-exs.html
- Adlai
On May 23, 2:46 pm, Adlai <·········@gmail.com> wrote:
> On May 23, 6:04 pm, GP lisper <····@ClouDancer.com> wrote:
>
> > The really interesting thing in this trash is how fast the various
> > "entities" respond, just check the posting time. Perhaps the fricken
> > idiot humans still posting can check that and see exactly how good
> > Eliza-Expansion or whatisname have been coded. Java is good for
> > something it appears.
>
> > I declare Turing Test victory!
>
> Actually, I think Eliza is too big a compliment for these folks... I
> would guess Henley.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Adlai and GP Lisper.
On May 23, 11:04 am, GP lisper <····@ClouDancer.com> wrote:
> The really interesting thing in this trash is how fast the various
> "entities" respond, just check the posting time. Perhaps the fricken
> idiot humans still posting can check that and see exactly how good
> Eliza-Expansion or whatisname have been coded.
The name is Series Expansion, and I am not an AI.
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Arne Vajhøj wrote:
>>> Seamus MacRae wrote:
>>>> Unfortunately, I've been publicly badmouthed there and so I must
>>>> publicly respond there to explain why I'm actually in the right here,
>>>
>>> That sounds familiar.
>>
>> Since it is normal human nature, it would be unless you were from
>> Pluto or something.
>
> Arne referred to
I am well aware of what Arne referred to. It has been addressed by me
above, and it is not relevant to either Lisp or Java. Please let it drop.
> your hang-up about having to "correct" every posting disagreeing
> with you.
This is not productive or worthwhile. Personal attacks convince no one
of anything, and in fact tend to lead both sides to entrench their
positions and refuse to budge, for to do otherwise could be seen as an
admission. Therefore, your strategy is in fact actively counterproductive.
Furthermore, the particular characteristic you attribute to me is
incorrect. I shall note that I make a distinction between posts that
disagree with me but agree to disagree with me, and posts that disagree
with me and assert or imply that all those who do not agree with their
authors are idiots.
> He is familiar with that from previous encounters with your other
> aliases
Now you are departing completely from the realm of meaningful and
intelligent discourse and entering the realm of paranoia. Nothing useful
can be established with wild accusations backed by insults instead of by
anything remotely resembling evidence, particularly when said
accusations are apropos of nothing.
On May 23, 9:34 am, Lars Enderin <············@telia.com> wrote:
> Seamus MacRae wrote:
> > Arne Vajhøj wrote:
> >> Seamus MacRae wrote:
> >>> Unfortunately, I've been publicly badmouthed there and so I must
> >>> publicly respond there to explain why I'm actually in the right here,
>
> >> That sounds familiar.
>
> > Since it is normal human nature, it would be unless you were from Pluto
> > or something.
>
> Arne referred to your [insult deleted]. He is familiar with that from
> previous encounters with your other aliases (Twisted, Jerry Gerrone,
> etc, etc, [implied insult deleted]). Your behaviour is [implied insult
> deleted].
No. Seamus is not me and none of the nasty things that you have said
or implied about me are at all true.
Kaz Kylheku wrote:
> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Arne Vajhøj wrote:
>>> Adlai wrote:
>>>> Have some self respect and do your research before you make a fool of
>>>> yourself again.
>>> Optimist !
>> These pointless jabs and pokes do not advance your case for Lisp. All
>
> I'm a comp.lang.lisp regular, and most of the names behind these jabs and pokes
> are completely new to me.
>
> For instance, let's see, looking at Arne's posting history on Google Groups,
> it's concentrated Java and C# newsgroups, and in a small sample of it
> I have not discovered Lisp advocacy.
That is correct.
I would have a hard time advocating Lisp since I do not code in Lisp.
(I know that lack of actual knowledge does not deter everyone
from arguing, but ...)
> [Nice to meet you, Arne.]
Thank you. Nice to meet you.
Arne
Arne Vajhøj wrote:
> Kaz Kylheku wrote:
>> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Arne Vajhøj wrote:
>>>> Adlai wrote:
>>>>> Have some self respect and do your research before you make a fool of
>>>>> yourself again.
>>>> Optimist !
>>> These pointless jabs and pokes do not advance your case for Lisp. All
>>
>> I'm a comp.lang.lisp regular, and most of the names behind these jabs and pokes
>> are completely new to me.
It is a well-known fact that, however they might be disavowed by its
mainstream, the extremists of a movement have a tendency to tarnish the
image of that movement if they act in a violent or otherwise uncivilized
manner.
It therefore is wise for those participating in a movement to try to
keep their own side's extremists in check, lest they give them all a bad
name.
>> For instance, let's see, looking at Arne's posting history on Google Groups,
>> it's concentrated Java and C# newsgroups, and in a small sample of it
>> I have not discovered Lisp advocacy.
I just did the same check. It seems he has a tendency to flame people
throughout comp.* and has had for years. He mixes these with a
smattering of on-topic posts, which probably prevents him losing his net
access for being a tosser. (A spot-check of 20 randomly selected posts
of his had 7 presumptively on-topic-and-useful posts across four grouos,
two in comp.lang.java.programmer, and 13 flames and otherwise off-topic
posts. Two were bitching about some spam. Seven were in a single thread
in comp.lang.java.programmer and were flames; the thread has over 5000
posts and Google needed some coaxing to display it, at first insisting
that the thread did not exist. The other four ranged from rude and
snappy replies to various newbies in newsgroups to outright flames.
> [calls me a liar]
Am not.
> (I know that lack of actual knowledge does not deter everyone
> from arguing
Least of all you.
>> [Nice to meet you, Arne.]
To judge by his posting history and my own recent experience, no, it is
not nice to meet Arne.
> Thank you. Nice to meet you.
Doubtful in the extreme.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Adlai wrote:
>>> Have some self respect and do your research before you make a fool of
>>> yourself again.
>>
>> Optimist !
>
> These pointless jabs and pokes do not advance your case for Lisp.
Wrong again. I am not trying to make a case for Lisp at all.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Adlai wrote:
>>>> Have some self respect and do your research before you make a fool of
>>>> yourself again.
>>>
>>> Optimist !
>>
>> These pointless jabs and pokes do not advance your case for Lisp.
>
> Wrong again.
No, it is perfectly true that your pointless jabs and pokes do not
advance the case for Lisp.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Seamus MacRae wrote:
>>> Arne Vajh�j wrote:
>>>> Adlai wrote:
>>>>> Have some self respect and do your research before you make a fool of
>>>>> yourself again.
>>>>
>>>> Optimist !
>>>
>>> These pointless jabs and pokes do not advance your case for Lisp.
>>
>> Wrong again. I am not trying to make a case for Lisp at all.
>
> No, it is perfectly true that your pointless jabs and pokes do not
> advance the case for Lisp.
You missed the point again.
It is not my case for Lisp.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Seamus MacRae wrote:
>>>> These pointless jabs and pokes do not advance your case for Lisp.
>>>
>>> Wrong again.
>>
>> No, it is perfectly true that your pointless jabs and pokes do not
>> advance the case for Lisp.
>
> You missed the point again.
I did not. I said your pointless jabs and pokes did not advance the case
for Lisp. You said that that was incorrect. I pointed out that it was
not incorrect.
On May 20, 10:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > Then, by the same principle inheriting from a class gets you very
> > little in Java.
>
> No, for reasons I've already explained. In Java you get:
> * Assignability to references of the base type(s) (compile-time "is-a")
> (no Lisp equivalent),
In Lisp you always have assignability, since variables have no type,
only values have.
> * Polymorphism (in Lisp you can easily get this without inheritance),
The fact you can get it without inheritance does not mean inheritance
does not give it to you.
> * Tidy delegation of unspecialized methods to base type(s) (in Lisp
> you can get this without inheritance with a bit of work),
The only sensible way I know of doing this in Lisp is using
inheritance.
> * Documentation of is-a relationship (in Lisp you can get this with
> actual documentation), and
And by a DEFCLASS form, which is code and not documentation, and gives
you runtime is-a behavior.
> * Access to protected members of base type(s) (no Lisp equivalent).
The Lisp equivalent is access to slots of the base type.
[snip]
>
> > There can be slots named with internal symbols. These are private,
> > since you cannot import those symbols in your own package.
>
> So, private in Lisp == "has to fully qualify name" rather than actually
> private. How fascinating.
Fully qualify using a different kind of notation:
package:external-symbol ("public") vs
package::internal-symbol ("private").
The latter, while possible, is generally considered bad practice. Just
like setAccessible(true) when using reflection in Java to access
private fields.
> >>> and in the class hierarchy, which exists in the system's state and not
> >>> only in the programmer's mind...
> >> but which does NOT exist for the compiler. It's just data, like dates in
> >> a java.util.Calendar.
>
> > Which Lisp compiler(s) have you studied to be sure about this?
>
> The ones that know about numbers, strings, symbols, cons cells,
> functions, macros, and very little else*. You know -- Lisp compilers!
I know Lisp compilers, and I know they can and often do take CLOS into
account.
> >>>> but it may as well just be part of the
> >>>> project documentation and not be in the source code
> >>> (defclass A (B) ()) is source code, and declares that every A "is-a"
> >>> B: every thing you can do with a B, you can do with an A too.
> >> My point, which you are intentionally trying not to get, is that if that
> >> doesn't *do* much useful beyond save a peck of typing and document the
> >> relationship, then you might as well just document the relationship.
>
> > My point, instead, it's that it's NOT documentation because IT HAS
> > EFFECTS on the behavior of the program!
>
> Effects that I have now had to explain THREE TIMES Lisp lets you get
> anyway, unlike Java where you *have* to implement an interface or extend
> a class.
Again, no:
(m (make-instance 'c2)) => 42
would exhibit a different behavior if c2 did not inherit from some-
class.
> > (m (make-instance 'c1)) => error, no applicable method!
>
> Yep. Kablooey!
??
> >> It changes runtime behavior in ways I just explained how you could
> >> accomplish by other means, using the powers of the macros YOU have been
> >> touting.
>
> > I'm already using those powers
>
> Strange then that when it suits you you appear to suddenly forget they
> ever existed.
I mean I'm using DEFCLASS, DEFGENERIC and DEFMETHOD, which *are*
macros. Just not written by me ;)
[snip total useless flaming]
Alessio Stalla wrote:
> On May 20, 10:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> Then, by the same principle inheriting from a class gets you very
>>> little in Java.
>> No, for reasons I've already explained. In Java you get:
>> * Assignability to references of the base type(s) (compile-time "is-a")
>> (no Lisp equivalent),
>
> In Lisp you always have assignability, since variables have no type,
> only values have.
Exactly my point: you no longer get this assignability from inheritance,
because you have it even without.
>> * Polymorphism (in Lisp you can easily get this without inheritance),
>
> The fact you can get it without inheritance does not mean inheritance
> does not give it to you.
It does mean inheritance isn't required to get it.
>> * Tidy delegation of unspecialized methods to base type(s) (in Lisp
>> you can get this without inheritance with a bit of work),
>
> The only sensible way I know of doing this in Lisp is using
> inheritance.
No, just having a dispatch in a generic function in each class suffices.
They needn't be related at all.
>> * Documentation of is-a relationship (in Lisp you can get this with
>> actual documentation), and
>
> And by a DEFCLASS form, which is code and not documentation, and gives
> you runtime is-a behavior.
WHAT "runtime is-a behavior"? I've just run down the list. Can assign to
variables that can hold an X: in CL you can do so without inheriting
from X. Can have a method dispatch to different versions depending on
whether some argument is an X or an instance of your class: in CL you
can do so without inheriting from X. Can access protected methods of X:
in CL there are no "protected" methods, so moot.
>>> There can be slots named with internal symbols. These are private,
>>> since you cannot import those symbols in your own package.
>> So, private in Lisp == "has to fully qualify name" rather than actually
>> private. How fascinating.
>
> Fully qualify using a different kind of notation
Fully qualify.
In other words, there is no real "private". Anyone can access anything,
even without using reflection or something equally hairy that says
"Danger -- use sparingly" with its awkwardness.
So much for encapsulation.
> package:external-symbol ("public") vs
> package::internal-symbol ("private").
>
> The latter, while possible, is generally considered bad practice. Just
> like setAccessible(true) when using reflection in Java to access
> private fields.
Java doesn't allow you to access a private field inadvertently with a
single slip of a finger.
>>>>> and in the class hierarchy, which exists in the system's state and not
>>>>> only in the programmer's mind...
>>>> but which does NOT exist for the compiler. It's just data, like dates in
>>>> a java.util.Calendar.
>>> Which Lisp compiler(s) have you studied to be sure about this?
>> The ones that know about numbers, strings, symbols, cons cells,
>> functions, macros, and very little else*. You know -- Lisp compilers!
>
> I know Lisp compilers, and I know they can and often do take CLOS into
> account.
In their optimizations. As explained elsewhere, they can do little else
without risking breaking other legal CL code, including very likely any
implementation of a CLOS-like object system that was slightly different
from CLOS.
>>>>>> but it may as well just be part of the
>>>>>> project documentation and not be in the source code
>>>>> (defclass A (B) ()) is source code, and declares that every A "is-a"
>>>>> B: every thing you can do with a B, you can do with an A too.
>>>> My point, which you are intentionally trying not to get, is that if that
>>>> doesn't *do* much useful beyond save a peck of typing and document the
>>>> relationship, then you might as well just document the relationship.
>>> My point, instead, it's that it's NOT documentation because IT HAS
>>> EFFECTS on the behavior of the program!
>> Effects that I have now had to explain THREE TIMES Lisp lets you get
>> anyway, unlike Java where you *have* to implement an interface or extend
>> a class.
>
> Again, no
Yes, it was three times. It is now four, but it was three at the time
that I wrote that.
> (m (make-instance 'c2)) => 42
>
> would exhibit a different behavior if c2 did not inherit from some-
> class.
Unless you did the appropriate defgeneric, defmethod stuff to create a
specialization of m for c2 "the hard way".
>>>> It changes runtime behavior in ways I just explained how you could
>>>> accomplish by other means, using the powers of the macros YOU have been
>>>> touting.
>>> I'm already using those powers
>> Strange then that when it suits you you appear to suddenly forget they
>> ever existed.
>
> I mean I'm using DEFCLASS, DEFGENERIC and DEFMETHOD, which *are*
> macros. Just not written by me ;)
Writing them is what I was referring to.
And must you randomly write the same identifiers in all-caps sometimes
and not others?
> [snip total useless flaming]
There'd be less of it to snip if you posted less of it to begin with.
(Though also, admittedly, if I quoted less of it when you did.)
On May 22, 5:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 20, 10:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Alessio Stalla wrote:
> >>> Then, by the same principle inheriting from a class gets you very
> >>> little in Java.
> >> No, for reasons I've already explained. In Java you get:
> >> * Assignability to references of the base type(s) (compile-time "is-a")
> >> (no Lisp equivalent),
>
> > In Lisp you always have assignability, since variables have no type,
> > only values have.
>
> Exactly my point: you no longer get this assignability from inheritance,
> because you have it even without.
So, inheritance does not give you something you already have. Well, I
don't see it as a problem of inheritance :)
> >> * Polymorphism (in Lisp you can easily get this without inheritance),
>
> > The fact you can get it without inheritance does not mean inheritance
> > does not give it to you.
>
> It does mean inheritance isn't required to get it.
Your original claim was that "inheritance gives you very little". Not
that "inheritance is not required for enough things".
> >> * Tidy delegation of unspecialized methods to base type(s) (in Lisp
> >> you can get this without inheritance with a bit of work),
>
> > The only sensible way I know of doing this in Lisp is using
> > inheritance.
>
> No, just having a dispatch in a generic function in each class suffices.
> They needn't be related at all.
No, because A inheriting from B means that all methods applicable to B
are automatically also applicable to A, and you don't get this without
inheritance.
> >> * Documentation of is-a relationship (in Lisp you can get this with
> >> actual documentation), and
>
> > And by a DEFCLASS form, which is code and not documentation, and gives
> > you runtime is-a behavior.
>
> WHAT "runtime is-a behavior"? I've just run down the list. Can assign to
> variables that can hold an X: in CL you can do so without inheriting
> from X. Can have a method dispatch to different versions depending on
> whether some argument is an X or an instance of your class: in CL you
> can do so without inheriting from X. Can access protected methods of X:
> in CL there are no "protected" methods, so moot.
- you inherit slots.
- you inherit methods.
- you answer 'yes' to 'am-I-subclass-of' questions.
- you answer 'yes' to 'am-I-subtype-of' questions.
> >>> There can be slots named with internal symbols. These are private,
> >>> since you cannot import those symbols in your own package.
> >> So, private in Lisp == "has to fully qualify name" rather than actually
> >> private. How fascinating.
>
> > Fully qualify using a different kind of notation
>
> Fully qualify.
>
> In other words, there is no real "private". Anyone can access anything,
> even without using reflection or something equally hairy that says
> "Danger -- use sparingly" with its awkwardness.
>
> So much for encapsulation.
There is, it's only easier to circumvent if you want to.
> > package:external-symbol ("public") vs
> > package::internal-symbol ("private").
>
> > The latter, while possible, is generally considered bad practice. Just
> > like setAccessible(true) when using reflection in Java to access
> > private fields.
>
> Java doesn't allow you to access a private field inadvertently with a
> single slip of a finger.
Java itself doesn't, but many Java libraries can and do freely access
private fields (e.g. Hibernate, JAXB). Making them much less "private"
than they are, imho.
> >>>>> and in the class hierarchy, which exists in the system's state and not
> >>>>> only in the programmer's mind...
> >>>> but which does NOT exist for the compiler. It's just data, like dates in
> >>>> a java.util.Calendar.
> >>> Which Lisp compiler(s) have you studied to be sure about this?
> >> The ones that know about numbers, strings, symbols, cons cells,
> >> functions, macros, and very little else*. You know -- Lisp compilers!
>
> > I know Lisp compilers, and I know they can and often do take CLOS into
> > account.
>
> In their optimizations. As explained elsewhere, they can do little else
> without risking breaking other legal CL code, including very likely any
> implementation of a CLOS-like object system that was slightly different
> from CLOS.
What else should they do besides optimizations? Are you referring to
type checking?
> >>>>>> but it may as well just be part of the
> >>>>>> project documentation and not be in the source code
> >>>>> (defclass A (B) ()) is source code, and declares that every A "is-a"
> >>>>> B: every thing you can do with a B, you can do with an A too.
> >>>> My point, which you are intentionally trying not to get, is that if that
> >>>> doesn't *do* much useful beyond save a peck of typing and document the
> >>>> relationship, then you might as well just document the relationship.
> >>> My point, instead, it's that it's NOT documentation because IT HAS
> >>> EFFECTS on the behavior of the program!
> >> Effects that I have now had to explain THREE TIMES Lisp lets you get
> >> anyway, unlike Java where you *have* to implement an interface or extend
> >> a class.
>
> > Again, no
>
> Yes, it was three times. It is now four, but it was three at the time
> that I wrote that.
>
> > (m (make-instance 'c2)) => 42
>
> > would exhibit a different behavior if c2 did not inherit from some-
> > class.
>
> Unless you did the appropriate defgeneric, defmethod stuff to create a
> specialization of m for c2 "the hard way".
No. No. No. You CANNOT automatically have an existing method work on
your class WITHOUT inheritance. The only "hard way" is COPY-PASTING
the existing method and specializing it for your class - ugh. Better
use inheritance, no?
> >>>> It changes runtime behavior in ways I just explained how you could
> >>>> accomplish by other means, using the powers of the macros YOU have been
> >>>> touting.
> >>> I'm already using those powers
> >> Strange then that when it suits you you appear to suddenly forget they
> >> ever existed.
>
> > I mean I'm using DEFCLASS, DEFGENERIC and DEFMETHOD, which *are*
> > macros. Just not written by me ;)
>
> Writing them is what I was referring to.
Well, then I don't use any other means.
> And must you randomly write the same identifiers in all-caps sometimes
> and not others?
I write them in all-caps when I want to stress they're identifiers.
Maybe I should always write them in all-caps, but I don't always
remember to.
> There'd be less of it to snip if you posted less of it to begin with.
> (Though also, admittedly, if I quoted less of it when you did.)
Alessio Stalla wrote:
[snip]
Please stop posting five minutes after I post, in the interests of
letting me get caught up so I can move on to other tasks. I do have
other things to do than defend myself against you and your pals, you
know, and it is disrespectful to keep me jumping like this without any
time to even catch a breather. Furthermore, please try to limit your
posts to a reasonable length. This one isn't as ludicrously long as some
of your recent posts have been, but it isn't exactly short either.
> On May 22, 5:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> On May 20, 10:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Alessio Stalla wrote:
>>>>> Then, by the same principle inheriting from a class gets you very
>>>>> little in Java.
>>>> No, for reasons I've already explained. In Java you get:
>>>> * Assignability to references of the base type(s) (compile-time "is-a")
>>>> (no Lisp equivalent),
>>> In Lisp you always have assignability, since variables have no type,
>>> only values have.
>> Exactly my point: you no longer get this assignability from inheritance,
>> because you have it even without.
>
> So, inheritance does not give you something you already have.
But I've just demonstrated unequivocally that (in CL) it does.
>>>> * Polymorphism (in Lisp you can easily get this without inheritance),
>>> The fact you can get it without inheritance does not mean inheritance
>>> does not give it to you.
>> It does mean inheritance isn't required to get it.
>
> Your original claim was that "inheritance gives you very little".
Yes, and we've established that it gives you what, access to superclass
fields? And that's it. Everything else can be had elsewhere.
>>>> * Tidy delegation of unspecialized methods to base type(s) (in Lisp
>>>> you can get this without inheritance with a bit of work),
>>> The only sensible way I know of doing this in Lisp is using
>>> inheritance.
>> No, just having a dispatch in a generic function in each class suffices.
>> They needn't be related at all.
>
> No
Yes.
Just give each method of A a version in B as well and away you go.
> - you inherit slots.
Maybe do need inheritance for this.
> - you inherit methods.
Can get methods in other ways, and retain polymorphic dispatch.
> - you answer 'yes' to 'am-I-subclass-of' questions.
> - you answer 'yes' to 'am-I-subtype-of' questions.
Can no doubt get that in some other way as well. Hopefully don't need to
-- those are similar to Java instanceof, which it's recommended one
avoid unless it's absolutely necessary.
>> In other words, there is no real "private". Anyone can access anything,
>> even without using reflection or something equally hairy that says
>> "Danger -- use sparingly" with its awkwardness.
>>
>> So much for encapsulation.
>
> There is, it's only easier to circumvent if you want to.
And it's coarse-grained as hell.
>>> package:external-symbol ("public") vs
>>> package::internal-symbol ("private").
>>> The latter, while possible, is generally considered bad practice. Just
>>> like setAccessible(true) when using reflection in Java to access
>>> private fields.
>> Java doesn't allow you to access a private field inadvertently with a
>> single slip of a finger.
>
> Java itself doesn't, but many Java libraries can and do freely access
> private fields (e.g. Hibernate, JAXB). Making them much less "private"
> than they are, imho.
Perhaps those libraries are poorly designed. There are alternatives that
do their jobs, though, and you're not stuck with them. With CL, you are
stuck with ::.
>>>>>>> and in the class hierarchy, which exists in the system's state and not
>>>>>>> only in the programmer's mind...
>>>>>> but which does NOT exist for the compiler. It's just data, like dates in
>>>>>> a java.util.Calendar.
>>>>> Which Lisp compiler(s) have you studied to be sure about this?
>>>> The ones that know about numbers, strings, symbols, cons cells,
>>>> functions, macros, and very little else*. You know -- Lisp compilers!
>>> I know Lisp compilers, and I know they can and often do take CLOS into
>>> account.
>> In their optimizations. As explained elsewhere, they can do little else
>> without risking breaking other legal CL code, including very likely any
>> implementation of a CLOS-like object system that was slightly different
>> from CLOS.
>
> What else should they do besides optimizations? Are you referring to
> type checking?
Among other things.
Various niceties that users of Java and similar programming languages
have come to expect from their tools over the years.
Scoped name autocomplete in IDEs. Certain trickier optimizations. Doc
generation. Lots of stuff like that.
>>> (m (make-instance 'c2)) => 42
>>> would exhibit a different behavior if c2 did not inherit from some-
>>> class.
>> Unless you did the appropriate defgeneric, defmethod stuff to create a
>> specialization of m for c2 "the hard way".
>
> No. No. No.
Yes. Yes. Yes.
> You CANNOT automatically have an existing method work on your class
> WITHOUT inheritance.
Who said anything about "automatically"? You snuck that in there to try
to move the goal-posts, didn't you? Because I certainly don't recall
stipulating "automatically" anywhere.
> The only "hard way" is COPY-PASTING the existing method and
> specializing it for your class - ugh. Better use inheritance, no?
Maybe. Strictly necessary? No.
>>>>>> It changes runtime behavior in ways I just explained how you could
>>>>>> accomplish by other means, using the powers of the macros YOU have been
>>>>>> touting.
>>>>> I'm already using those powers
>>>> Strange then that when it suits you you appear to suddenly forget they
>>>> ever existed.
>>> I mean I'm using DEFCLASS, DEFGENERIC and DEFMETHOD, which *are*
>>> macros. Just not written by me ;)
>> Writing them is what I was referring to.
>
> Well, then I don't use any other means.
OK, then.
On May 22, 9:50 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
>
> [snip]
>
> Please stop posting five minutes after I post, in the interests of
> letting me get caught up so I can move on to other tasks. I do have
> other things to do than defend myself against you and your pals, you
> know, and it is disrespectful to keep me jumping like this without any
> time to even catch a breather. Furthermore, please try to limit your
> posts to a reasonable length. This one isn't as ludicrously long as some
> of your recent posts have been, but it isn't exactly short either.
I just answered another of your posts, and this precisely demonstrates
my point there; you are not in control in this conversation, but are
trying to be. But you can't help yourself; you must post, and here
you are complaining that others are keeping you jumping. In reality,
nobody is doing any such thing; any jumping you are doing you are
doing all on your own. If you truly want control, then take control,
including control over the urge you have to answer every argument and
to answer every argument quickly. It will do your health a world of
good.
Duane
·····@franz.com wrote:
> On May 22, 9:50 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>
>> [snip]
>>
>> Please stop posting five minutes after I post, in the interests of
>> letting me get caught up so I can move on to other tasks. I do have
>> other things to do than defend myself against you and your pals, you
>> know, and it is disrespectful to keep me jumping like this without any
>> time to even catch a breather. Furthermore, please try to limit your
>> posts to a reasonable length. This one isn't as ludicrously long as some
>> of your recent posts have been, but it isn't exactly short either.
>
> I just answered another of your posts, and this precisely demonstrates
> my point there; you are not in control in this conversation
I'm not sure I care for your threatening tone.
> you must post, and here you are complaining that others are keeping
> you jumping.
If I set out to catch up on Usenet, then once I have begun I must reply
to any posts that say incorrect things, especially if they say incorrect
things about me, personally, in public where other people might read
them and be misled.
If people continue to flood the newsgroup with more incorrect postings,
then it makes it difficult to get caught up and be able to say "there,
I'm done" and move on to another task.
> If you truly want control, then take control, including control over
> the urge you have to answer every argument
Not every argument. Every argument that says or insinuates something
unpleasant about me, either by vigorously disagreeing with something I
said or by containing overt personal attacks, perhaps. But nobody sane
would want something like that aimed at them being on the public record,
but as yet unchallenged, now would they?
On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> ·····@franz.com wrote:
> > On May 22, 9:50 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Alessio Stalla wrote:
>
> >> [snip]
>
> >> Please stop posting five minutes after I post, in the interests of
> >> letting me get caught up so I can move on to other tasks. I do have
> >> other things to do than defend myself against you and your pals, you
> >> know, and it is disrespectful to keep me jumping like this without any
> >> time to even catch a breather. Furthermore, please try to limit your
> >> posts to a reasonable length. This one isn't as ludicrously long as some
> >> of your recent posts have been, but it isn't exactly short either.
>
> > I just answered another of your posts, and this precisely demonstrates
> > my point there; you are not in control in this conversation
>
> I'm not sure I care for your threatening tone.
No threat. Just an observation. You are not in control of yourself.
You must post. Just as you must answer me. You have no control.
> > you must post, and here you are complaining that others are keeping
> > you jumping.
>
> If I set out to catch up on Usenet, then once I have begun I must reply
> to any posts that say incorrect things, especially if they say incorrect
> things about me, personally, in public where other people might read
> them and be misled.
Then let them be misled. Right now, they get the wrong idea about
you, because they laugh at your inability to back down from an
argument. Only after you've mastered the art of walking away can you
master the art of controlling people's viewpoints.
> If people continue to flood the newsgroup with more incorrect postings,
> then it makes it difficult to get caught up and be able to say "there,
> I'm done" and move on to another task.
Not at all. for someone who is in control, it is easy to walk away
and say "there, I'm done". You know how to do that? Just walk away
and say "there, I'm done.".
> > If you truly want control, then take control, including control over
> > the urge you have to answer every argument
>
> Not every argument. Every argument that says or insinuates something
> unpleasant about me, either by vigorously disagreeing with something I
> said or by containing overt personal attacks, perhaps. But nobody sane
> would want something like that aimed at them being on the public record,
> but as yet unchallenged, now would they?
Of course they would, if they are in control of themselves. But I
don't expect you to understand this, because you can't control
yourself.
Duane
·····@franz.com wrote:
> On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> ·····@franz.com wrote:
>>> On May 22, 9:50 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Alessio Stalla wrote:
>>>> [snip]
>>>> Please stop posting five minutes after I post, in the interests of
>>>> letting me get caught up so I can move on to other tasks. I do have
>>>> other things to do than defend myself against you and your pals, you
>>>> know, and it is disrespectful to keep me jumping like this without any
>>>> time to even catch a breather. Furthermore, please try to limit your
>>>> posts to a reasonable length. This one isn't as ludicrously long as some
>>>> of your recent posts have been, but it isn't exactly short either.
>>> I just answered another of your posts, and this precisely demonstrates
>>> my point there; you are not in control in this conversation
>> I'm not sure I care for your threatening tone.
>
> No threat.
You implied a threat to disrespect my wishes and continue to publicly
badmouth me, right there in that quoted text.
>> If I set out to catch up on Usenet, then once I have begun I must reply
>> to any posts that say incorrect things, especially if they say incorrect
>> things about me, personally, in public where other people might read
>> them and be misled.
>
> Then let them be misled.
That would be unwise.
> Right now, they get the wrong idea about you, because they laugh at you
So you claim. I think you would not be making that claim unless it
served your purpose. Since your purpose seems to be to have the last
word and to do so at my expense, and since that would have undesirable
consequences for me, it follows that you are probably attempting to
deceive me into pursing a poor strategy that will enable you to have
that all-important last word.
Therefore I should ignore what you are suggesting.
> Only after you've mastered the art of walking away can you
> master the art of controlling people's viewpoints.
Once again you err. I am not interested in controlling people's
viewpoints. I had some things to say about Lisp versus Java.
Subsequently, I have endeavored to correct the public record regarding
my own person, after several people set about to doctor that record. At
first I believe they did so inadvertently, by arguing about Lisp in ways
that unfortunately insinuated things about me that were inaccurate.
However, it is now apparent that at least some of you are doing it
deliberately, though you formerly were either silent or doing it
accidentally.
Shame on you.
Regardless, you are all entitled to your personal opinions and
viewpoints and I would not dream of trying to change those by force.
However, what you publish in writing about me is another matter entirely
and I am entitled by law to some influence over that.
>> If people continue to flood the newsgroup with more incorrect postings,
>> then it makes it difficult to get caught up and be able to say "there,
>> I'm done" and move on to another task.
>
> Not at all.
Yes, it does. Why are you accusing me of lying, when I have no motive to
do so and especially when the evidence clearly supports what I said?
> for someone who is in control, it is easy to walk away
> and say "there, I'm done". You know how to do that? Just walk away
> and say "there, I'm done.".
In other words, you suggest that I should lie about whether I've
actually caught up on usenet, by claiming to have done so when I have
not? How illogical.
>>> If you truly want control, then take control, including control over
>>> the urge you have to answer every argument
>> Not every argument. Every argument that says or insinuates something
>> unpleasant about me, either by vigorously disagreeing with something I
>> said or by containing overt personal attacks, perhaps. But nobody sane
>> would want something like that aimed at them being on the public record,
>> but as yet unchallenged, now would they?
>
> Of course they would
No, they would not. None would ordinarily prefer that the public record
contain an erroneous negative statement about them than that the public
record contained no such statements.
The rest of your insulting and vaguely threatening post has been deleted
unread. Have a nice day.
On May 22, 10:52 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> ·····@franz.com wrote:
> > On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> ·····@franz.com wrote:
> >>> On May 22, 9:50 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Alessio Stalla wrote:
> >>>> [snip]
> >>>> Please stop posting five minutes after I post, in the interests of
> >>>> letting me get caught up so I can move on to other tasks. I do have
> >>>> other things to do than defend myself against you and your pals, you
> >>>> know, and it is disrespectful to keep me jumping like this without any
> >>>> time to even catch a breather. Furthermore, please try to limit your
> >>>> posts to a reasonable length. This one isn't as ludicrously long as some
> >>>> of your recent posts have been, but it isn't exactly short either.
> >>> I just answered another of your posts, and this precisely demonstrates
> >>> my point there; you are not in control in this conversation
> >> I'm not sure I care for your threatening tone.
>
> > No threat.
>
> You implied a threat to disrespect my wishes and continue to publicly
> badmouth me, right there in that quoted text.
You who are so concerned about losing respect have already done so,
and long before I entered this conversation.
There was no threat. The disaster you created for your reputation was
intricately woven by you in this whole thread.
> >> If I set out to catch up on Usenet, then once I have begun I must reply
> >> to any posts that say incorrect things, especially if they say incorrect
> >> things about me, personally, in public where other people might read
> >> them and be misled.
>
> > Then let them be misled.
>
> That would be unwise.
Have it your way.
> > Right now, they get the wrong idea about you, because they laugh at you
>
> So you claim. I think you would not be making that claim unless it
> served your purpose. Since your purpose seems to be to have the last
> word and to do so at my expense, and since that would have undesirable
> consequences for me, it follows that you are probably attempting to
> deceive me into pursing a poor strategy that will enable you to have
> that all-important last word.
>
> Therefore I should ignore what you are suggesting.
You have not been able to do so yet.
> > Only after you've mastered the art of walking away can you
> > master the art of controlling people's viewpoints.
>
> Once again you err. I am not interested in controlling people's
> viewpoints. I had some things to say about Lisp versus Java.
> Subsequently, I have endeavored to correct the public record regarding
> my own person, after several people set about to doctor that record. At
> first I believe they did so inadvertently, by arguing about Lisp in ways
> that unfortunately insinuated things about me that were inaccurate.
> However, it is now apparent that at least some of you are doing it
> deliberately, though you formerly were either silent or doing it
> accidentally.
>
> Shame on you.
>
> Regardless, you are all entitled to your personal opinions and
> viewpoints and I would not dream of trying to change those by force.
> However, what you publish in writing about me is another matter entirely
> and I am entitled by law to some influence over that.
>
> >> If people continue to flood the newsgroup with more incorrect postings,
> >> then it makes it difficult to get caught up and be able to say "there,
> >> I'm done" and move on to another task.
>
> > Not at all.
>
> Yes, it does. Why are you accusing me of lying, when I have no motive to
> do so and especially when the evidence clearly supports what I said?
I've never accused you of lying. You seem to have an obsession about
the issue of lying. You been telling me I've accused you of lying,
and I never have. It seems if we have a difference of opinion, you
think I'm accusing you of lying.
> > for someone who is in control, it is easy to walk away
> > and say "there, I'm done". You know how to do that? Just walk away
> > and say "there, I'm done.".
>
> In other words, you suggest that I should lie about whether I've
> actually caught up on usenet, by claiming to have done so when I have
> not? How illogical.
I'm not suggesting you lie to yourself. I'm not suggesting you think
of yourself of being caught up on usenet when you're not. I'm
suggesting that one way of being done with usenet is to _not_ catch
up, but to simply be done with it. Of course it's illogical to you,
because you have a compulsion to "catch up", and you can't help
yourself.
> >>> If you truly want control, then take control, including control over
> >>> the urge you have to answer every argument
> >> Not every argument. Every argument that says or insinuates something
> >> unpleasant about me, either by vigorously disagreeing with something I
> >> said or by containing overt personal attacks, perhaps. But nobody sane
> >> would want something like that aimed at them being on the public record,
> >> but as yet unchallenged, now would they?
>
> > Of course they would
>
> No, they would not. None would ordinarily prefer that the public record
> contain an erroneous negative statement about them than that the public
> record contained no such statements.
Ah, but because the public record already has the sheer volume of your
posts in it, it already shows the unpleasantness that you have created
for yourself, just for the volume of it. Your reputation has been
damaged irreparably by yourself and no other. There's nothing you can
do to fix that now.
> The rest of your insulting and vaguely threatening post has been deleted
> unread. Have a nice day.
"Vaguely threatening?" Well, I would wish you a nice day, but it
seems you're not have a very nice day, with all of the threats and
accusations leveled against you, and with all of the catching up you
must do.
Have a nice day anyway.
Duane
·····@franz.com wrote:
> On May 22, 10:52 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> ·····@franz.com wrote:
>>> On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> ·····@franz.com wrote:
>>>>> On May 22, 9:50 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> Alessio Stalla wrote:
>>>>>> [snip]
>>>>>> Please stop posting five minutes after I post, in the interests of
>>>>>> letting me get caught up so I can move on to other tasks. I do have
>>>>>> other things to do than defend myself against you and your pals, you
>>>>>> know, and it is disrespectful to keep me jumping like this without any
>>>>>> time to even catch a breather. Furthermore, please try to limit your
>>>>>> posts to a reasonable length. This one isn't as ludicrously long as some
>>>>>> of your recent posts have been, but it isn't exactly short either.
>>>>> I just answered another of your posts, and this precisely demonstrates
>>>>> my point there; you are not in control in this conversation
>>>> I'm not sure I care for your threatening tone.
>>> No threat.
>> You implied a threat to disrespect my wishes and continue to publicly
>> badmouth me, right there in that quoted text.
>
> You who are so concerned about losing respect have already done so
I cannot have lost your respect, for clearly I never had it to begin with.
> There was no threat. The disaster you created for your reputation was
> intricately woven by you in this whole thread.
These are lies.
>>>> If I set out to catch up on Usenet, then once I have begun I must reply
>>>> to any posts that say incorrect things, especially if they say incorrect
>>>> things about me, personally, in public where other people might read
>>>> them and be misled.
>>> Then let them be misled.
>> That would be unwise.
>
> Have it your way.
If that is your wish, why are you endeavoring to prevent that exact outcome?
>>> Right now, they get the wrong idea about you, because they laugh at you
>> So you claim. I think you would not be making that claim unless it
>> served your purpose. Since your purpose seems to be to have the last
>> word and to do so at my expense, and since that would have undesirable
>> consequences for me, it follows that you are probably attempting to
>> deceive me into pursing a poor strategy that will enable you to have
>> that all-important last word.
>>
>> Therefore I should ignore what you are suggesting.
>
> You have not been able to do so yet.
I have indeed. Since you have suggested that I shut up, and I have
clearly not shut up, then I have indeed not followed your suggestion.
>>>> If people continue to flood the newsgroup with more incorrect postings,
>>>> then it makes it difficult to get caught up and be able to say "there,
>>>> I'm done" and move on to another task.
>>> Not at all.
>> Yes, it does. Why are you accusing me of lying, when I have no motive to
>> do so and especially when the evidence clearly supports what I said?
>
> I've never accused you of lying.
You just did. If I say a statement and you reply with "not at all" you
are implying that I told a falsehood. This should be apparent to anyone
with even the must rudimentary grasp of logic.
> You been telling me I've accused you of lying, and I never have.
You have indeed.
> It seems if we have a difference of opinion, you think I'm accusing
> you of lying.
A difference of opinion? You have explicitly contradicted factual
statements from me, including statements about my own beliefs that I
should know much more about than you do. That is, essentially, calling
me a liar.
>>> for someone who is in control, it is easy to walk away
>>> and say "there, I'm done". You know how to do that? Just walk away
>>> and say "there, I'm done.".
>> In other words, you suggest that I should lie about whether I've
>> actually caught up on usenet, by claiming to have done so when I have
>> not? How illogical.
>
> I'm not suggesting you lie
Yes, you are.
I had originally written:
> If people continue to flood the newsgroup with more incorrect
> postings, then it makes it difficult to get caught up and be able to
> say "there, I'm done" and move on to another task.
You suggested that I say "there, I'm done" prematurely. Since I would
know whether I had actually caught up or not, I would then be saying one
thing while knowing a contradictory thing. It follows that you suggested
that I lie.
> I'm suggesting that one way of being done with usenet is to _not_
> catch up
You are now. You were not before. And no, I shall not stop catching up
simply because you want me to. In fact, given your behavior and apparent
hostility, that you apparently want me to is an excellent reason for me
to keep catching up.
>>>>> If you truly want control, then take control, including control over
>>>>> the urge you have to answer every argument
>>>> Not every argument. Every argument that says or insinuates something
>>>> unpleasant about me, either by vigorously disagreeing with something I
>>>> said or by containing overt personal attacks, perhaps. But nobody sane
>>>> would want something like that aimed at them being on the public record,
>>>> but as yet unchallenged, now would they?
>>> Of course they would
>> No, they would not. None would ordinarily prefer that the public record
>> contain an erroneous negative statement about them than that the public
>> record contained no such statements.
>
> Ah, but because the public record already has the sheer volume of your
> posts in it
My posts are not at issue here. The posts discussed immediately above
are those, like yours, that make incorrect negative statements about me.
> Your reputation has been damaged irreparably by yourself and no other.
> There's nothing you can do to fix that now.
I do not take kindly to people that threaten me. I strongly recommend
that you desist from doing so.
>> The rest of your insulting and vaguely threatening post has been deleted
>> unread. Have a nice day.
>
> "Vaguely threatening?" Well, I would wish you a nice day, but it
> seems you're not have a very nice day, with all of the threats and
> accusations leveled against you, and with all of the catching up you
> must do.
And you are partially responsible.
·····@franz.com wrote:
> Then let them be misled. Right now, they get the wrong idea about
> you, because they laugh at your inability to back down from an
> argument. Only after you've mastered the art of walking away can you
> master the art of controlling people's viewpoints.
Reminds me of a chat I had with one of the more intellectual bouncers
down at my sports bar. He said that whenever two guys start to get into
it he points out to them that they are about to turn off every girl in
the bar.
I forgot to ask if it works.
nsth, kt
Kenneth Tilton wrote:
> ·····@franz.com wrote:
>> Then let them be misled. Right now, they get the wrong idea about
>> you, because they laugh at your inability to back down from an
>> argument. Only after you've mastered the art of walking away can you
>> master the art of controlling people's viewpoints.
>
> Reminds me of a chat I had with one of the more intellectual bouncers
> down at my sports bar. He said that whenever two guys start to get into
> it he points out to them that they are about to turn off every girl in
> the bar.
>
> I forgot to ask if it works.
None of this is relevant here. What Duane has said about me is a pack of
lies; nobody here is analogous to a bouncer, since this is an
unmoderated group; in comp.* newsgroups, "every girl in the bar" means
all two of them; and last but certainly not least, not one word of any
of the quoted text has anything whatsoever to do with either Java OR Lisp.
In fact about the only commonalities between bars and these newsgroups
are the amount of boorishness and fight-picking that goes on and the
amount of public drunkenness that goes on (the latter inferred from many
incoherent, rambling, or just-plain-irrational posts that I've seen from
various people here none of whom were me).
On May 23, 3:25 am, Kenneth Tilton <·········@gmail.com> wrote:
> ·····@franz.com wrote:
> > Then let them be misled. Right now, they get the wrong idea about
> > you, because they laugh at your inability to back down from an
> > argument. Only after you've mastered the art of walking away can you
> > master the art of controlling people's viewpoints.
>
> Reminds me of a chat I had with one of the more intellectual bouncers
> down at my sports bar. He said that whenever two guys start to get into
> it he points out to them that they are about to turn off every girl in
> the bar.
>
> I forgot to ask if it works.
Likely not. The fight instinct and the need to dominate, fueled by
testosterone, will far outweigh the instinct to be liked or loved.
Duane
·····@franz.com wrote:
> On May 23, 3:25 am, Kenneth Tilton <·········@gmail.com> wrote:
>> ·····@franz.com wrote:
>>> Then let them be misled. Right now, they get the wrong idea about
>>> you, because they laugh at your inability to back down from an
>>> argument. Only after you've mastered the art of walking away can you
>>> master the art of controlling people's viewpoints.
>> Reminds me of a chat I had with one of the more intellectual bouncers
>> down at my sports bar. He said that whenever two guys start to get into
>> it he points out to them that they are about to turn off every girl in
>> the bar.
>>
>> I forgot to ask if it works.
>
> Likely not. The fight instinct and the need to dominate, fueled by
> testosterone, will far outweigh the instinct to be liked or loved.
That observation may explain the behavior of certain of my opponents --
particularly those, like "Lew", Arne, and Lars, whose posts consist
almost entirely of insults, childish posturing, and demands, with nary a
Java- or Lisp-relevant statement to be found within.
Of course, I am above such instincts; my actions are dictated, when they
are dictated at all, by logic and necessity. This is why your emotional
arguments against Java and in favor of Lisp carry no weight with me, and
why your personal attacks are ineffective in convincing me either to go
along with you or to go away. You would have greater chances of
diverting the course of the Mississippi by throwing a small stone into
it, or by standing upon its shore and having a temper tantrum.
På Sat, 23 May 2009 05:12:37 +0200, skrev Seamus MacRae
<··········@live.ca.nospam>:
>> If you truly want control, then take control, including control over
>> the urge you have to answer every argument
>
> Not every argument. Every argument that says or insinuates something
> unpleasant about me, either by vigorously disagreeing with something I
> said or by containing overt personal attacks, perhaps. But nobody sane
> would want something like that aimed at them being on the public record,
> but as yet unchallenged, now would they?
Ironically all you had to do to prove him wrong was not to answer..
---------------------
John Thingstad
John Thingstad wrote:
> På Sat, 23 May 2009 05:12:37 +0200, skrev Seamus MacRae
> <··········@live.ca.nospam>:
>
>>> If you truly want control, then take control, including control over
>>> the urge you have to answer every argument
>>
>> Not every argument. Every argument that says or insinuates something
>> unpleasant about me, either by vigorously disagreeing with something I
>> said or by containing overt personal attacks, perhaps. But nobody sane
>> would want something like that aimed at them being on the public
>> record, but as yet unchallenged, now would they?
>
> Ironically all you had to do to prove him wrong was not to answer..
That would only by ironic if by object here was to prove him wrong. My
object here is to correct erroneous statements made about me, and to
point out the flaws in the reasoning of the Lisp proponents, of which
there are numerous. Flaws, that is. In fact if Lisp truly is superior my
doing so should be viewed positively by them, as it would identify the
places where their arguments could be shored up and errors corrected.
However, that shows that were Lisp truly superior to Java, the logical
result of my pointing out flaws in their arguments would be that their
arguments would get stronger over time. The observed fact, however, is
that their arguments have become weaker over time; for instance, where
once mainly technical claims for Lisp features making it exceptionally
useful were made, now invalid ad hominem arguments, petty namecalling,
and even empty threats have largely replaced them. This devolution I
take to be evidence that Lisp, while not necessarily inferior, is not
superior.
On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Please stop posting five minutes after I post, in the interests of
please stop posting.
TomSW wrote:
> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>
>> Please stop posting five minutes after I post, in the interests of
>
> please stop posting.
You first.
On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> TomSW wrote:
> > On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> >> Please stop posting five minutes after I post, in the interests of
>
> > please stop posting.
>
> You first.
Here's another example of you being not in control. It is the oldest
child's game in the world. As children grow up, they learn to control
themselves, and not to play "who can outlast the other" as a means of
discourse.
I suspect that you will respond to this, and I will likely just give
up trying to teach you something. But you will continue to be
embroiled in your own headlock with many others who want to still play
this game with you, and at that point I will feel a little more sorry
for you.
Duane
·····@franz.com wrote:
> On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> TomSW wrote:
>>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Please stop posting five minutes after I post, in the interests of
>>> please stop posting.
>> You first.
>
> Here's another example of
Did I ask you for another example of anything? No? Then please don't
clutter up both newsgroups with irrelevancies. TomSW and I were
discussing something. Your interjection is neither useful nor warranted.
> As children grow up, they learn to control themselves, and not to play
> "who can outlast the other" as a means of discourse.
From this I conclude that either you are lying or you have not grown up
yet.
> I suspect that you will respond to this, and I will likely just give
> up trying to teach you something.
You assume, incorrectly, that I am trying to learn something. Perhaps
earlier I was, but at the moment my goal is purely to set the record
straight and then get on with other, more pleasant tasks.
> But you will continue to be embroiled in your own headlock with many
> others who want to still play this game with you, and at that point
> I will feel a little more sorry for you.
I did not ask for, nor do I need, your pity. Such things are also
inappropriate subject matter for discussing openly in a public place
according to the rules of polite society.
On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> You assume, incorrectly, that I am trying to learn something. Perhaps
> earlier I was, but at the moment my goal is purely to set the record
> straight
There's not much chance of that.
You put me in mind of this passage, which thanks to you I was prompted
to hunt down in full:
"A physician once remarked to me as a proof
of the exciting nature of anger, that a man when excessively jaded
will sometimes invent imaginary offences and put himself into a
passion,
unconsciously for the sake of reinvigorating himself; and since
hearing
this remark, I have occasionally recognized its full truth."
TomSW wrote:
> On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
>> You assume, incorrectly, that I am trying to learn something. Perhaps
>> earlier I was, but at the moment my goal is purely to set the record
>> straight
>
> There's not much chance of that.
Another threat. I suggest you find a more productive endeavor.
> You put me in mind of this passage, which thanks to you I was prompted
> to hunt down in full:
>
> "A physician once remarked to me as a proof
> of the exciting nature of anger, that a man when excessively jaded
> will sometimes invent imaginary offences and put himself into a
> passion,
> unconsciously for the sake of reinvigorating himself; and since
> hearing
> this remark, I have occasionally recognized its full truth."
This is inapplicable. I am not angry; I am calm and collected.
Occasionally I have been disappointed in the way someone else has
behaved that I hoped would know better. And that's about it. My posts
reflect this: logical, precise, calm, largely lacking in expletives and
personal attacks, and rational even in the face of strong provocation.
On May 23, 12:48 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > There's not much chance of that.
>
> Another threat. I suggest you find a more productive endeavor.
It wasn't meant to be a threat. I just don't think you're even going
to set the record straight.
> > "A physician once remarked to me as a proof
> > of the exciting nature of anger, that a man when excessively jaded
> > will sometimes invent imaginary offences and put himself into a
> > passion,
> > unconsciously for the sake of reinvigorating himself; and since
> > hearing
> > this remark, I have occasionally recognized its full truth."
>
> This is inapplicable. I am not angry; I am calm and collected.
You're always so categorical and right, aren't you? I never said you
were angry, but you do seem to be locked into a cycle of finding
offence and then (to your mind) prevailing against it logically,
precisely, calmly and whatnot. It hardly matters what your
interlocutors say or whether they exist: this discussion could have
happened entirely in your head, the unfortunate thing for you is that
it's happening on a public archived newsgroup. You're making a
glorious fool of yourself - that's why I told you to stop - and you
have the nerve to suggest to other people that they find "more
productive endeavour"s?
But thank you, I will.
TomSW
TomSW wrote:
> On May 23, 12:48 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>
>>> There's not much chance of that.
>> Another threat. I suggest you find a more productive endeavor.
>
> It wasn't meant to be a threat.
So, not only did you threaten me, you were also incompetent at whatever
you intended to do instead? That is hardly an improvement in my estimation.
>>> "A physician once remarked to me as a proof
>>> of the exciting nature of anger, that a man when excessively jaded
>>> will sometimes invent imaginary offences and put himself into a
>>> passion,
>>> unconsciously for the sake of reinvigorating himself; and since
>>> hearing
>>> this remark, I have occasionally recognized its full truth."
>> This is inapplicable. I am not angry; I am calm and collected.
>
> You're always so categorical and right, aren't you?
That is the effect of using logic instead of emotion as one's basis for
forming conclusions.
> I never said you were angry
I never said you did. I merely pointed out that, since I was not, the
remarks you made concerning anger were inapplicable.
The remainder of your post was incoherent and laced with several ad
hominems, and it clearly fails to make any kind of a case for preferring
Lisp to Java. I have therefore not bothered to respond to it in any
specific detail.
On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> ·····@franz.com wrote:
> > On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> TomSW wrote:
> >>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Please stop posting five minutes after I post, in the interests of
> >>> please stop posting.
> >> You first.
>
> > Here's another example of
>
> Did I ask you for another example of anything? No? Then please don't
> clutter up both newsgroups with irrelevancies. TomSW and I were
> discussing something. Your interjection is neither useful nor warranted.
The largest problem with this newsgroup is that elders can't spank the
youngsters when they misbehave so we're stuck with eternal september.
bobi
On May 23, 4:06 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> > ·····@franz.com wrote:
> > > On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > >> TomSW wrote:
> > >>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > >>>> Please stop posting five minutes after I post, in the interests of
> > >>> please stop posting.
> > >> You first.
>
> > > Here's another example of
>
> > Did I ask you for another example of anything? No? Then please don't
> > clutter up both newsgroups with irrelevancies. TomSW and I were
> > discussing something. Your interjection is neither useful nor warranted.
>
> The largest problem with this newsgroup is that elders can't spank the
> youngsters when they misbehave so we're stuck with eternal september.
Not to worry; the elders will end up walking away :-)
Duane
On May 23, 4:31 pm, ·····@franz.com wrote:
> On May 23, 4:06 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
> > On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> > > ·····@franz.com wrote:
> > > > On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > > >> TomSW wrote:
> > > >>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > > >>>> Please stop posting five minutes after I post, in the interests of
> > > >>> please stop posting.
> > > >> You first.
>
> > > > Here's another example of
>
> > > Did I ask you for another example of anything? No? Then please don't
> > > clutter up both newsgroups with irrelevancies. TomSW and I were
> > > discussing something. Your interjection is neither useful nor warranted.
>
> > The largest problem with this newsgroup is that elders can't spank the
> > youngsters when they misbehave so we're stuck with eternal september.
>
> Not to worry; the elders will end up walking away :-)
Elder flight, that's what I'm afraid of.
Bobi
On May 24, 2:34 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
> On May 23, 4:31 pm, ·····@franz.com wrote:
>
> > On May 23, 4:06 am, Slobodan Blazeski <·················@gmail.com>
> > wrote:
>
> > > On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> > > > ·····@franz.com wrote:
> > > > > On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > > > >> TomSW wrote:
> > > > >>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > > > >>>> Please stop posting five minutes after I post, in the interests of
> > > > >>> please stop posting.
> > > > >> You first.
>
> > > > > Here's another example of
>
> > > > Did I ask you for another example of anything? No? Then please don't
> > > > clutter up both newsgroups with irrelevancies. TomSW and I were
> > > > discussing something. Your interjection is neither useful nor warranted.
>
> > > The largest problem with this newsgroup is that elders can't spank the
> > > youngsters when they misbehave so we're stuck with eternal september.
>
> > Not to worry; the elders will end up walking away :-)
>
> Elder flight, that's what I'm afraid of.
And yet more!
Slobodan Blazeski wrote:
> On May 23, 4:31 pm, ·····@franz.com wrote:
>> On May 23, 4:06 am, Slobodan Blazeski <·················@gmail.com>
>> wrote:
>>> On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> ·····@franz.com wrote:
>>>>> On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> TomSW wrote:
>>>>>>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>>>> Please stop posting five minutes after I post, in the interests of
>>>>>>> please stop posting.
>>>>>> You first.
>>>>> Here's another example of
>>>> Did I ask you for another example of anything? No? Then please don't
>>>> clutter up both newsgroups with irrelevancies. TomSW and I were
>>>> discussing something. Your interjection is neither useful nor warranted.
>>> The largest problem with this newsgroup is that elders can't spank the
>>> youngsters when they misbehave
Indeed. Were I able, I'd have spanked you all silly by now.
Now behave!
>> Not to worry; the elders will end up walking away :-)
> Elder flight, that's what I'm afraid of.
Well, fear no more for I'm back.
On May 23, 10:31 am, ·····@franz.com wrote:
> On May 23, 4:06 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
> > On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> > > ·····@franz.com wrote:
> > > > On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > > >> TomSW wrote:
> > > >>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > > >>>> Please stop posting five minutes after I post, in the interests of
> > > >>> please stop posting.
> > > >> You first.
>
> > > > Here's another example of
>
> > > Did I ask you for another example of anything? No? Then please don't
> > > clutter up both newsgroups with irrelevancies. TomSW and I were
> > > discussing something. Your interjection is neither useful nor warranted.
>
> > The largest problem with this newsgroup is that elders can't spank the
> > youngsters when they misbehave so we're stuck with eternal september.
>
> Not to worry; the elders will end up walking away :-)
And more!
·····@franz.com wrote:
> On May 23, 4:06 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>> On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>
>>> ·····@franz.com wrote:
>>>> On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> TomSW wrote:
>>>>>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>>> Please stop posting five minutes after I post, in the interests of
>>>>>> please stop posting.
>>>>> You first.
>>>> Here's another example of
>>> Did I ask you for another example of anything? No? Then please don't
>>> clutter up both newsgroups with irrelevancies. TomSW and I were
>>> discussing something. Your interjection is neither useful nor warranted.
>> The largest problem with this newsgroup is that elders can't spank the
>> youngsters when they misbehave
Indeed. Were I able, I'd have spanked you all silly by now.
Now behave!
> Not to worry; the elders will end up walking away :-)
But I came back. :)
On May 23, 7:06 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> > ·····@franz.com wrote:
> > > On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > >> TomSW wrote:
> > >>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > >>>> Please stop posting five minutes after I post, in the interests of
> > >>> please stop posting.
> > >> You first.
>
> > > Here's another example of
>
> > Did I ask you for another example of anything? No? Then please don't
> > clutter up both newsgroups with irrelevancies. TomSW and I were
> > discussing something. Your interjection is neither useful nor warranted.
>
> The largest problem with this newsgroup is that elders can't spank the
> youngsters when they misbehave so we're stuck with eternal september.
Another badmouthing of Seamus behind his back!
Slobodan Blazeski wrote:
> On May 23, 7:55 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> ·····@franz.com wrote:
>>> On May 22, 8:12 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> TomSW wrote:
>>>>> On May 22, 6:50 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> Please stop posting five minutes after I post, in the interests of
>>>>> please stop posting.
>>>> You first.
>>> Here's another example of
>> Did I ask you for another example of anything? No? Then please don't
>> clutter up both newsgroups with irrelevancies. TomSW and I were
>> discussing something. Your interjection is neither useful nor warranted.
>
> The largest problem with this newsgroup is that elders can't spank the
> youngsters when they misbehave
Indeed. Were I able, I'd have spanked you all silly by now.
Now behave!
Seamus MacRae wrote:
> Please stop posting five minutes after I post, in the interests of
> letting me get caught up so I can move on to other tasks. I do have
> other things to do than defend myself against you and your pals, you
> know, and it is disrespectful to keep me jumping like this without any
> time to even catch a breather. Furthermore, please try to limit your
> posts to a reasonable length.
This is usenet. You can not tell other what to do or not to do.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Please stop posting five minutes after I post, in the interests of
>> letting me get caught up so I can move on to other tasks. I do have
>> other things to do than defend myself against you and your pals, you
>> know, and it is disrespectful to keep me jumping like this without any
>> time to even catch a breather. Furthermore, please try to limit your
>> posts to a reasonable length.
>
> This is usenet. You can not tell other what to do or not to do.
I know that. That's why I asked, politely, rather than telling.
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>> Thomas A. Russ wrote:
>>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>
>>>>> Every time a serious problem is mentioned, you tend to dismiss it with
>>>>> little more than a hand-wave. A can-do attitude is good to have, but
>>>>> here it's verging on Pollyanna. You're liable to trip and pitch
>>>>> headfirst down a six-hundred-foot chasm while staring up at the pretty
>>>>> blue sky if you carry on like that.
>>>> Well, if you were to actually LEARN something about Common Lisp first
>>> There's no call for this rudeness.
>>>
>>>> perhaps you wouldn't raise so-called "problems" that don't really
>>>> exist.
>>> But they do exist.
>>
>> Only in your head.
>
> Personal attacks such as this will not help you to rationally address
> the issues that I have raised.
I, for one, would gladly address some those issues, but I can't do that without
a reference manual.
Is there a website where I can download, or read online, the specification of
Seamus MacRae Lisp?
I'm not comfortable spouting off about languages I don't know anything about.
Kaz Kylheku wrote:
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>
>>>> Thomas A. Russ wrote:
>>>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>>
>>>>>> Every time a serious problem is mentioned, you tend to dismiss it with
>>>>>> little more than a hand-wave. A can-do attitude is good to have, but
>>>>>> here it's verging on Pollyanna. You're liable to trip and pitch
>>>>>> headfirst down a six-hundred-foot chasm while staring up at the pretty
>>>>>> blue sky if you carry on like that.
>>>>> Well, if you were to actually LEARN something about Common Lisp first
>>>> There's no call for this rudeness.
>>>>
>>>>> perhaps you wouldn't raise so-called "problems" that don't really
>>>>> exist.
>>>> But they do exist.
>>> Only in your head.
>> Personal attacks such as this will not help you to rationally address
>> the issues that I have raised.
>
> I, for one, would gladly address some those issues, but I can't do that without
> a reference manual.
>
> Is there a website where I can download, or read online, the specification of
> Seamus MacRae Lisp?
Never heard of it, sorry. I thought we were discussing Common Lisp anyway.
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Kaz Kylheku wrote:
>> Is there a website where I can download, or read online, the specification of
>> Seamus MacRae Lisp?
>
> Never heard of it, sorry. I thought we were discussing Common Lisp anyway.
You don't appear to know anything about Common Lisp, so that can't possibly be
the case.
How much code have you written in Common Lisp? What reference materials have
you studied? How familiar are you with the HTML-ized ANSI standard of
Common Lisp known as the CLHS (Common Lisp Hyper-Spec?).
How confident are you you could pass a closed-book newbie-level
exam in Common Lisp?
People are to interpret what you are saying as being about Common Lisp, you
look like a complete twit who posts whatever made-up nonsense that pops
into his head, presenting it as a fact.
So you may want to retract your claim that you are discussing Common Lisp.
Kaz Kylheku wrote:
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Kaz Kylheku wrote:
>>> Is there a website where I can download, or read online, the specification of
>>> Seamus MacRae Lisp?
>> Never heard of it, sorry. I thought we were discussing Common Lisp anyway.
>
> You don't appear to know anything about Common Lisp
A lie.
> so that can't possibly be the case.
Assumes a premise that proved to be false. Unsurprising then that the
conclusion also comes out false.
> People are to interpret what you are saying as being about Common Lisp
Yes.
> you look like a complete twit
Insults will not convince me that Lisp is better than Java. Only
evidence will, if you can find some and present it here. I am coming to
suspect ever more strongly that you cannot.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Insults will not convince me that Lisp is better than Java. Only
>
> I'm quite sure nobody /wants/ to convince you that Lisp is better than
> Java. That would be the last thing we'd want! Then you'd be in the
> Lisp groups all the time.
More personal attacks, and not even any worthwhile attempts at rational
argumentation in the post. It might as well not have been posted. Why
are so few people reasonable or rational?
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Insults will not convince me that Lisp is better than Java. Only
>
> I'm quite sure nobody /wants/ to convince you that Lisp is better than
> Java. That would be the last thing we'd want! Then you'd be in the
> Lisp groups all the time.
:-)
Arne
Arne Vajh�j wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>> Insults will not convince me that Lisp is better than Java. Only
>>
>> I'm quite sure nobody /wants/ to convince you that Lisp is better than
>> Java. That would be the last thing we'd want! Then you'd be in the
>> Lisp groups all the time.
>
> :-)
I find nothing amusing about Paul's insulting and rude insinuations.
On May 15, 11:10 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > Not at all. The necessary modification of the generic function is
> > handled automatically (really, CLOS would be remarkably useless if it
> > weren't) when you define the new method.
>
> You mean, the source code for a dispatch table you posted is
> machine-generated, like yacc output? No wonder it looks like ... well,
> what a lay person will probably imagine "yacc output" describes. ;)
Oh, shit. I think you guys may actually be dealing with someone with a
9th-dan black belt in usenet-fu here. Do you see how he subtly, but
quite definitely, retaliates for your earlier insulting comparison of
his Java code to vomit by doing the same to your Lisp code here?
No matter. I'm outta here before it all hits the fan.
On May 16, 1:48 am, Little Green Man <·······@gmail.com> wrote:
>
> Oh, shit. I think you guys may actually be dealing with someone with a
> 9th-dan black belt in usenet-fu here. Do you see how he subtly, but
> quite definitely, retaliates for your earlier insulting comparison of
> his Java code to vomit by doing the same to your Lisp code here?
>
> No matter. I'm outta here before it all hits the fan.
Seamus MacRae and Series Expansion are proving themselves to be
grandmasters of trolling. The Troll-o-Matic will have to be updated to
reflect their expert techniques.
And has anyone else noticed that they are never both present at the
same time? Just a thought.
Larry Coleman wrote:
> Seamus MacRae and Series Expansion are proving themselves to be
> grandmasters of trolling. The Troll-o-Matic will have to be updated to
> reflect their expert techniques.
>
> And has anyone else noticed that they are never both present at the
> same time? Just a thought.
Both are absent at the same time through the magic of killfiles.
--
Lew
Lew wrote:
> Larry Coleman wrote:
>> Seamus MacRae and Series Expansion are proving themselves to be
>> grandmasters of trolling. The Troll-o-Matic will have to be updated to
>> reflect their expert techniques.
>>
>> And has anyone else noticed that they are never both present at the
>> same time? Just a thought.
>
> Both are absent at the same time through the magic of killfiles.
That, definitely, is a personal attack.
Keep your opinions of other people to yourself. Didn't your mother teach
you any manners?
On May 18, 7:40 pm, Lew <·····@lewscanon.com> wrote:
> Larry Coleman wrote:
> > Seamus MacRae and Series Expansion are proving themselves to be
> > grandmasters of trolling. The Troll-o-Matic will have to be updated to
> > reflect their expert techniques.
>
> > And has anyone else noticed that they are never both present at the
> > same time? Just a thought.
>
> Both are absent at the same time through the magic of killfiles.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Larry.
Larry Coleman wrote:
> Seamus MacRae and Series Expansion are proving themselves to be
> grandmasters of trolling. The Troll-o-Matic will have to be updated to
> reflect their expert techniques.
>
> And has anyone else noticed that they are never both present at the
> same time? Just a thought.
Based on his IP address then Series Expansion is twisted alias
Paul Derbyshire.
You can do the googling.
Arne
On May 18, 9:18 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Larry Coleman wrote:
> > Seamus MacRae and Series Expansion are proving themselves to be
> > [numerous insults deleted]
>
> Based on his IP address then Series Expansion is twisted alias Paul Derbyshire.
As explained previously, I find it necessary to assume that all
insults aimed at "Paul Derbyshire" here are actually intended for me,
and respond in both of our defense. To set the record straight:
* I am not Paul.
* None of the nasty things that you have said or implied are
true of me.
* I don't know whether the insults are true of Paul, but I
very much doubt that he'd appreciate you insulting him behind
his back.
Jerry Gerrone wrote:
> On May 18, 9:18 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>> Larry Coleman wrote:
>>> Seamus MacRae and Series Expansion are proving themselves to be
>>> grandmasters of trolling. The Troll-o-Matic will have to be updated to
>>> reflect their expert techniques.
>>>
>>> And has anyone else noticed that they are never both present at the
>>> same time? Just a thought.
>> Based on his IP address then Series Expansion is twisted alias Paul Derbyshire.
>
> As explained previously, I find it necessary to assume that all
> insults aimed at "Paul Derbyshire" here are actually intended for me,
> and respond in both of our defense. To set the record straight:
>
> * I am not Paul.
> * None of the nasty things that you have said or implied are
> true of me.
> * I don't know whether the insults are true of Paul, but I
> very much doubt that he'd appreciate you insulting him behind
> his back.
So you consider yourself insulted ny being accused of being
Series Expansion.
I can understand that !
:-)
Arne
On May 20, 9:12 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Jerry Gerrone wrote:
> > On May 18, 9:18 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Larry Coleman wrote:
> >>> Seamus MacRae and Series Expansion are proving themselves to be
> >>> grandmasters of trolling. The Troll-o-Matic will have to be updated to
> >>> reflect their expert techniques.
>
> >>> And has anyone else noticed that they are never both present at the
> >>> same time? Just a thought.
> >> Based on his IP address then Series Expansion is twisted alias Paul Derbyshire.
I am neither.
> > As explained previously, I find it necessary to assume that all
> > insults aimed at "Paul Derbyshire" here are actually intended for me,
> > and respond in both of our defense. To set the record straight:
>
> > * I am not Paul.
> > * None of the nasty things that you have said or implied are
> > true of me.
> > * I don't know whether the insults are true of Paul, but I
> > very much doubt that he'd appreciate you insulting him behind
> > his back.
>
> So you consider yourself insulted ny being accused of being
> Series Expansion.
>
> I can understand that !
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne, Jerry, and Larry.
On May 18, 9:18 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Larry Coleman wrote:
> > Seamus MacRae and Series Expansion are proving themselves to be
> > grandmasters of trolling. The Troll-o-Matic will have to be updated to
> > reflect their expert techniques.
>
> > And has anyone else noticed that they are never both present at the
> > same time? Just a thought.
>
> Based on his IP address then Series Expansion is twisted alias
> Paul Derbyshire.
No, I am not. Furthermore, my identity is irrelevant to the questions
raised regarding Lisp macros, and the personal attacks posted by Larry
also fail to make any kind of a case for Lisp over Java.
Series Expansion wrote:
> On May 18, 9:18 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>> Larry Coleman wrote:
>>> Seamus MacRae and Series Expansion are proving themselves to be
>>> grandmasters of trolling. The Troll-o-Matic will have to be updated to
>>> reflect their expert techniques.
>>> And has anyone else noticed that they are never both present at the
>>> same time? Just a thought.
>> Based on his IP address then Series Expansion is twisted alias
>> Paul Derbyshire.
>
> No, I am not.
Well that is what the IP address indicates.
Arne
Arne Vajh�j wrote:
> Series Expansion wrote:
>> On May 18, 9:18 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>>> Larry Coleman wrote:
>>>> Seamus MacRae and Series Expansion are proving themselves to be
>>>> grandmasters of trolling. The Troll-o-Matic will have to be updated to
>>>> reflect their expert techniques.
>>>> And has anyone else noticed that they are never both present at the
>>>> same time? Just a thought.
>>> Based on his IP address then Series Expansion is twisted alias
>>> Paul Derbyshire.
>>
>> No, I am not.
>
> Well that is what the IP address indicates.
No, it is not. I just had a look, and Series Expansion is posting from
74.*. Assuming that Jerry Gerrone is the individual you are referring to
as "twisted", I examined several of his posts as well, and they appear
to come from 70.*. Different class-A net blocks. Interestingly, both are
currently owned by the same ISP, but the consistent difference between
the two posters' IP addresses argues that they are different users of
that ISP, perhaps located in different parts of the region where they do
business, or for other reasons, such as one has a residential account
and the other a business one.
On May 22, 10:28 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 18, 9:18 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Based on his IP address then Series Expansion is twisted alias
> > No, I am not.
>
> Well that is what the IP address indicates.
It indicates nothing more than, at most, that we happen to share the
same Internet service provider.
Larry Coleman wrote:
> On May 16, 1:48 am, Little Green Man <·······@gmail.com> wrote:
>
>> Oh, shit. I think you guys may actually be dealing with someone with a
>> 9th-dan black belt in usenet-fu here. Do you see how he subtly, but
>> quite definitely, retaliates for your earlier insulting comparison of
>> his Java code to vomit by doing the same to your Lisp code here?
>>
>> No matter. I'm outta here before it all hits the fan.
>
> Seamus MacRae and Series Expansion are proving themselves to be
> grandmasters of trolling. The Troll-o-Matic will have to be updated to
> reflect their expert techniques.
This looks suspiciously like a personal attack. It certainly seems to be
irrelevant to the debate at hand, as does its parent post.
> And has anyone else noticed that they are never both present at the
> same time? Just a thought.
Is that supposed to be some sort of insinuation? Most likely we just
live in different timezones or something. There are after all 24 of them
in the world, so the odds have to be pretty good.
On May 18, 3:09 pm, Larry Coleman <············@yahoo.com> wrote:
> On May 16, 1:48 am, Little Green Man <·······@gmail.com> wrote:
>
>
>
> > Oh, shit. I think you guys may actually be dealing with someone with a
> > 9th-dan black belt in usenet-fu here. Do you see how he subtly, but
> > quite definitely, retaliates for your earlier insulting comparison of
> > his Java code to vomit by doing the same to your Lisp code here?
>
> > No matter. I'm outta here before it all hits the fan.
>
> Seamus MacRae and Series Expansion are proving themselves to be
> grandmasters of trolling. The Troll-o-Matic will have to be updated to
> reflect their expert techniques.
>
> And has anyone else noticed that they are never both present at the
> same time? Just a thought.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Larry.
And I think Seamus and I are both online posting right now as a matter
of fact. One more thing you got wrong. This is what happens to those
that allow their emotions to overrule their reason.
Series Expansion wrote:
> On May 18, 3:09 pm, Larry Coleman <············@yahoo.com> wrote:
>> On May 16, 1:48 am, Little Green Man <·······@gmail.com> wrote:
>>
>>
>>
>>> Oh, shit. I think you guys may actually be dealing with someone with a
>>> 9th-dan black belt in usenet-fu here. Do you see how he subtly, but
>>> quite definitely, retaliates for your earlier insulting comparison of
>>> his Java code to vomit by doing the same to your Lisp code here?
>>> No matter. I'm outta here before it all hits the fan.
>> Seamus MacRae and Series Expansion are proving themselves to be
>> grandmasters of trolling. The Troll-o-Matic will have to be updated to
>> reflect their expert techniques.
>>
>> And has anyone else noticed that they are never both present at the
>> same time? Just a thought.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, Larry.
>
> And I think Seamus and I are both online posting right now as a matter
> of fact. One more thing you got wrong. This is what happens to those
> that allow their emotions to overrule their reason.
It's easy to run Thunderbird and Firefox in different windows more or
less simultaneously, so that doesn't invalidate the highly plausible
hypothesis that you and Seamus are one and the same person.
Lars Enderin wrote:
> It's easy to run Thunderbird and Firefox in different windows more or
> less simultaneously, so that doesn't invalidate the highly plausible
> hypothesis that you and Seamus are one and the same person.
He isn't.
Obviously it can't really be proved. Just as I can't prove beyond a
shadow of a doubt that you and Kaz Kylheku aren't the same person,
though I have multiple reasons to suspect you are not.
It is fruitless to speculate about these things, and furthermore, it has
nothing whatsoever to do with which is better, Java or Lisp. Or Lisp
macros. Or Java type-checking. Or any of that stuff.
I suggest you forget about irrelevancies that not only have no bearing
on the topic at hand but regarding which there is no way for you to make
headway of any sort in answering the questions you seem to have. Give it
up as forever unknown, or assume the common case, i.e. assume two
seemingly-distinct people ARE different unless *proven* otherwise.
On May 21, 1:43 pm, Lars Enderin <············@telia.com> wrote:
> Series Expansion wrote:
> > On May 18, 3:09 pm, Larry Coleman <············@yahoo.com> wrote:
> >> On May 16, 1:48 am, Little Green Man <·······@gmail.com> wrote:
>
> >>> Oh, shit. I think you guys may actually be dealing with someone with a
> >>> 9th-dan black belt in usenet-fu here. Do you see how he subtly, but
> >>> quite definitely, retaliates for your earlier insulting comparison of
> >>> his Java code to vomit by doing the same to your Lisp code here?
> >>> No matter. I'm outta here before it all hits the fan.
> >> Seamus MacRae and Series Expansion are proving themselves to be
> >> grandmasters of trolling. The Troll-o-Matic will have to be updated to
> >> reflect their expert techniques.
>
> >> And has anyone else noticed that they are never both present at the
> >> same time? Just a thought.
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, Larry.
>
> > And I think Seamus and I are both online posting right now as a matter
> > of fact. One more thing you got wrong. This is what happens to those
> > that allow their emotions to overrule their reason.
>
> It's easy to run Thunderbird and Firefox in different windows more or
> less simultaneously, so that doesn't invalidate the highly plausible
> hypothesis that you and Seamus are one and the same person.
That hypothesis is nonetheless:
a) Wrong.
b) Off-topic for both newsgroups.
c) Irrelevant in a debate about which is better, Lisp or Java.
d) Speculation about persons, made publicly, that at least one of
those
persons considers unwelcome.
e) Speculation about matters that would be none of your business
no matter what.
Any single one of those items is reason enough why it shouldn't have
been posted and why you shouldn't continue to discuss it.
Please return to the topic at hand, namely which is better, Lisp or
Java.
Seamus MacRae <··········@live.ca.nospam> writes:
> I hate machine-generated code.
And rigtly you should! Machine-generated code is what will put you jobless.
> I hatehateHATE having to *maintain*
> machine-generated code.
Well, be happy, you won't have to maintain machine-generated code, the
machine will do it itself.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> I hate machine-generated code.
>
> And rigtly you should! Machine-generated code is what will put you jobless.
>
>> I hatehateHATE having to *maintain*
>> machine-generated code.
>
> Well, be happy, you won't have to maintain machine-generated code, the
> machine will do it itself.
Why put it in the source code then?
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pascal J. Bourguignon wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>> I hate machine-generated code.
>>
>> And rigtly you should! Machine-generated code is what will put you jobless.
>>
>>> I hatehateHATE having to *maintain*
>>> machine-generated code.
>>
>> Well, be happy, you won't have to maintain machine-generated code, the
>> machine will do it itself.
>
> Why put it in the source code then?
Good question. One reason you might have to live with this would be that your
team, boss, or customer has imposed the requirement that Seamus MacRae
Imaginary Lisp will be used for the project, rather than ANSI Common Lisp.
Kaz Kylheku wrote:
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pascal J. Bourguignon wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> I hate machine-generated code.
>>> And rigtly you should! Machine-generated code is what will put you jobless.
>>>
>>>> I hatehateHATE having to *maintain*
>>>> machine-generated code.
>>> Well, be happy, you won't have to maintain machine-generated code, the
>>> machine will do it itself.
>> Why put it in the source code then?
>
> Good question. One reason you might have to live with this would be that your
> team, boss, or customer has imposed the requirement
Well let's ask the horse's mouth why. Anonymous C Lisper, you wrote the
code with the example dispatch table. Care to weigh in?
Seamus MacRae <··········@live.ca.nospam> writes:
> Well let's ask the horse's mouth why. Anonymous C Lisper, you wrote the
> code with the example dispatch table. Care to weigh in?
Um, that wasn't code "with the example dispatch table". That was just
code using syntactic sugar to add DEFMETHOD forms to a DEFGENERIC. You
know, something like the difference between doing the following two
variable initializations in a Java class definition
static int id = 0;
vs.
static int id;
static: {id = 0;}
in Java. You can save some typing if you want to put everything
together in one place. But if it makes more sense to separate things,
you can do that.
It's harder to come up with Java examples, because they are a bit rarer.
But in any case, before continuing to embarass yourself with
misrepresentations about that form, I suggest you study
http://www.lispworks.com/documentation/HyperSpec/Body/07_.htm
http://www.lispworks.com/documentation/HyperSpec/Body/m_defgen.htm
http://www.lispworks.com/documentation/HyperSpec/Body/m_defmet.htm
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Well let's ask the horse's mouth why. Anonymous C Lisper, you wrote the
>> code with the example dispatch table. Care to weigh in?
>
> [calls me a liar]
Didn't think so. Non-response noted.
> But in any case, before continuing to embarass yourself with
> misrepresentations [rest of insults deleted]
Nice try, by the way. You purposely omitted cljp from the newsgroups
list hoping I'd never see this and rebut it. But your dishonest attempt
to fly one under the radar has failed miserably. Have a nice day.
Seamus MacRae <··········@live.ca.nospam> writes:
>> You need to be able to do this to add methods
>> for user-defined classes to built-in generic functions (like PRINT-
>> OBJECT or INITIALIZE-INSTANCE).
>
> Such a pain, when Java lets you just go
>
> public class MyWhatsit {
> @Override
> public String toString () {
> return "I'm a MyWhatsit!";
> }
> }
>
> sticking this in your own namespace and not monkeying with any other
> code anywhere (either manually, or by running some sort of
> code-generator), yet if a MyWhatsit is subsequently passed to
> e.g. String.valueOf(Object), out pops "I'm a MyWhatsit!".
>
> It ain't real polymorphism until you can do that, *without* scribbling
> outside the lines around the box your code is in.
>
>>> With Java I'd just have to define the implementations, naming them
>>> correctly, and stick "implements Number" somewhere and away I'd go.
>> In Common Lisp, you'd just write the four method definitions; you
>> wouldn't even have to mention the "implements Number" part.
>
> Duck-typing? Well, it beats no typing at all I suppose.
>
> Eh, wait a minute, you'd write the four method definitions and then
> run that code-generator thingy to generate the new versions of the
> dispatch tables.
>
> Er, how does that code-generator resolve conflicts again? If someone
> else makes a class, also calls it Complex, implements it differently
> (r-theta instead of x-y say), and writes methods with the same four
> names? Does it use the package the Complex class is in to keep the two
> versions of each separate?
You're ridiculous! Go learn some lisp before puting yourself to such a shame.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>>> You need to be able to do this to add methods
>>> for user-defined classes to built-in generic functions (like PRINT-
>>> OBJECT or INITIALIZE-INSTANCE).
>> Such a pain, when Java lets you just go
>>
>> public class MyWhatsit {
>> @Override
>> public String toString () {
>> return "I'm a MyWhatsit!";
>> }
>> }
>>
>> sticking this in your own namespace and not monkeying with any other
>> code anywhere (either manually, or by running some sort of
>> code-generator), yet if a MyWhatsit is subsequently passed to
>> e.g. String.valueOf(Object), out pops "I'm a MyWhatsit!".
>>
>> It ain't real polymorphism until you can do that, *without* scribbling
>> outside the lines around the box your code is in.
>>
>>>> With Java I'd just have to define the implementations, naming them
>>>> correctly, and stick "implements Number" somewhere and away I'd go.
>>> In Common Lisp, you'd just write the four method definitions; you
>>> wouldn't even have to mention the "implements Number" part.
>> Duck-typing? Well, it beats no typing at all I suppose.
>>
>> Eh, wait a minute, you'd write the four method definitions and then
>> run that code-generator thingy to generate the new versions of the
>> dispatch tables.
>>
>> Er, how does that code-generator resolve conflicts again? If someone
>> else makes a class, also calls it Complex, implements it differently
>> (r-theta instead of x-y say), and writes methods with the same four
>> names? Does it use the package the Complex class is in to keep the two
>> versions of each separate?
>
> You're ridiculous! Go learn some lisp before puting yourself to such a shame.
Your response to my post is an ad hominem argument that does not say
anything about either Lisp or Java.
Please hang up, and try your reasoning skills again.
Seamus MacRae <··········@live.ca.nospam> writes:
> Inheritance relationships recorded where? Lisp seems to take a
> Java-esque class and explode it, scattering bits of it all across the
> codebase and maybe hiding some bits up its sleeve for good measure.
OK. But Java takes all of the methods that do essentially the same
thing and hides them each in their own file. So instead of being able
to see the commonality in a particular set of methods all in one place,
you have to go searching through each class that implements the method.
At least in Common Lisp you have the choice of choosing a Java-esque
file organization or one that is more function-oriented. So you could
ahve all of the print-related methods grouped together, all of the
database-related methods grouped together, etc.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Inheritance relationships recorded where? Lisp seems to take a
>> Java-esque class and explode it, scattering bits of it all across the
>> codebase and maybe hiding some bits up its sleeve for good measure.
>
> OK. But Java takes all of the methods that do essentially the same
> thing and hides them each in their own file. So instead of being able
> to see the commonality in a particular set of methods all in one place,
> you have to go searching through each class that implements the method.
>
> At least in Common Lisp you have the choice of choosing a Java-esque
> file organization or one that is more function-oriented. So you could
> ahve all of the print-related methods grouped together, all of the
> database-related methods grouped together, etc.
OK. Lisp is better than Java. Victory for the Knights of Lisp!
--
Lew
Lew wrote:
> Thomas A. Russ wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>> Inheritance relationships recorded where? Lisp seems to take a
>>> Java-esque class and explode it, scattering bits of it all across the
>>> codebase and maybe hiding some bits up its sleeve for good measure.
>>
>> OK. But Java takes all of the methods that do essentially the same
>> thing and hides them each in their own file. So instead of being able
>> to see the commonality in a particular set of methods all in one place,
>> you have to go searching through each class that implements the method.
>>
>> At least in Common Lisp you have the choice of choosing a Java-esque
>> file organization or one that is more function-oriented. So you could
>> ahve all of the print-related methods grouped together, all of the
>> database-related methods grouped together, etc.
>
> OK. Lisp is better than Java. Victory for the Knights of Lisp!
Thomas has utterly failed to prove anything of the sort. See also my
direct followup to Thomas's post.
On May 18, 7:40 pm, Lew <·····@lewscanon.com> wrote:
> Thomas A. Russ wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
> >> Inheritance relationships recorded where? Lisp seems to take a
> >> Java-esque class and explode it, scattering bits of it all across the
> >> codebase and maybe hiding some bits up its sleeve for good measure.
>
> > OK. But Java takes all of the methods that do essentially the same
> > thing and hides them each in their own file. So instead of being able
> > to see the commonality in a particular set of methods all in one place,
> > you have to go searching through each class that implements the method.
>
> > At least in Common Lisp you have the choice of choosing a Java-esque
> > file organization or one that is more function-oriented. So you could
> > ahve all of the print-related methods grouped together, all of the
> > database-related methods grouped together, etc.
>
> OK. Lisp is better than Java. Victory for the Knights of Lisp!
The evidence gathered thus far does not warrant that conclusion.
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Inheritance relationships recorded where? Lisp seems to take a
>> Java-esque class and explode it, scattering bits of it all across the
>> codebase and maybe hiding some bits up its sleeve for good measure.
>
> OK. But Java takes all of the methods that do essentially the same
> thing and hides them each in their own file. So instead of being able
> to see the commonality in a particular set of methods all in one place,
> you have to go searching through each class that implements the method.
Maybe. But Lisp is no better if you have (defmethod frobnobdicate)
instances sprinkled all over the code base. Gathering them all in one
place means using the (defgeneric frobnobdicate) form, which puts them
all in one namespace too, as well as centralizing the place to create
more dispatches and implementations.
The only compromise I can see is using defmethod, but putting them all
in one place. And then there'll be a whole mess of explicit scoping
since that "one place" will belong to one package and you'll want to be
able to distribute the defmethods among several. All but one of those
will therefore involve explicit scoping.
> At least in Common Lisp you have the choice of choosing a Java-esque
> file organization or one that is more function-oriented. So you could
> ahve all of the print-related methods grouped together, all of the
> database-related methods grouped together, etc.
Instead of all of the methods that deal with the internals of foobars
together, and all of the methods that deal with the internals of
bazquuxs together.
There goes encapsulation. Here comes that distinctive zigzag pattern
that signifies an imminent migraine. Now where in the code are all the
references to that ivar? Hell if I know!
Seamus MacRae <··········@live.ca.nospam> writes:
> Thomas A. Russ wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
> >> Inheritance relationships recorded where? Lisp seems to take a
> >> Java-esque class and explode it, scattering bits of it all across the
> >> codebase and maybe hiding some bits up its sleeve for good measure.
> > OK. But Java takes all of the methods that do essentially the same
> > thing and hides them each in their own file. So instead of being able
> > to see the commonality in a particular set of methods all in one place,
> > you have to go searching through each class that implements the method.
>
> Maybe. But Lisp is no better if you have (defmethod frobnobdicate)
> instances sprinkled all over the code base. Gathering them all in one
> place means using the (defgeneric frobnobdicate) form, which puts them
> all in one namespace too, as well as centralizing the place to create
> more dispatches and implementations.
No. Gathering them all in one places just means putting the DEFMETHOD
forms sequentially in a single file.
> The only compromise I can see is using defmethod, but putting them all
> in one place. And then there'll be a whole mess of explicit scoping
> since that "one place" will belong to one package and you'll want to be
> able to distribute the defmethods among several. All but one of those
> will therefore involve explicit scoping.
You don't get scoping by putting things into a single file. Files don't
establish scoping.
Packages are managed separately from files and file contents. You can
have multiple files all in the same package and you can have a single
file with multiple packages in it.
It's dangerous to make assumptions about how lisp works if you haven't
first studied it.
> > At least in Common Lisp you have the choice of choosing a Java-esque
> > file organization or one that is more function-oriented. So you could
> > ahve all of the print-related methods grouped together, all of the
> > database-related methods grouped together, etc.
>
> Instead of all of the methods that deal with the internals of foobars
> together, and all of the methods that deal with the internals of
> bazquuxs together.
You have the choice. You get to pick the organization that makes the
most sense for the project at hand.
> There goes encapsulation. Here comes that distinctive zigzag pattern
> that signifies an imminent migraine. Now where in the code are all the
> references to that ivar? Hell if I know!
It's a different model of encapsulation. And nothing stops you from
adopting a Java-like organization, or even a mixed organization. You
can put several related classes together in a single file and then have
both the class definitions and the methods all together in one place.
It's your choice.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Thomas A. Russ wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> Inheritance relationships recorded where? Lisp seems to take a
>>>> Java-esque class and explode it, scattering bits of it all across the
>>>> codebase and maybe hiding some bits up its sleeve for good measure.
>>> OK. But Java takes all of the methods that do essentially the same
>>> thing and hides them each in their own file. So instead of being able
>>> to see the commonality in a particular set of methods all in one place,
>>> you have to go searching through each class that implements the method.
>> Maybe. But Lisp is no better if you have (defmethod frobnobdicate)
>> instances sprinkled all over the code base. Gathering them all in one
>> place means using the (defgeneric frobnobdicate) form, which puts them
>> all in one namespace too, as well as centralizing the place to create
>> more dispatches and implementations.
>
> [calls me a liar]
No, as has been clearly established *you* are the liar. In particular,
if you were actually interested in honest debate with me, you would not
have tried to hide your response from me!
>> The only compromise I can see is using defmethod, but putting them all
>> in one place. And then there'll be a whole mess of explicit scoping
>> since that "one place" will belong to one package and you'll want to be
>> able to distribute the defmethods among several. All but one of those
>> will therefore involve explicit scoping.
>
> You don't get scoping by putting things into a single file. Files don't
> establish scoping.
Illogical.
> It's dangerous to make assumptions [rest of condescension deleted]
It's dangerous to be rude to me.
>>> At least in Common Lisp you have the choice of choosing a Java-esque
>>> file organization or one that is more function-oriented. So you could
>>> ahve all of the print-related methods grouped together, all of the
>>> database-related methods grouped together, etc.
>> Instead of all of the methods that deal with the internals of foobars
>> together, and all of the methods that deal with the internals of
>> bazquuxs together.
>>
>> There goes encapsulation. Here comes that distinctive zigzag pattern
>> that signifies an imminent migraine. Now where in the code are all the
>> references to that ivar? Hell if I know!
>
> It's a different model of encapsulation. And nothing stops you from
> adopting a Java-like organization, or even a mixed organization.
Well, except that your coworkers' code may be organized very strangely
from your perspective, making teamwork nearly impossible.
You don't get any choice about how your coworkers organize code.
Seamus MacRae <··········@live.ca.nospam> writes:
> Paul Donnelly wrote:
>> Series Expansion <·······@gmail.com> writes:
>>
>>> On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
>>>
>>>> The CL package system will solve the name collision with no harm done.
>>> I just explained why the package system won't. Adding new classes in
>>> their own packages? No problem, the package system can distinguish
>>> foo.String from bar.String. Adding new methods to an existing class,
>>> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
>>> foo.String.doIt()?
>>
>> I guess that's one of the downsides of an inside-out object
>> system.
>
> Can I jump in here? You see, I have a theory.
>
> It goes something like this. Java and most OO languages are actually
> noun-oriented languages. They follow the natural way of thinking:
> subject does verb to object. 1 + 1 = 2. And so on.
I'll just jump in right here and point out that your assumption is
completely ridiculous. Why would it be less natural to put verbs first?
Your habits don't define human nature.
>>>> If anyone want to use the two of them together, and it has some
>>>> symbol clashes (probably just a few of them), this person can
>>>> explicitly tell how the clashes should be handled.
>>> Ah, I love the smell of boilerplate code in the morning!
>>
>> Not boilerplate. Just resolving a couple of conflicts if they arise.
>
> At each place where it arises.
No, once each time you define a package using conflicting packages.
> This can happen in Java too, if the same piece of code uses two
> different classes with the same unqualified name. You can end up with
> code littered with "java.util.Date" and "javax.sql.Date" for instance
> in some types of enterprise code. It's god-awful. All those repeated
> "java.util." and "javax.sql." prefixes add up to quite a lot of
> boilerplate.
Indeed they do.
> Fortunately, it's rare to get name clashes between different peoples'
> nouns and still need to intersperse both in one bit of code. It's much
> more common with verbs:
>
> someIOStream.close();
> aDoor.close();
> aPort.close();
> aSocket.close();
> aTransaction.close();
> if (difference(pointA, pointB).close()) doSomething();
>
> I'd hate to have to fully qualify all my "close"s, or "open"s, or
> "free"s, or "release"s, or "next"s, or "remove"s, or "equals"s,
> instead of the correct one being inferred from the type of the
> expression to the left of it.
Why do you assume you would have to do this in Lisp?
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Paul Donnelly wrote:
>>> Series Expansion <·······@gmail.com> writes:
>>>
>>>> On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
>>>>
>>>>> The CL package system will solve the name collision with no harm done.
>>>> I just explained why the package system won't. Adding new classes in
>>>> their own packages? No problem, the package system can distinguish
>>>> foo.String from bar.String. Adding new methods to an existing class,
>>>> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
>>>> foo.String.doIt()?
>>> I guess that's one of the downsides of an inside-out object
>>> system.
>> Can I jump in here? You see, I have a theory.
>>
>> It goes something like this. Java and most OO languages are actually
>> noun-oriented languages. They follow the natural way of thinking:
>> subject does verb to object. 1 + 1 = 2. And so on.
>
> I'll just jump in right here and point out that
[personal attacks deleted]
Eh, there's nothing left?
Seamus MacRae <··········@live.ca.nospam> writes:
[We'll ignore the fact that + in Common Lisp is not a generic function,
but rather a built-in function that does coercion. We'll also ignore
the fact that complex numbers are built-in to Common Lisp, since
neither fact affects the larger issue here.]
> Now you can see where the problem will show up. If I want to add a
> Complex noun, now I have to add a plus(Complex, Complex) to plus. Which
> means I have to modify something in the system package. Uh-oh!
Well, this paragraph is great up until you get to "Uh-oh!".
There is not "Uh-oh!" in Common Lisp at this point. In fact, that it
precisely the point of all of this. You can do this. It is natural.
It is not a problem. You just do it.
> It all boils down to which programmers will be doing more often: adding
> new nouns which may be used with already-existing verbs, or adding new
> verbs which may be used with already-existing nouns.
Well, why not use a system that makes either one just as easy? Then it
doesn't matter which is more frequent, because either option is handled
exactly the same way. That leads to a nicer, more uniform way of
operating with the language, so that the entire language model is easier
to understand.
> Adding new nouns which are used only with new verbs is not a problem in
> either case.
Right.
> Adding new nouns which may be used with already-existing verbs is not a
> problem if namespaces contain nouns, which contain implementations per
> supported verb. But it is a problem if namespaces contain verbs, which
> contain implementations per supported noun.
Why is that a problem?
BTW, in Common Lisp, namespaces are not tied to classes at all. They
are their own separate entity, so any effect based on namespaces is
equally easy regardless of whether you are talking about new classes,
new generic functions or new methods for existing generic functions.
> Adding new verbs which may be used with already-existing nouns is not a
> problem if namespaces contain verbs, which contain implementations per
> supported noun. But it is a problem if namespaces contain nouns, which
> contain implementations per supported verb.
Right. So here is a class of problem where one particular object system
gets in your way. See, for example, my nice hammer and picnic blanket
analogy elsewhere in this thread.
> So, if new nouns with existing verbs is more common, Java's method is
> better. If new verbs with existing nouns is more common, Lisp's method
> is better. (Leaving static vs. dynamic typing entirely alone here and
> considering only the order of scoping of nouns and verbs within
> namespaces.) Doing the "wrong" one in either language will cause
> headaches unless there's a way to namespace separately by noun and verb,
> which would cause its own inherent variety of headaches instead.
The error in this analysis is conflating the notion of a namespace with
that of a class or function/method. In Java there is such a conflation,
because methods are associated with classes and resolved relative to
them. This is not the case in Common Lisp, so there isn't any
difference from the namespace perspective between adding either one.
One uniform mechanism that handles both cases with equal ease. That is
one reason I think the Common Lisp object model is superior. Another is
multiple-dispatch, but that's a completely different discussion.
>
> My own experience tells me that new nouns with existing verbs is more
> common. I quite often want to define a new Java class that has state. I
> much less often wish for an existing Java class to have a method I've
> never heard of before.
Well, part of that may be conditioning, since you can't really have the
latter. So you learn to do with out it. Well, actually that's perhaps
a bit strong. Typically the solution to this is to either write wrapper
classes or interfaces to add the new functionality or else to use static
methods on some utility class so you can write methods that affect
classes to which you don't have source code access.
> The workaround also isn't usually that bad: create a utility class with
> a static method to do the manipulation. It can't be polymorphic or use
> the object's private state directly, but the latter is for the best and
> the former, while annoying, isn't usually a show-stopper.
Well, the workaround does have the minor problem that you don't get
dynamic dispatch for the static methods. So if you want to have a
hierarchy of classes with different methods, you lose the benefits of
dynamic dispatch and have to manage that yourself. That sounds to me to
be a bit more tedious and potentially error-prone.
> The Lisp way around would present problems.
And yet, oddly enough, in practice there don't seem to be any. It works
just fine.
> On the rare occasion I
> wanted to augment an existing class with new behavior it would be easy:
> define my own verb in my own namespace and set up somehow a polymorphic
> dispatch on object type. On the much more frequent occasion I wanted to
> add a new noun, I'd often be forced to change verbs that lived in
> pre-existing namespaces, and maybe even in more than one namespace; the
> code for my new noun would be scattered all over the codebase AND the
> namespaces within the system, rather than in exactly one place in each.
First of all, you don't "change the verb". You simply add a method.
And there is absolutely no reason that the code for your new class has
to be scattered anywhere. You can, if the organization makes the most
sense for your application, put the method definitions IN THE SAME FILE
as the class definition. If it makes more sense to organize around the
generic function instead, then you can. Or you can even mix it.
The
> Ouch.
No ouch. Simply a misunderstanding of how Common Lisp programs are
organized. This debate really puts you at a bit of a disadvantage,
since the Common Lisp advocates have programmed a lot more in Java than
you have in Common Lisp. And it shows, because lots of misconceptions
about "how things must be" crop up.
That is a result of hearing about a particular lisp feature and then
applying an incorrect noton about "how it must be", based only on your
experience programming in Java. If you wish to broaden your set of
programming skills and increase the intellectual understanding of the
range of design options in programming languages, you would do well to
try out some of the other languages that work differently. One nice
starting place would be Abelson & Sussman's _Structure and
Interpretation of Programming Languages_.
> There's also going to be big differences in polymorphism. With an object
> oriented system, nouns can be subtypes of other nouns, and verb behavior
> can be inherited, with or without modification. Dispatch is based on the
> run-time-type of the noun, and adding a new polymorphic type is easy. In
> Java, suppose there was an Addable interface specifying the plus method,
> and Integer, Float, and Double implemented it. If I created my Complex
> class and implemented Addable, code that did generic sums over Addables
> would automatically also work with Complex now. I wouldn't have to make
> any changes outside the Complex class.
Well, Common Lisp has its own object oriented system. It just works
differently, in both gross and subtle ways that I don't think you are
familiar with.
For example, you write "Dispatch is based on teh run-time-type of THE
noun." That is because you have an assumption that there can only be ONE
object whose run-time-type determines the dispatch. But in Common Lisp
that is not the case. Any combination of the required arguments can be
used to select the actual method to run for a particular generic
function. So, you get an even more flexible polympophism method.
I also don't think you want to try to argue flexibility of method
dispatch at this point. Common Lisp has multiple-argument dynamic
dispatch that also includes dispatching and defining methods on literal
data types.
As for adding a new type, it would be just as easy in Common Lisp. In a
single source file you would provide the class definition for Complex
and then provide a method definition for the "plus" generic function.
You don't need to make any changes to any other location. You can put
this all in the same source file.
Furthermore, you could also define methods that handle the addition of a
complex number to a Double. How would you go about doing that in Java?
You would have to change all of the Integer, Float and Double classes
because you can't arrange to put the new method just in the Complex
class.
> With Lisp, I'd need to change the system namespace's plus verb's
> dispatch table manually so that it knew about my Complex class, on the
> other hand.
Say what? Do you have any clue how Lisp actually works?
You don't change dispatch tables manually. You just write definitions.
Unless you consider defining new classes in Java to be "manually
changing the system's type hierarchy". You really would be a more
credible debate partner if you didn't keep saying things that betray a
complete ignorance of how things work.
> Both problems in one. In fact, every combination of noun and
> verb in dynamic dispatch needs to be explicitly specified
> somewhere. From the sounds of it, I couldn't just say "Complex is a type
> of Number" in Lisp and have the compiler automatically know where to
> dispatch plus, minus, times, and dividedBy;
Um, and if you implement a interface in Java, suddenly all of the
methods are automatically specialized for your new class without you
having to write implementations for them? Really?
In lisp, you could say something like that and any more general methods
would automatically be available. If you want specialized handling of
the type, then you have to write method bodies for them.
> I'd have to edit four
> separate dispatch tables in four separate places, AND define (hopefully
> all in one final, fifth place) my Complex implementations of these that
> the new dispatch table entries would point to.
No, all of the bookkeeping is handled by the language. Just like you
don't need to edit any dispatch tables in Java. What makes you think
you as the programmer need to do it in Lisp? This is pure ignorance of
how things work.
You can do all definitions in contiguous places in a single source file
and you don't have to worry about any of the internal details. That's
why they are internal details.
There are no dispatch tables to edit. There are no separate places to
do anything. You can do it all in one place.
> With Java I'd just have
> to define the implementations, naming them correctly, and stick
> "implements Number" somewhere and away I'd go.
Which is exactly analogous to Common Lisp (assuming CL actually needed
to implement Complex -- which it doesn't, since it's already built-in....)
The structure of the file would be something like this:
(defclass complex (number)
((real-part :type number)
(imaginary-part :type number :init-form 0)))
(defmethod plus ((x complex) (y complex))
...)
(defmethod plus ((x double) (y complex))
...) ;; How do you do this one in Java???
(defmethod multiply ((x complex) (y complex))
...)
etc.
This all goes in one file.
> >> So, basically, you're saying that the way you avoid the name clash is
> >> to make baz's String.doIt() and quux's String.doIt() private.
> > No, he's saying that support methods that don't make up a library's API
> > won't be exported from packages, so there's no hazard of name clashes
> > between them when one chooses to import all symbols from a package.
>
> That's the same thing isn't it? He says "private", you say "won't be
> exported"; it looks the same to me.
But it isn't.
> >>> If anyone want to use the two of them together, and it has some
> >>> symbol clashes (probably just a few of them), this person can
> >>> explicitly tell how the clashes should be handled.
> >> Ah, I love the smell of boilerplate code in the morning!
> > Not boilerplate. Just resolving a couple of conflicts if they arise.
>
> At each place where it arises.
>
> This can happen in Java too, if the same piece of code uses two
> different classes with the same unqualified name. You can end up with
> code littered with "java.util.Date" and "javax.sql.Date" for instance in
> some types of enterprise code. It's god-awful. All those repeated
> "java.util." and "javax.sql." prefixes add up to quite a lot of
> boilerplate.
>
> Fortunately, it's rare to get name clashes between different peoples'
> nouns and still need to intersperse both in one bit of code. It's much
> more common with verbs:
>
> someIOStream.close();
> aDoor.close();
> aPort.close();
> aSocket.close();
> aTransaction.close();
> if (difference(pointA, pointB).close()) doSomething();
>
> I'd hate to have to fully qualify all my "close"s, or "open"s, or
> "free"s, or "release"s, or "next"s, or "remove"s, or "equals"s, instead
> of the correct one being inferred from the type of the expression to the
> left of it.
Well, we think that there is a fundamental difference between different
sorts of close and prefer to make sure they have different names. That
certainly helps out when one ends up making a hybrid class using true
multiple inheritance, where you have to know the difference between the
different CLOSE methods one inherits.
So, there would perhaps be two or three differently named CLOSE
operations, as distinguished by their namespace. And you could have
methods for several of them on the same object. Furthermore, you could
also have general methods (defined on the universal type T, roughly
equivalent to Object in Java), which would then handle the operation for
all of those objects to which it may not apply. Or else you could just
let the standard error handling operate on it.
But it is a different way of seeing and operating, because it is a
different paradigm for doing object-oriented programming. You may or
may not like it, but that would only be an informed choice if you
actually tried working with both systems.
In actual practice, you would only need to use fully-qualified names in
the same type of circumstance that you need fully-qualified names in
Java: When there is an ambiguity in the "short names" in the namespace
that you are operating in.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> In actual practice, you would only need to use fully-qualified names in
> the same type of circumstance that you need fully-qualified names in
> Java: When there is an ambiguity in the "short names" in the namespace
> that you are operating in.
Good news! Lisp is at least as good as Java!
You've made your point.
--
Lew
On May 18, 7:42 pm, Lew <·····@lewscanon.com> wrote:
> Thomas A. Russ wrote:
> > In actual practice, you would only need to use fully-qualified names in
> > the same type of circumstance that you need fully-qualified names in
> > Java: When there is an ambiguity in the "short names" in the namespace
> > that you are operating in.
>
> Good news! Lisp is at least as good as Java!
The evidence gathered thus far does not warrant that conclusion.
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
> [We'll ignore the fact that + in Common Lisp is not a generic function,
> but rather a built-in function that does coercion. We'll also ignore
> the fact that complex numbers are built-in to Common Lisp, since
> neither fact affects the larger issue here.]
>
>> Now you can see where the problem will show up. If I want to add a
>> Complex noun, now I have to add a plus(Complex, Complex) to plus. Which
>> means I have to modify something in the system package. Uh-oh!
>
> Well, this paragraph is great up until you get to "Uh-oh!".
Which means we have a second "uh-oh": the fact that Thomas A. Russ does
not consider it an "uh-oh" that someone has to modify something in the
system package. Uh-oh!
> There is not "Uh-oh!" in Common Lisp at this point. In fact, that it
> precisely the point of all of this. You can do this. It is natural.
> It is not a problem. You just do it.
You just do it, and then your coworkers string you up by your toenails
and leave you hanging from the sprinkler head above the office Xerox
machine overnight.
>> It all boils down to which programmers will be doing more often: adding
>> new nouns which may be used with already-existing verbs, or adding new
>> verbs which may be used with already-existing nouns.
>
> Well, why not use a system that makes either one just as easy?
Because no such system exists. It would require needing to scope both
nouns and verbs separately, instead of the verb being disambiguated
based on the noun or vice versa so only one of the two needed
disambiguation by the programmer. Now the programmer has to worry his
head about both!
> Then it doesn't matter which is more frequent, because either option
> is handled exactly the same way.
Yes. Instead of 84% of the job being easy and the other 16% of it being
hard, or 84% of it being hard and the other 16% being easy, 84% of it is
hard and the other 16% of it is also hard.
> That leads to a nicer, more uniform way of
> operating with the language, so that the entire language model is easier
> to understand.
Easier to understand! You're a laugh riot. Java's basic language model
can be grasped in a day. You've spent more than a week attempting to
convey Lisp's to the people of comp.lang.java.programmer and have
apparently thus confused at least two of them and probably most of them.
Either you're all exceptionally bad at explaining things, down to the
last man, or Lisp is emphatically NOT "easier to understand".
>> Adding new nouns which may be used with already-existing verbs is not a
>> problem if namespaces contain nouns, which contain implementations per
>> supported verb. But it is a problem if namespaces contain verbs, which
>> contain implementations per supported noun.
>
> Why is that a problem?
Because you have to monkey around in someone else's namespace and in
someone else's code to add quux.frobnobdicate() when there's already a
frobnobdicate verb and you're addign the quux noun.
I thought I'd explained this?
> BTW, in Common Lisp, namespaces are not tied to classes at all.
Big mistake.
> They are their own separate entity, so any effect based on namespaces
> is equally easy
which is to say, about as easy as ascending Everest without any special
equipment or any clothing and living to tell the tale
> regardless of whether you are talking about new classes,
> new generic functions or new methods for existing generic functions.
>
>> Adding new verbs which may be used with already-existing nouns is not a
>> problem if namespaces contain verbs, which contain implementations per
>> supported noun. But it is a problem if namespaces contain nouns, which
>> contain implementations per supported verb.
>
> Right. So here is a class of problem where one particular object system
> gets in your way.
The solution adopted by CLOS apparently being to make an object system
that gets in the way for EVERY class of problem!
> See, for example, my nice hammer and picnic blanket analogy elsewhere
> in this thread.
See, for example, the demolition of your hammer and picnic blanket
analogy elsewhere in this thread.
>> So, if new nouns with existing verbs is more common, Java's method is
>> better. If new verbs with existing nouns is more common, Lisp's method
>> is better. (Leaving static vs. dynamic typing entirely alone here and
>> considering only the order of scoping of nouns and verbs within
>> namespaces.) Doing the "wrong" one in either language will cause
>> headaches unless there's a way to namespace separately by noun and verb,
>> which would cause its own inherent variety of headaches instead.
>
> The error in this analysis is conflating the notion of a namespace with
> that of a class or function/method.
I did no such thing. I only assumed that classes and/or
functions/methods live IN namespaces.
I assumed that there were three possible ways to resolve names:
package.class.method (perhaps with inheritance) (Java uses this)
package.method.class
package1.class.package2.method
that is, either packages namespace classes which namespace methods (Java
model), packages namespace methods which namespace classes (don't know
what uses this), or packages namespace both methods and classes.
You seem to be saying that Lisp does the last of the three.
The problem, partly, is the combinatorical explosion of possible package
pairs in every invocation of a method when there are now two packages
involved in resolving every method invocation instead of one.
Regardless, there are no errors in my analysis. Ever.
> One uniform mechanism that handles both cases with equal ease.
Equality of ease isn't the be all and end all. Making it hard in all
cases is worse than making it easy in some cases and hard in others, as
a general rule.
> That is one reason I think the Common Lisp object model is superior.
> Another is multiple-dispatch, but that's a completely different
> discussion.
Heartburn macros upset stomach, dispatch tables diarrhea! Yay, Pepto-Bismol!
>> My own experience tells me that new nouns with existing verbs is more
>> common. I quite often want to define a new Java class that has state. I
>> much less often wish for an existing Java class to have a method I've
>> never heard of before.
>
> Well, part of that may be conditioning
Nope. I'm a human being, not one of Pavlov's dogs, and the suggestion
otherwise is frankly insulting.
> Well, actually that's perhaps a bit strong. Typically the solution to
> this is to either write wrapper classes or interfaces to add the new
> functionality or else to use static methods on some utility class so
> you can write methods that affect classes to which you don't have
> source code access.
Perhaps that is the price of encapsulation and having a non-hairy name
resolution system. The amount of bug-hunting time saved by encapsulation
alone in the history of OO probably makes it worth it.
>> The workaround also isn't usually that bad: create a utility class with
>> a static method to do the manipulation. It can't be polymorphic or use
>> the object's private state directly, but the latter is for the best and
>> the former, while annoying, isn't usually a show-stopper.
>
> Well, the workaround does have the minor problem that you don't get
> dynamic dispatch for the static methods.
Make the utility class have subclasses and change the static method to a
polymorphic one. Well, it still can't be polymorphic in the arguments,
but it can still use the polymorphic methods OF the arguments.
> So if you want to have a
> hierarchy of classes with different methods, you lose the benefits of
> dynamic dispatch and have to manage that yourself. That sounds to me to
> be a bit more tedious and potentially error-prone.
It's going to be no matter what. If you want to add more classes and
more methods both, or more classes with dispatch of a two-argument
method based on the types of both parameters, then no simple inheritance
system is going to work and you'll have to manually specify what to do
for every possible pair ... somehow.
When it's one dimensional, you can use inheritance and have each
subclass take care of itself.
As soon as it's two-or-more dimensional, you can't. Some of the
information about class X or whatever is going to be scattered about,
and there's going to be something like a switch statement, pointer
array, or other explicit dispatch mechanism in the source code.
Lisp just sticks you with this by default instead of letting the cases
that CAN be easy actually BE easy.
>> The Lisp way around would present problems.
>
> And yet, oddly enough, in practice there don't seem to be any. It works
> just fine.
So you claim. Color me skeptical.
>> On the rare occasion I
>> wanted to augment an existing class with new behavior it would be easy:
>> define my own verb in my own namespace and set up somehow a polymorphic
>> dispatch on object type. On the much more frequent occasion I wanted to
>> add a new noun, I'd often be forced to change verbs that lived in
>> pre-existing namespaces, and maybe even in more than one namespace; the
>> code for my new noun would be scattered all over the codebase AND the
>> namespaces within the system, rather than in exactly one place in each.
>
> First of all, you don't "change the verb". You simply add a method.
Which changes the verb.
Adding a method to a class is changing the class, right?
Lisp methods live in generic functions instead of classes, right?
Ergo adding a method to a genetic function changes the generic function.
(Subclassing a class doesn't change the base class. But subclassing a
class creates a new class that has its own name and is in its own
package. Adding a method to a generic function does not create a new
generic function that has its own name and is in its own package. It
adds to the existing generic function instead, thus changing it.)
> And there is absolutely no reason that the code for your new class has
> to be scattered anywhere. You can, if the organization makes the most
> sense for your application, put the method definitions IN THE SAME FILE
> as the class definition. If it makes more sense to organize around the
> generic function instead, then you can. Or you can even mix it.
Your coworkers are going to have SO much fun trying to guess where you
put everything.
>> Ouch.
>
> No ouch.
Yes ouch.
> Simply a misunderstanding of how Common Lisp programs are organized.
I have misunderstood nothing. According to you, Common Lisp programs are
organized at the whims of individual programmers. Not conducive to
scaling up to a large development team, mind you.
> This debate really puts you at a bit of a disadvantage,
etc. etc. etc.
I think I've had quite enough of being insulted by you.
The rest of your text has been deleted unread, with one small exception.
>> There's also going to be big differences in polymorphism. With an object
>> oriented system, nouns can be subtypes of other nouns, and verb behavior
>> can be inherited, with or without modification. Dispatch is based on the
>> run-time-type of the noun, and adding a new polymorphic type is easy. In
>> Java, suppose there was an Addable interface specifying the plus method,
>> and Integer, Float, and Double implemented it. If I created my Complex
>> class and implemented Addable, code that did generic sums over Addables
>> would automatically also work with Complex now. I wouldn't have to make
>> any changes outside the Complex class.
>
>> With Lisp, I'd need to change the system namespace's plus verb's
>> dispatch table manually so that it knew about my Complex class, on the
>> other hand.
>
>> Both problems in one. In fact, every combination of noun and
>> verb in dynamic dispatch needs to be explicitly specified
>> somewhere. From the sounds of it, I couldn't just say "Complex is a type
>> of Number" in Lisp and have the compiler automatically know where to
>> dispatch plus, minus, times, and dividedBy;
>
>> I'd have to edit four
>> separate dispatch tables in four separate places, AND define (hopefully
>> all in one final, fifth place) my Complex implementations of these that
>> the new dispatch table entries would point to.
>
>> With Java I'd just have
>> to define the implementations, naming them correctly, and stick
>> "implements Number" somewhere and away I'd go.
>
>>>> So, basically, you're saying that the way you avoid the name clash is
>>>> to make baz's String.doIt() and quux's String.doIt() private.
>>> No, he's saying that support methods that don't make up a library's API
>>> won't be exported from packages, so there's no hazard of name clashes
>>> between them when one chooses to import all symbols from a package.
>> That's the same thing isn't it? He says "private", you say "won't be
>> exported"; it looks the same to me.
>
>>>>> If anyone want to use the two of them together, and it has some
>>>>> symbol clashes (probably just a few of them), this person can
>>>>> explicitly tell how the clashes should be handled.
>>>> Ah, I love the smell of boilerplate code in the morning!
>>> Not boilerplate. Just resolving a couple of conflicts if they arise.
>> At each place where it arises.
>>
>> This can happen in Java too, if the same piece of code uses two
>> different classes with the same unqualified name. You can end up with
>> code littered with "java.util.Date" and "javax.sql.Date" for instance in
>> some types of enterprise code. It's god-awful. All those repeated
>> "java.util." and "javax.sql." prefixes add up to quite a lot of
>> boilerplate.
>>
>> Fortunately, it's rare to get name clashes between different peoples'
>> nouns and still need to intersperse both in one bit of code. It's much
>> more common with verbs:
>>
>> someIOStream.close();
>> aDoor.close();
>> aPort.close();
>> aSocket.close();
>> aTransaction.close();
>> if (difference(pointA, pointB).close()) doSomething();
>>
>> I'd hate to have to fully qualify all my "close"s, or "open"s, or
>> "free"s, or "release"s, or "next"s, or "remove"s, or "equals"s, instead
>> of the correct one being inferred from the type of the expression to the
>> left of it.
>
> Well, we think that there is a fundamental difference between different
> sorts of close and prefer to make sure they have different names.
So instead of everything you can "close" having a "close" method, you
end up "close"ing one type, "shut"ting another, "slam"ming a third,
"plug"ging a fourth, and onward to increasingly unintuitive and
unguessable names? Wow, that must REALLY help code readability.
On May 20, 12:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Thomas A. Russ wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
>
> > [We'll ignore the fact that + in Common Lisp is not a generic function,
> > but rather a built-in function that does coercion. We'll also ignore
> > the fact that complex numbers are built-in to Common Lisp, since
> > neither fact affects the larger issue here.]
>
> >> Now you can see where the problem will show up. If I want to add a
> >> Complex noun, now I have to add a plus(Complex, Complex) to plus. Which
> >> means I have to modify something in the system package. Uh-oh!
>
> > Well, this paragraph is great up until you get to "Uh-oh!".
>
> Which means we have a second "uh-oh": the fact that Thomas A. Russ does
> not consider it an "uh-oh" that someone has to modify something in the
> system package. Uh-oh!
>
> > There is not "Uh-oh!" in Common Lisp at this point. In fact, that it
> > precisely the point of all of this. You can do this. It is natural.
> > It is not a problem. You just do it.
>
> You just do it, and then your coworkers string you up by your toenails
> and leave you hanging from the sprinkler head above the office Xerox
> machine overnight.
>
> >> It all boils down to which programmers will be doing more often: adding
> >> new nouns which may be used with already-existing verbs, or adding new
> >> verbs which may be used with already-existing nouns.
>
> > Well, why not use a system that makes either one just as easy?
>
> Because no such system exists. It would require needing to scope both
> nouns and verbs separately, instead of the verb being disambiguated
> based on the noun or vice versa so only one of the two needed
> disambiguation by the programmer. Now the programmer has to worry his
> head about both!
What if the package system scoped generic "names", and those "names"
could be used to refer to verbs, nouns, pronouns, etc. etc.? That's
what the CL package system does. It is not attached to function,
classes, methods, variables, ... it's relative to *symbols*, which can
name any of the above.
> > Then it doesn't matter which is more frequent, because either option
> > is handled exactly the same way.
>
> Yes. Instead of 84% of the job being easy and the other 16% of it being
> hard, or 84% of it being hard and the other 16% being easy, 84% of it is
> hard and the other 16% of it is also hard.
>
> > That leads to a nicer, more uniform way of
> > operating with the language, so that the entire language model is easier
> > to understand.
>
> Easier to understand! You're a laugh riot. Java's basic language model
> can be grasped in a day. You've spent more than a week attempting to
> convey Lisp's to the people of comp.lang.java.programmer and have
> apparently thus confused at least two of them and probably most of them.
> Either you're all exceptionally bad at explaining things, down to the
> last man, or Lisp is emphatically NOT "easier to understand".
I have the impression that those two people you're speaking about are
actively trying to remain "confused".
> >> Adding new nouns which may be used with already-existing verbs is not a
> >> problem if namespaces contain nouns, which contain implementations per
> >> supported verb. But it is a problem if namespaces contain verbs, which
> >> contain implementations per supported noun.
>
> > Why is that a problem?
>
> Because you have to monkey around in someone else's namespace and in
> someone else's code to add quux.frobnobdicate() when there's already a
> frobnobdicate verb and you're addign the quux noun.
>
> I thought I'd explained this?
the method MY:frobnodicate(MY:quux) is different from
the method MY:frobnodicate(YOUR:quux) which is different from
the method YOUR:frobnodicate(MY:quux) which is different from
the method YOUR:frobnodicate(YOUR:quux)
this because in general MY:frobnodicate and YOUR:frobnodicate are two
different symbols. Ditto for quux.
> > BTW, in Common Lisp, namespaces are not tied to classes at all.
>
> Big mistake.
Why? I'm curious.
> > They are their own separate entity, so any effect based on namespaces
> > is equally easy
>
> which is to say, about as easy as ascending Everest without any special
> equipment or any clothing and living to tell the tale
Why?
> > regardless of whether you are talking about new classes,
> > new generic functions or new methods for existing generic functions.
>
> >> Adding new verbs which may be used with already-existing nouns is not a
> >> problem if namespaces contain verbs, which contain implementations per
> >> supported noun. But it is a problem if namespaces contain nouns, which
> >> contain implementations per supported verb.
>
> > Right. So here is a class of problem where one particular object system
> > gets in your way.
>
> The solution adopted by CLOS apparently being to make an object system
> that gets in the way for EVERY class of problem!
Why? Give me an example, please.
> > See, for example, my nice hammer and picnic blanket analogy elsewhere
> > in this thread.
>
> See, for example, the demolition of your hammer and picnic blanket
> analogy elsewhere in this thread.
>
> >> So, if new nouns with existing verbs is more common, Java's method is
> >> better. If new verbs with existing nouns is more common, Lisp's method
> >> is better. (Leaving static vs. dynamic typing entirely alone here and
> >> considering only the order of scoping of nouns and verbs within
> >> namespaces.) Doing the "wrong" one in either language will cause
> >> headaches unless there's a way to namespace separately by noun and verb,
> >> which would cause its own inherent variety of headaches instead.
>
> > The error in this analysis is conflating the notion of a namespace with
> > that of a class or function/method.
>
> I did no such thing. I only assumed that classes and/or
> functions/methods live IN namespaces.
>
> I assumed that there were three possible ways to resolve names:
>
> package.class.method (perhaps with inheritance) (Java uses this)
> package.method.class
> package1.class.package2.method
>
> that is, either packages namespace classes which namespace methods (Java
> model), packages namespace methods which namespace classes (don't know
> what uses this), or packages namespace both methods and classes.
>
> You seem to be saying that Lisp does the last of the three.
No. In Lisp you have
package.symbol
and stop. This means there's no difference between
package.className and
package.genericFunctionName
except the fact that they're two different symbols. There's no
namespace associated with a class nor with a gf.
package.class.genericFunction does not make sense in Lisp. Neither
does package.genericFunction.class.
> The problem, partly, is the combinatorical explosion of possible package
> pairs in every invocation of a method when there are now two packages
> involved in resolving every method invocation instead of one.
>
> Regardless, there are no errors in my analysis. Ever.
Sure, and there are no bugs in my code. Ever. Guys, let's be
serious... :)
> > One uniform mechanism that handles both cases with equal ease.
>
> Equality of ease isn't the be all and end all. Making it hard in all
> cases is worse than making it easy in some cases and hard in others, as
> a general rule.
Making it easy in all cases is better than making it easy in some
cases and hard in others, as a general rule.
> > That is one reason I think the Common Lisp object model is superior.
> > Another is multiple-dispatch, but that's a completely different
> > discussion.
>
> Heartburn macros upset stomach, dispatch tables diarrhea! Yay, Pepto-Bismol!
>
> >> My own experience tells me that new nouns with existing verbs is more
> >> common. I quite often want to define a new Java class that has state. I
> >> much less often wish for an existing Java class to have a method I've
> >> never heard of before.
>
> > Well, part of that may be conditioning
>
> Nope. I'm a human being, not one of Pavlov's dogs, and the suggestion
> otherwise is frankly insulting.
>
> > Well, actually that's perhaps a bit strong. Typically the solution to
> > this is to either write wrapper classes or interfaces to add the new
> > functionality or else to use static methods on some utility class so
> > you can write methods that affect classes to which you don't have
> > source code access.
>
> Perhaps that is the price of encapsulation and having a non-hairy name
> resolution system. The amount of bug-hunting time saved by encapsulation
> alone in the history of OO probably makes it worth it.
>
> >> The workaround also isn't usually that bad: create a utility class with
> >> a static method to do the manipulation. It can't be polymorphic or use
> >> the object's private state directly, but the latter is for the best and
> >> the former, while annoying, isn't usually a show-stopper.
>
> > Well, the workaround does have the minor problem that you don't get
> > dynamic dispatch for the static methods.
>
> Make the utility class have subclasses and change the static method to a
> polymorphic one. Well, it still can't be polymorphic in the arguments,
> but it can still use the polymorphic methods OF the arguments.
>
> > So if you want to have a
> > hierarchy of classes with different methods, you lose the benefits of
> > dynamic dispatch and have to manage that yourself. That sounds to me to
> > be a bit more tedious and potentially error-prone.
>
> It's going to be no matter what. If you want to add more classes and
> more methods both, or more classes with dispatch of a two-argument
> method based on the types of both parameters, then no simple inheritance
> system is going to work and you'll have to manually specify what to do
> for every possible pair ... somehow.
Or you can define a general case and specialize only the cases that
interest you, only for the "pairs" (or tuples) that make sense for the
problem at hand.
> When it's one dimensional, you can use inheritance and have each
> subclass take care of itself.
>
> As soon as it's two-or-more dimensional, you can't. Some of the
> information about class X or whatever is going to be scattered about,
> and there's going to be something like a switch statement, pointer
> array, or other explicit dispatch mechanism in the source code.
Maybe then it's not information about class X, but about classes X, Y
and Z. It is precisely this kind of thing that is easy to express in
CLOS and harder in Java (in fact, it is generally avoided in Java and
considered bad practice, but it can't be avoided in all cases, and
sometimes avoiding it causes a convoluted design).
> Lisp just sticks you with this by default instead of letting the cases
> that CAN be easy actually BE easy.
>
> >> The Lisp way around would present problems.
>
> > And yet, oddly enough, in practice there don't seem to be any. It works
> > just fine.
>
> So you claim. Color me skeptical.
What reason on Earth would Thomas have to say it works fine if it
didn't? He's not trying to sell you anything. I (and him too, and
everyone else here, I think) am perfectly fine if you'll never use
Lisp, because Java fits you better. Languages are designed mainly for
humans. But if you confuse your personal preference with objective
truth, and write that "truth" in public, I - we - feel the need to
correct your claims.
> >> On the rare occasion I
> >> wanted to augment an existing class with new behavior it would be easy:
> >> define my own verb in my own namespace and set up somehow a polymorphic
> >> dispatch on object type. On the much more frequent occasion I wanted to
> >> add a new noun, I'd often be forced to change verbs that lived in
> >> pre-existing namespaces, and maybe even in more than one namespace; the
> >> code for my new noun would be scattered all over the codebase AND the
> >> namespaces within the system, rather than in exactly one place in each.
>
> > First of all, you don't "change the verb". You simply add a method.
>
> Which changes the verb.
>
> Adding a method to a class is changing the class, right?
> Lisp methods live in generic functions instead of classes, right?
> Ergo adding a method to a genetic function changes the generic function.
Yes, but only with respect to the types on which the method is
specialized. You don't change the behavior of the "verb" for other
kinds of "nouns".
> (Subclassing a class doesn't change the base class. But subclassing a
> class creates a new class that has its own name and is in its own
> package. Adding a method to a generic function does not create a new
> generic function that has its own name and is in its own package. It
> adds to the existing generic function instead, thus changing it.)
Subclassing a class DOES change the class, if you intend "class" as
the set of all possible instances of that type. Consider:
class A {
int method() { return 42; }
}
calling method() on ANY instance of A will ALWAYS return 42.
Then you add:
class B extends A {
int method() { return 25; }
}
and now, calling method() on instances of A will return 42 in some
cases, 25 in others, due to runtime dispatch.
That's the same with CLOS:
(defgeneric f (arg))
(defclass A () ())
(defmethod f ((arg A)) 42)
(defclass B (A) ())
(defmethod f ((arg B)) 25)
Only difference, CLOS does runtime dispatch on all arguments and not
just one in particular (the implicit one before the dot in Java).
> > And there is absolutely no reason that the code for your new class has
> > to be scattered anywhere. You can, if the organization makes the most
> > sense for your application, put the method definitions IN THE SAME FILE
> > as the class definition. If it makes more sense to organize around the
> > generic function instead, then you can. Or you can even mix it.
>
> Your coworkers are going to have SO much fun trying to guess where you
> put everything.
Not if you follow some convention in your team. This is not specific
to Lisp, conventions are needed in every language that allows more
than one way to do the same thing (IMHO, every serious language).
> >> Ouch.
>
> > No ouch.
>
> Yes ouch.
>
> > Simply a misunderstanding of how Common Lisp programs are organized.
>
> I have misunderstood nothing. According to you, Common Lisp programs are
> organized at the whims of individual programmers. Not conducive to
> scaling up to a large development team, mind you.
Only if you let individual programmers do it at their whim. Just as if
there wasn't no convention among Java programmers in a team on how to
name packages, for example.
> > This debate really puts you at a bit of a disadvantage,
>
> etc. etc. etc.
>
> I think I've had quite enough of being insulted by you.
>
> The rest of your text has been deleted unread, with one small exception.
>
> >> There's also going to be big differences in polymorphism. With an object
> >> oriented system, nouns can be subtypes of other nouns, and verb behavior
> >> can be inherited, with or without modification. Dispatch is based on the
> >> run-time-type of the noun, and adding a new polymorphic type is easy. In
> >> Java, suppose there was an Addable interface specifying the plus method,
> >> and Integer, Float, and Double implemented it. If I created my Complex
> >> class and implemented Addable, code that did generic sums over Addables
> >> would automatically also work with Complex now. I wouldn't have to make
> >> any changes outside the Complex class.
>
> >> With Lisp, I'd need to change the system namespace's plus verb's
> >> dispatch table manually so that it knew about my Complex class, on the
> >> other hand.
>
> >> Both problems in one. In fact, every combination of noun and
> >> verb in dynamic dispatch needs to be explicitly specified
> >> somewhere. From the sounds of it, I couldn't just say "Complex is a type
> >> of Number" in Lisp and have the compiler automatically know where to
> >> dispatch plus, minus, times, and dividedBy;
>
> >> I'd have to edit four
> >> separate dispatch tables in four separate places, AND define (hopefully
> >> all in one final, fifth place) my Complex implementations of these that
> >> the new dispatch table entries would point to.
>
> >> With Java I'd just have
> >> to define the implementations, naming them correctly, and stick
> >> "implements Number" somewhere and away I'd go.
>
> >>>> So, basically, you're saying that the way you avoid the name clash is
> >>>> to make baz's String.doIt() and quux's String.doIt() private.
> >>> No, he's saying that support methods that don't make up a library's API
> >>> won't be exported from packages, so there's no hazard of name clashes
> >>> between them when one chooses to import all symbols from a package.
> >> That's the same thing isn't it? He says "private", you say "won't be
> >> exported"; it looks the same to me.
>
> >>>>> If anyone want to use the two of them together, and it has some
> >>>>> symbol clashes (probably just a few of them), this person can
> >>>>> explicitly tell how the clashes should be handled.
> >>>> Ah, I love the smell of boilerplate code in the morning!
> >>> Not boilerplate. Just resolving a couple of conflicts if they arise.
> >> At each place where it arises.
>
> >> This can happen in Java too, if the same piece of code uses two
> >> different classes with the same unqualified name. You can end up with
> >> code littered with "java.util.Date" and "javax.sql.Date" for instance in
> >> some types of enterprise code. It's god-awful. All those repeated
> >> "java.util." and "javax.sql." prefixes add up to quite a lot of
> >> boilerplate.
>
> >> Fortunately, it's rare to get name clashes between different peoples'
> >> nouns and still need to intersperse both in one bit of code. It's much
> >> more common with verbs:
>
> >> someIOStream.close();
> >> aDoor.close();
> >> aPort.close();
> >> aSocket.close();
> >> aTransaction.close();
> >> if (difference(pointA, pointB).close()) doSomething();
>
> >> I'd hate to have to fully qualify all my "close"s, or "open"s, or
> >> "free"s, or "release"s, or "next"s, or "remove"s, or "equals"s, instead
> >> of the correct one being inferred from the type of the expression to the
> >> left of it.
>
> > Well, we think that there is a fundamental difference between different
> > sorts of close and prefer to make sure they have different names.
>
> So instead of everything you can "close" having a "close" method, you
> end up "close"ing one type, "shut"ting another, "slam"ming a third,
> "plug"ging a fourth, and onward to increasingly unintuitive and
> unguessable names? Wow, that must REALLY help code readability.
No. You'll have a streams:close, a doors:close, a mouth:close, ... if
they're really different verbs (for example, take completely different
parameters). Then, you'll have specializations of the verbs for
related nouns, for example
streams:close(file-stream)
streams:close(network-stream)
etc.
Alessio
Alessio Stalla wrote:
> On May 20, 12:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Thomas A. Russ wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> It all boils down to which programmers will be doing more often: adding
>>>> new nouns which may be used with already-existing verbs, or adding new
>>>> verbs which may be used with already-existing nouns.
>>> Well, why not use a system that makes either one just as easy?
>> Because no such system exists. It would require needing to scope both
>> nouns and verbs separately, instead of the verb being disambiguated
>> based on the noun or vice versa so only one of the two needed
>> disambiguation by the programmer. Now the programmer has to worry his
>> head about both!
>
> What if the package system scoped generic "names", and those "names"
> could be used to refer to verbs, nouns, pronouns, etc. etc.?
That would be even worse: not only would methods and classes both have
to be scoped, so thing.method() would have to have two scopes decided
somehow (and the type of "thing" cannot be a factor in compile-time name
resolution, since as far as the compiler is concerned it could be
anything), but method names and class names could now collide with one
another, and possibly with other things too!
At first this might not seem so bad, since nouns and verbs are mostly
nonoverlapping sets. But some common cases are exceptions: a jump vs. to
jump, for example.
There has been some example code and other text that collectively
implied that Lisp identifiers are not case-sensitive, which means that
using a Java-esque convention of Jump for the noun and jump for the verb
would not avoid a collision.
Worse, this also means JUMP for a global constant will collide with both.
What a mess!
>>> That leads to a nicer, more uniform way of
>>> operating with the language, so that the entire language model is easier
>>> to understand.
>> Easier to understand! You're a laugh riot. Java's basic language model
>> can be grasped in a day. You've spent more than a week attempting to
>> convey Lisp's to the people of comp.lang.java.programmer and have
>> apparently thus confused at least two of them and probably most of them.
>> Either you're all exceptionally bad at explaining things, down to the
>> last man, or Lisp is emphatically NOT "easier to understand".
>
> I have the impression that those two people you're speaking about are
> actively trying to remain "confused".
In at least one instance, that is not true.
>>>> Adding new nouns which may be used with already-existing verbs is not a
>>>> problem if namespaces contain nouns, which contain implementations per
>>>> supported verb. But it is a problem if namespaces contain verbs, which
>>>> contain implementations per supported noun.
>>> Why is that a problem?
>> Because you have to monkey around in someone else's namespace and in
>> someone else's code to add quux.frobnobdicate() when there's already a
>> frobnobdicate verb and you're addign the quux noun.
>>
>> I thought I'd explained this?
>
> the method MY:frobnodicate(MY:quux) is different from
> the method MY:frobnodicate(YOUR:quux) which is different from
> the method YOUR:frobnodicate(MY:quux) which is different from
> the method YOUR:frobnodicate(YOUR:quux)
The methods, yes. It's the little bit of code containing the dispatch
table that concerns me. Someone has to add a (YOUR:quux YOUR:quux)
dispatch to MY:frobnobdicate, for example. If that someone is you, then
you may become a bottleneck in the development effort. If that someone
is the owner of YOUR, then everyone can trample your MY:frobnobdicate
garden. Either way, as team size increases there will be growing pains.
Add to that the misery of the user of these methods having to sort them
all out and explicitly scope at least part of at least three of them and
all of at least one of them.
>>> BTW, in Common Lisp, namespaces are not tied to classes at all.
>> Big mistake.
>
> Why? I'm curious.
Encapsulation, among other things I've already explained in previous posts.
>>> They are their own separate entity, so any effect based on namespaces
>>> is equally easy
>> which is to say, about as easy as ascending Everest without any special
>> equipment or any clothing and living to tell the tale
>
> Why?
Ditto.
>>> regardless of whether you are talking about new classes,
>>> new generic functions or new methods for existing generic functions.
>>>> Adding new verbs which may be used with already-existing nouns is not a
>>>> problem if namespaces contain verbs, which contain implementations per
>>>> supported noun. But it is a problem if namespaces contain nouns, which
>>>> contain implementations per supported verb.
>>> Right. So here is a class of problem where one particular object system
>>> gets in your way.
>> The solution adopted by CLOS apparently being to make an object system
>> that gets in the way for EVERY class of problem!
>
> Why?
Ditto.
>> package.class.method (perhaps with inheritance) (Java uses this)
>> package.method.class
>> package1.class.package2.method
>>
>> that is, either packages namespace classes which namespace methods (Java
>> model), packages namespace methods which namespace classes (don't know
>> what uses this), or packages namespace both methods and classes.
>>
>> You seem to be saying that Lisp does the last of the three.
>
> No.
Yes.
> In Lisp you have
>
> package.symbol
>
> and stop. This means there's no difference between
>
> package.className and
> package.genericFunctionName
That's when you're referring to just one of those. I'm discussing the
commonplace situation when you're referring to one of each. Then you
need to specify 2 packages. Somehow.
>> The problem, partly, is the combinatorical explosion of possible package
>> pairs in every invocation of a method when there are now two packages
>> involved in resolving every method invocation instead of one.
>>
>> Regardless, there are no errors in my analysis. Ever.
>
> Sure
>
>>> One uniform mechanism that handles both cases with equal ease.
>> Equality of ease isn't the be all and end all. Making it hard in all
>> cases is worse than making it easy in some cases and hard in others, as
>> a general rule.
>
> Making it easy in all cases is better than making it easy in some
> cases and hard in others, as a general rule.
If you could actually do that, the above sentence would actually be
relevant to this discussion.
>>> That is one reason I think the Common Lisp object model is superior.
>>> Another is multiple-dispatch, but that's a completely different
>>> discussion.
>>
>> Heartburn macros upset stomach, dispatch tables diarrhea! Yay, Pepto-Bismol!
>>
>>> So if you want to have a
>>> hierarchy of classes with different methods, you lose the benefits of
>>> dynamic dispatch and have to manage that yourself. That sounds to me to
>>> be a bit more tedious and potentially error-prone.
>> It's going to be no matter what. If you want to add more classes and
>> more methods both, or more classes with dispatch of a two-argument
>> method based on the types of both parameters, then no simple inheritance
>> system is going to work and you'll have to manually specify what to do
>> for every possible pair ... somehow.
>
> Or you can define a general case and specialize only the cases that
> interest you, only for the "pairs" (or tuples) that make sense for the
> problem at hand.
The (foo foo) (bar bar) syntax does not allow to "define a general
case", save if all project objects inherit from some class, say Object,
and you put in a dispatch for (Object Object) (Object Object), and this
respects inheritance, so any call lacking a more specialized applicable
dispatch with arguments both inheriting from Object will get that dispatch.
Then the real fun begins: enforcing "NO CLASSES NOT DERIVED FROM
OBJECT!!" everywhere in the project. Unless CLOS already has an
omni-superclass like Java's java.lang.Object class.
>> When it's one dimensional, you can use inheritance and have each
>> subclass take care of itself.
>>
>> As soon as it's two-or-more dimensional, you can't. Some of the
>> information about class X or whatever is going to be scattered about,
>> and there's going to be something like a switch statement, pointer
>> array, or other explicit dispatch mechanism in the source code.
>
> Maybe then it's not information about class X, but about classes X, Y
> and Z. It is precisely this kind of thing that is easy to express in
> CLOS
It is easy to express precisely nowhere. CLOS lets you lump everything
to do with X, Y, and Z together in the same place. So? This might easily
end up meaning pretty much the whole project. So much for namespaces,
nevermind encapsulation, which we'd already given up on ages ago.
>> Lisp just sticks you with this by default instead of letting the cases
>> that CAN be easy actually BE easy.
>>
>>>> The Lisp way around would present problems.
>>> And yet, oddly enough, in practice there don't seem to be any. It works
>>> just fine.
>> So you claim. Color me skeptical.
>
> What reason on Earth would Thomas have to say it works fine if it
> didn't?
I do not know, though strongly suspect "appearing to be the victor of a
particular Usenet pissing match" to be among his motives. Nonetheless,
what he claimed flies in the face of logic.
> But if you confuse your personal preference with objective
> truth, and write that "truth" in public, I - we - feel the need to
> correct your claims.
That statement makes several insulting and false insinuations about me.
>> Adding a method to a class is changing the class, right?
>> Lisp methods live in generic functions instead of classes, right?
>> Ergo adding a method to a genetic function changes the generic function.
>
> Yes
I'm glad that particular dispute is finally settled.
>> (Subclassing a class doesn't change the base class. But subclassing a
>> class creates a new class that has its own name and is in its own
>> package. Adding a method to a generic function does not create a new
>> generic function that has its own name and is in its own package. It
>> adds to the existing generic function instead, thus changing it.)
>
> Subclassing a class DOES change the class, if you intend "class" as
> the set of all possible instances of that type.
Sophistry. It doesn't change the base class itself, and indeed, code
that uses the base class won't be affected unless someone passes it a
reference to a derived-class instance.
Since there aren't separate "base" and "derived" generic functions in
Lisp, however, the above does not apply there, and the "base itself" IS
changed.
Uh-oh.
>>> And there is absolutely no reason that the code for your new class has
>>> to be scattered anywhere. You can, if the organization makes the most
>>> sense for your application, put the method definitions IN THE SAME FILE
>>> as the class definition. If it makes more sense to organize around the
>>> generic function instead, then you can. Or you can even mix it.
>> Your coworkers are going to have SO much fun trying to guess where you
>> put everything.
>
> Not if you follow some convention in your team.
Given all the places things can be squirreled away, a) defining such a
convention to be both complete and consistent will be non-trivial and b)
so will enforcing it.
In fact, the potential complexity of the system you've described may
suffice to invoke the incompleteness theorem, ensuring that NO
convention could EVER be devised to be both complete and consistent.
> This is not specific
> to Lisp, conventions are needed in every language that allows more
> than one way to do the same thing (IMHO, every serious language).
But the more ways there are to do a thing, the worse it gets; indeed,
you can easily get a combinatorial explosion like the one that nuked
perl as a viable language for large-scale development efforts.
>>> Simply a misunderstanding of how Common Lisp programs are organized.
>> I have misunderstood nothing. According to you, Common Lisp programs are
>> organized at the whims of individual programmers. Not conducive to
>> scaling up to a large development team, mind you.
>
> Only if you let individual programmers do it at their whim. Just as if
> there wasn't no convention among Java programmers in a team on how to
> name packages, for example.
Java needs relatively few conventions BESIDES how to name packages. Lisp
will need a convention the documentation of which would consume 74,172
trees (plus or minus five) to print and massing 11.3 tons. Looking up
anything in the convention will take 1 month, 17 days, 3 hours and 11
minutes, plus or minus one, assuming it's found on average halfway
through. The one upside is that it will make one hell of a paperweight
or doorstop.
>>> Well, we think that there is a fundamental difference between different
>>> sorts of close and prefer to make sure they have different names.
>> So instead of everything you can "close" having a "close" method, you
>> end up "close"ing one type, "shut"ting another, "slam"ming a third,
>> "plug"ging a fourth, and onward to increasingly unintuitive and
>> unguessable names? Wow, that must REALLY help code readability.
>
> No.
Yes. Thomas said you'd not use "close" for everything that closes, which
means Fun With Your Thesaurus time folks!
> streams:close(file-stream)
This vs. Java's fileStream.close(). And you guys said *Java* is bloated
and looks like vomit?!
On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
[...]
> I do not know, though strongly suspect "appearing to be the victor of a
> particular Usenet pissing match" to be among his motives. Nonetheless,
> what he claimed flies in the face of logic.
[...]
> That statement makes several insulting and false insinuations about me.
OK, that's comedy gold right there.
Cheers,
Pillsy
On May 20, 6:46 pm, Pillsy <·········@gmail.com> wrote:
> On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > That statement makes several insulting and false insinuations about me.
>
> OK, that's comedy gold right there.
You know, I thought that perhaps I was forming a rather unfair opinion
of Seamus.
I thought that maybe he was geniunely competent as a Java programmer,
but having trouble grasping some CL concepts.
So I thought I'd take a look at comp.lang.java.programmer, and perhaps
report back that he was actually quite reasonable there...
However:
http://groups.google.co.in/group/comp.lang.java.programmer/browse_thread/thread/79b734ca7c276521/ed286a98157a62e5?#ed286a98157a62e5
I would hate to offend him, so I won't quote directly.
Trust me though, comedy gold lies here also...
Jamie
·······@gmail.com wrote:
> On May 20, 6:46 pm, Pillsy <·········@gmail.com> wrote:
>> On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> That statement makes several insulting and false insinuations about me.
>> OK, that's comedy gold right there.
>
> [a lot of flamage and no worthwhile content]
I don't even know you. Why appear out of nowhere just to conduct a
drive-by flaming of a random bystander?
On May 20, 7:40 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> ·······@gmail.com wrote:
> > On May 20, 6:46 pm, Pillsy <·········@gmail.com> wrote:
> >> On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>> That statement makes several insulting and false insinuations about me.
> >> OK, that's comedy gold right there.
>
> > [a lot of flamage and no worthwhile content]
>
> I don't even know you. Why appear out of nowhere just to conduct a
> drive-by flaming of a random bystander?
Because on the (remote) offchance that somebody who's curious about CL
is still reading this thread, I would hate for them to believe the
misguided nonsense you have posted.
The word "nonsense" is justified because the overwhelming majority of
what you have said appears factually incorrect, and you have not shown
any interest in providing any corroborating evidence (or even a cogent
argument).
Note that I did not call you a liar, because I do not know you.
Perhaps you could extend this courtesy to some of the other
participants?
Jamie
PS: "drive-by flaming" is marvellous. Thanks!
·······@gmail.com wrote:
> On May 20, 7:40 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> ·······@gmail.com wrote:
>>> On May 20, 6:46 pm, Pillsy <·········@gmail.com> wrote:
>>>> On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> That statement makes several insulting and false insinuations about me.
>>>> OK, that's comedy gold right there.
>>> [a lot of flamage and no worthwhile content]
>> I don't even know you. Why appear out of nowhere just to conduct a
>> drive-by flaming of a random bystander?
>
> Because on the (remote) offchance that somebody who's curious about CL
> is still reading this thread, I would hate for them to believe the
> misguided nonsense you have posted.
I have posted no misguided nonsense. On the other hand, you have so far
devoted all three of your posts to this thread to exactly that.
> The word "nonsense" is justified because [insult] and you have not shown
> any interest in providing any corroborating evidence (or even a cogent
> argument).
Those are damned lies! I have supplied lots of cogent arguments and the
occasional citation or other form of evidence.
The closest to "evidence" you lot seem to get, meanwhile, is anecdotes,
assertions, and holier-than-thou attitudes.
> Note that I did not call you a liar, because I do not know you.
>
> Perhaps you could extend this courtesy to some of the other
> participants?
Certainly, but not to you; you publicly called me several inapplicable
names when you should have known better, and that makes you a liar.
> Jamie
>
> PS: "drive-by flaming" is marvellous. Thanks!
Well, that's no longer applicable now that you've unfortunately decided
to return to the scene and then become a repeat offender.
On May 20, 8:19 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> I have posted no misguided nonsense. On the other hand, you have so far
> devoted all three of your posts to this thread to exactly that.
>
> > The word "nonsense" is justified because [insult] and you have not shown
> > any interest in providing any corroborating evidence (or even a cogent
> > argument).
Seamus, engage your obviously superior reasoning skills and consider
the following, which you abbreviated to "[insult]":
"...the overwhelming majority of
what you have said appears factually incorrect..."
I wonder whether you characterise the above as:
a) A statement that I believe that much of what you have said is
incorrect.
b) An insult.
Considering your distaste at being misquoted, intentionally or
otherwise, I find this most amusing.
> Those are damned lies! I have supplied lots of cogent arguments and the
> occasional citation or other form of evidence.
Yes, Seamus, but they were all demonstrated to be wrong.
> > Note that I did not call you a liar, because I do not know you.
>
> > Perhaps you could extend this courtesy to some of the other
> > participants?
>
> Certainly, but not to you; you publicly called me several inapplicable
> names when you should have known better, and that makes you a liar.
I don't see any such post. Citations please?
Note that I am still not calling you a liar, or even a troll.
Jamie
·······@gmail.com wrote:
> On May 20, 8:19 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> I have posted no misguided nonsense. On the other hand, you have so far
>> devoted all three of your posts to this thread to exactly that.
>>
>>> The word "nonsense" is justified because [insult] and you have not shown
>>> any interest in providing any corroborating evidence (or even a cogent
>>> argument).
>
> Seamus, engage your obviously superior reasoning skills and consider
> the following, which you abbreviated to "[insult]":
>
> [insult]
I bear no interest in your opinion of me whatsoever, so repeating it can
accomplish nothing of worth.
Let's return to the subject of comparing Lisp and Java, which I *am*
somewhat interested in, and leave our personal opinions of one another
out of it please.
>> Those are damned lies! I have supplied lots of cogent arguments and the
>> occasional citation or other form of evidence.
>
> Yes, Seamus
Retraction accepted.
>>> Note that I did not call you a liar, because I do not know you.
>>> Perhaps you could extend this courtesy to some of the other
>>> participants?
>> Certainly, but not to you; you publicly called me several inapplicable
>> names when you should have known better, and that makes you a liar.
>
> I don't see any such post.
EVERY SINGLE post where you have engaged in petty namecalling and
similar behavior instead of discussing Lisp and Java.
> Note that I am still not calling you a liar, or even a troll.
Is that a threat?
On May 22, 9:43 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> ·······@gmail.com wrote:
> > On May 20, 8:19 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> I have posted no misguided nonsense. On the other hand, you have so far
> >> devoted all three of your posts to this thread to exactly that.
>
> >>> The word "nonsense" is justified because [insult] and you have not shown
> >>> any interest in providing any corroborating evidence (or even a cogent
> >>> argument).
>
> > Seamus, engage your obviously superior reasoning skills and consider
Now I can see where I went wrong.
Plonk.
> > the following, which you abbreviated to "[insult]":
>
> > [insult]
>
> I bear no interest in your opinion of me whatsoever, so repeating it can
> accomplish nothing of worth.
>
> Let's return to the subject of comparing Lisp and Java, which I *am*
> somewhat interested in, and leave our personal opinions of one another
> out of it please.
>
> >> Those are damned lies! I have supplied lots of cogent arguments and the
> >> occasional citation or other form of evidence.
>
> > Yes, Seamus
>
> Retraction accepted.
>
> >>> Note that I did not call you a liar, because I do not know you.
> >>> Perhaps you could extend this courtesy to some of the other
> >>> participants?
> >> Certainly, but not to you; you publicly called me several inapplicable
> >> names when you should have known better, and that makes you a liar.
>
> > I don't see any such post.
>
> EVERY SINGLE post where you have engaged in petty namecalling and
> similar behavior instead of discussing Lisp and Java.
>
> > Note that I am still not calling you a liar, or even a troll.
>
> Is that a threat?
No.
Persistent troll is persistent...
·······@gmail.com wrote:
> On May 22, 9:43 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> ·······@gmail.com wrote:
>>> On May 20, 8:19 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> I have posted no misguided nonsense. On the other hand, you have so far
>>>> devoted all three of your posts to this thread to exactly that.
>>>>> The word "nonsense" is justified because [insult] and you have not shown
>>>>> any interest in providing any corroborating evidence (or even a cogent
>>>>> argument).
>>> Seamus, engage your obviously superior reasoning skills and consider
>
> Now I can see where I went wrong.
Another personal attack, in lieu of rational argumentation. And you
wonder why I don't respond in the way that you'd like. Perhaps if you
tried to persuade rather than browbeat me, you'd get better results?
>>> Note that I am still not calling you a liar, or even a troll.
>> Is that a threat?
>
> No.
>
> Persistent troll is persistent...
Apparently it was a threat.
Regardless, yet another personal attack does not an argument in favor of
either Lisp or Java make.
On 2009-05-27, Seamus MacRae <··········@live.ca.invalid> wrote:
>
Oh look, the troll is now permuting his From: header to
evade killfiles. Previously it was ``live.ca.nospam''.
Kaz Kylheku wrote:
> On 2009-05-27, Seamus MacRae <··········@live.ca.invalid> wrote:
>
> Oh look, the troll
Personal attack. Not a rational argument in favor of either language.
> is now permuting his From: header
I changed it once.
> to evade killfiles.
Nope. I had another reason.
Seamus MacRae <··········@live.ca.nospam> writes:
> ·······@gmail.com wrote:
> > On May 20, 6:46 pm, Pillsy <·········@gmail.com> wrote:
> >> On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>> That statement makes several insulting and false insinuations about me.
> >> OK, that's comedy gold right there.
> > [a lot of flamage and no worthwhile content]
>
> I don't even know you. Why appear out of nowhere just to conduct a
> drive-by flaming of a random bystander?
Hmmm. Continuing the legacy of "interesting" statements. I would
suggest that the choice was not random. And you are hardly a bystander,
given the volume of postings.
One might wonder what motivated you to appear out of nowhere just to
conduct an extended campaign of posting drivel to two technical
newsgroups.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> ·······@gmail.com wrote:
>>> On May 20, 6:46 pm, Pillsy <·········@gmail.com> wrote:
>>>> On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> That statement makes several insulting and false insinuations about me.
>>>> OK, that's comedy gold right there.
>>> [a lot of flamage and no worthwhile content]
>> I don't even know you. Why appear out of nowhere just to conduct a
>> drive-by flaming of a random bystander?
>
> [calls me a liar and accuses me falsely of posting "drivel"]
I have posted technical posts. You have posted what, a big steaming pile
of ad hominems? Yours are the drivel posts, my friend.
Pillsy wrote:
> On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> [...]
>> I do not know, though strongly suspect "appearing to be the victor of a
>> particular Usenet pissing match" to be among his motives. Nonetheless,
>> what he claimed flies in the face of logic.
> [...]
>> That statement makes several insulting and false insinuations about me.
>
> OK, that's comedy gold right there.
No, that's an intentional and dishonest misquotation of me that takes
one of my comments out of context. What I actually said:
>> What reason on Earth would Thomas have to say it works fine if it
>> didn't?
>
> I do not know, though strongly suspect "appearing to be the victor of
> a particular Usenet pissing match" to be among his motives.
> Nonetheless, what he claimed flies in the face of logic.
>
>> But if you confuse your personal preference with objective
>> truth, and write that "truth" in public, I - we - feel the need to
>> correct your claims.
>
> That statement makes several insulting and false insinuations about me.
Clearly the first paragraph by me refers to Thomas and the second to
some text that Thomas wrote.
Do not intentionally misquote me again.
On May 20, 2:38 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > On May 20, 1:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > [...]
> >> I do not know, though strongly suspect "appearing to be the victor of a
> >> particular Usenet pissing match" to be among his motives. Nonetheless,
> >> what he claimed flies in the face of logic.
> > [...]
> >> That statement makes several insulting and false insinuations about me.
> > OK, that's comedy gold right there.
> No, that's an intentional and dishonest misquotation of me that takes
> one of my comments out of context.
Or not. In one paragraph, you're complaining insulting insinuations
about a third party (Thomas A. Russ), and in next, you're complaining
about someone making insulting insinuations about you.
[...]
> Clearly the first paragraph by me refers to Thomas and the second to
> some text that Thomas wrote.
So clearly, in fact, that my change did nothing to obscure that fact.
Your lucid writing almost makes up for your hypocrisy and willful
ignorance. FSVO "almost", anyway.
> intentionally misquote me
Well, if you insist!
Pillsy
Pillsy wrote:
> On May 20, 2:38 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> OK, that's comedy gold right there.
>
>> No, that's an intentional and dishonest misquotation of me that takes
>> one of my comments out of context.
>
> Or
Or nothing. It was an intentional and dishonest misquotation of me that
took one of my comments out of context.
>> Clearly the first paragraph by me refers to Thomas and the second to
>> some text that Thomas wrote.
>
> So clearly, in fact, that my change did nothing to obscure that fact.
In other words, you cocked it up!
> Your lucid writing
Thanks
> almost makes up for your hypocrisy and willful ignorance.
But no thanks. None of that's true of course.
>> Do not intentionally misquote me again
>
> Well, if you insist!
I'll hold you to that.
On May 20, 4:45 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
[...]
> > Your lucid writing
> Thanks
> > almost makes up for your hypocrisy and willful ignorance.
> But no thanks. None of that's true of course.
OK, fine: your crappy writing does nothing to make up for your
hypocrisy and willful ignorance.
Feel free to have the last word.
Later,
Pillsy
Pillsy wrote:
> On May 20, 4:45 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
> [...]
>>> Your lucid writing
>
>> Thanks
>
>>> almost makes up for your hypocrisy and willful ignorance.
>
>> But no thanks. None of that's true of course.
>
> OK, fine: your crappy writing does nothing to make up for your
> hypocrisy and willful ignorance.
:-)
Arne
Arne Vajh�j wrote:
> Pillsy wrote:
>> On May 20, 4:45 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Pillsy wrote:
>> [...]
>>>> Your lucid writing
>>
>>> Thanks
>>
>>>> almost makes up for your hypocrisy and willful ignorance.
>>
>>> But no thanks. None of that's true of course.
>>
>> OK, fine: your crappy writing does nothing to make up for your
>> hypocrisy and willful ignorance.
>
> :-)
I'd find it touching that you find it amusing to see people viciously
attacking each other, if I happened to be a sadistic psychopath reading
this from in a prison library. And then when I got out I might track you
down and do things to you.
How fortunate for you that I'm not, and the only thing I'm likely to do
in response to this sort of silliness is think "the lot of you are a
bunch of stupid assholes" and take nothing you write very seriously ever
again.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Pillsy wrote:
>>> On May 20, 4:45 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Pillsy wrote:
>>> [...]
>>>>> Your lucid writing
>>>
>>>> Thanks
>>>
>>>>> almost makes up for your hypocrisy and willful ignorance.
>>>
>>>> But no thanks. None of that's true of course.
>>>
>>> OK, fine: your crappy writing does nothing to make up for your
>>> hypocrisy and willful ignorance.
>>
>> :-)
>
> I'd find it touching that you find it amusing to see people viciously
> attacking each other, if I happened to be a sadistic psychopath reading
> this from in a prison library. And then when I got out I might track you
> down and do things to you.
>
> How fortunate for you that I'm not, and the only thing I'm likely to do
> in response to this sort of silliness is think "the lot of you are a
> bunch of stupid assholes" and take nothing you write very seriously ever
> again.
Does that include not replying to it??
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Pillsy wrote:
>>>> On May 20, 4:45 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> Pillsy wrote:
>>>> [...]
>>>>>> Your lucid writing
>>>>
>>>>> Thanks
>>>>
>>>>>> almost makes up for your hypocrisy and willful ignorance.
>>>>
>>>>> But no thanks. None of that's true of course.
>>>>
>>>> OK, fine: your crappy writing does nothing to make up for your
>>>> hypocrisy and willful ignorance.
>>>
>>> :-)
>>
>> I'd find it touching that you find it amusing to see people viciously
>> attacking each other, if I happened to be a sadistic psychopath
>> reading this from in a prison library. And then when I got out I might
>> track you down and do things to you.
>>
>> How fortunate for you that I'm not, and the only thing I'm likely to
>> do in response to this sort of silliness is think "the lot of you are
>> a bunch of stupid assholes" and take nothing you write very seriously
>> ever again.
>
> Does that include not replying to it??
That depends. If "it" includes an incorrect public statement or
implication about me, I shall feel obliged to publicly correct it.
Otherwise, I may very well let it slide.
Pillsy wrote:
> On May 20, 4:45 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
> [...]
>>> Your lucid writing
>
>> Thanks
>
>>> almost makes up for your hypocrisy and willful ignorance.
>
>> But no thanks. None of that's true of course.
>
> OK, fine: your crappy writing does nothing to make up for your
> hypocrisy and willful ignorance.
More stupid ad hominems. Please tell me how you get from this insulting
drivel to a conclusion that Java is inferior to Lisp. Let me guess: you
can't, because the latter does not logically follow from the former.
That's called a fallacy, in this case argumentum ad hominem. Now in the
future, you need real arguments that actually hang together logically.
That means no more ad hominem. No more arguing against the man. If you
take issue with an argument I make in favor of static typing, say, that
means you argue logically against static typing rather than that you
call me names and then say "well, then, since he's an idiot, whatever
he's saying must be stupid, so static typing is stupid, and Lisp's the
best, yeah!!!1!1one" when in fact "he's an idiot" is a false premise,
the conclusion that static typing is bad wouldn't follow from the
premise even if the premise WERE true, and indeed the conclusion that
Lisp beats Java wouldn't follow from static typing being bad even if
THAT were true -- otherwise it would follow that a dynamically-typed
INTERCAL dialect also beat Java, which seems doubtful.
["Followup-To:" header set to comp.lang.lisp.]
On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
>> On May 20, 4:45 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Pillsy wrote:
>> [...]
>>>> Your lucid writing
>>
>>> Thanks
>>
>>>> almost makes up for your hypocrisy and willful ignorance.
>>
>>> But no thanks. None of that's true of course.
>>
>> OK, fine: your crappy writing does nothing to make up for your
>> hypocrisy and willful ignorance.
>
> More stupid ad hominems.
Now go look up what the ad hominem fallacy actaully means.
Recognizing that your opponent in a debate is a pitiful moron is not the ad
hominem falacy.
Ad hominem means that you weave irrelevant facts from someone's background
into an argument against him.
That you're willfully ignorant is not an irrelevant fact about your background.
Kaz Kylheku wrote:
> ["Followup-To:" header set to comp.lang.lisp.]
> On 2009-05-22, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> On May 20, 4:45 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Pillsy wrote:
>>> [...]
>>>>> Your lucid writing
>>>> Thanks
>>>>> almost makes up for your hypocrisy and willful ignorance.
>>>> But no thanks. None of that's true of course.
>>> OK, fine: your crappy writing does nothing to make up for your
>>> hypocrisy and willful ignorance.
>> More stupid ad hominems.
>
> Now go look up what the ad hominem fallacy actaully means.
And another stupid ad hominem. Implying that your opponent doesn't
understand ad hominem, and therefore Lisp beats Java.
> Recognizing that your opponent in a debate is a pitiful moron is not the ad
> hominem falacy.
Your opponent is a moron, therefore Lisp beats Java.
> Ad hominem means that you weave irrelevant facts from someone's background
> into an argument against him.
It means that you weave irrelevant arguments against the person saying
something into an argument against the something.
Often those arguments against the person are not facts, but rather
opinions, ill-informed speculation, errors, and even outright lies; such
certainly seems to be the case here.
You are attempting to argue for Lisp in preference to Java. Calling me
names does not furnish any rational basis for preferring Lisp to Java.
That is the error in your logic that I am endeavoring to point out.
> That you're willfully ignorant is not an irrelevant fact about your background.
Of course not -- it is not a fact at all, so certainly it is not an
"irrelevant fact about my background".
P.S. Please stop trying to redirect my replies out of
comp.lang.java.programmer. If you badmouth me in
comp.lang.java.programmer then I will respond in my own defense in
comp.lang.java.programmer. Trying to prevent me from doing so is a)
futile, b) annoying, and c) rude and antisocial behavior.
Seamus MacRae wrote:
> P.S. Please stop trying to redirect my replies out of
> comp.lang.java.programmer. If you badmouth me in
> comp.lang.java.programmer then I will respond in my own defense in
> comp.lang.java.programmer.
I am sure the readers of cljp would appreciate to be left out.
And don't worry about your reputation - it will not be
harmed by cljp not seeing your replies.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> P.S. Please stop trying to redirect my replies out of
>> comp.lang.java.programmer. If you badmouth me in
>> comp.lang.java.programmer then I will respond in my own defense in
>> comp.lang.java.programmer.
>
> I am sure the readers of cljp would appreciate
What they would appreciate is irrelevant. Kaz Kylheku has no reason to
care, and I've already indicated my own wishes.
> And don't worry about your reputation - it will not be
> harmed by cljp not seeing your replies.
In your opinion.
On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 20, 12:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Thomas A. Russ wrote:
> >>> Seamus MacRae <··········@live.ca.nospam> writes:
> >>>> It all boils down to which programmers will be doing more often: adding
> >>>> new nouns which may be used with already-existing verbs, or adding new
> >>>> verbs which may be used with already-existing nouns.
> >>> Well, why not use a system that makes either one just as easy?
> >> Because no such system exists. It would require needing to scope both
> >> nouns and verbs separately, instead of the verb being disambiguated
> >> based on the noun or vice versa so only one of the two needed
> >> disambiguation by the programmer. Now the programmer has to worry his
> >> head about both!
>
> > What if the package system scoped generic "names", and those "names"
> > could be used to refer to verbs, nouns, pronouns, etc. etc.?
>
> That would be even worse: not only would methods and classes both have
> to be scoped, so thing.method() would have to have two scopes decided
> somehow (and the type of "thing" cannot be a factor in compile-time name
> resolution, since as far as the compiler is concerned it could be
> anything), but method names and class names could now collide with one
> another, and possibly with other things too!
They don't, because a name can refer to more than one "thing" at once,
and the intended meaning is apparent from the context:
(make-instance 'name ...) ;class name
(name ...) ;function, macro or special operator
(setq name 45) ;variable
etc.
> At first this might not seem so bad, since nouns and verbs are mostly
> nonoverlapping sets. But some common cases are exceptions: a jump vs. to
> jump, for example.
>
> There has been some example code and other text that collectively
> implied that Lisp identifiers are not case-sensitive, which means that
> using a Java-esque convention of Jump for the noun and jump for the verb
> would not avoid a collision.
>
> Worse, this also means JUMP for a global constant will collide with both.
>
> What a mess!
>
> >>> That leads to a nicer, more uniform way of
> >>> operating with the language, so that the entire language model is easier
> >>> to understand.
> >> Easier to understand! You're a laugh riot. Java's basic language model
> >> can be grasped in a day. You've spent more than a week attempting to
> >> convey Lisp's to the people of comp.lang.java.programmer and have
> >> apparently thus confused at least two of them and probably most of them.
> >> Either you're all exceptionally bad at explaining things, down to the
> >> last man, or Lisp is emphatically NOT "easier to understand".
>
> > I have the impression that those two people you're speaking about are
> > actively trying to remain "confused".
>
> In at least one instance, that is not true.
>
> >>>> Adding new nouns which may be used with already-existing verbs is not a
> >>>> problem if namespaces contain nouns, which contain implementations per
> >>>> supported verb. But it is a problem if namespaces contain verbs, which
> >>>> contain implementations per supported noun.
> >>> Why is that a problem?
> >> Because you have to monkey around in someone else's namespace and in
> >> someone else's code to add quux.frobnobdicate() when there's already a
> >> frobnobdicate verb and you're addign the quux noun.
>
> >> I thought I'd explained this?
>
> > the method MY:frobnodicate(MY:quux) is different from
> > the method MY:frobnodicate(YOUR:quux) which is different from
> > the method YOUR:frobnodicate(MY:quux) which is different from
> > the method YOUR:frobnodicate(YOUR:quux)
>
> The methods, yes. It's the little bit of code containing the dispatch
> table that concerns me.
> Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobdicate, for example.
Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which may
or may not make sense depending on what MY:frobnobdicate and YOUR:quux
mean.
For example, it is very sensible to do:
(defmethod common-lisp:print-object ((object my-library:my-
class)) ...printing code for my objects...)
- I have explicitly used common-lisp: here even if it's superfluous
(like java.lang) to make things clearer -
it probably does not make much sense to do
(defmethod db-library:open-transaction ((transaction-manager picture-
library:jpeg-picture)) ...whatever...)
> If that someone is you, then
> you may become a bottleneck in the development effort. If that someone
> is the owner of YOUR, then everyone can trample your MY:frobnobdicate
> garden. Either way, as team size increases there will be growing pains.
>
> Add to that the misery of the user of these methods having to sort them
> all out and explicitly scope at least part of at least three of them and
> all of at least one of them.
>
> >>> BTW, in Common Lisp, namespaces are not tied to classes at all.
> >> Big mistake.
>
> > Why? I'm curious.
>
> Encapsulation, among other things I've already explained in previous posts.
You can have encapsulation even if packages are not tied to classes,
since packages have the concept of internal ("private") and external
("public") symbols. Which, due to the generality of symbols,
automatically can make private/public anything - classes, functions,
variables, anything that can be named by a symbol.
> >>> They are their own separate entity, so any effect based on namespaces
> >>> is equally easy
> >> which is to say, about as easy as ascending Everest without any special
> >> equipment or any clothing and living to tell the tale
>
> > Why?
>
> Ditto.
>
> >>> regardless of whether you are talking about new classes,
> >>> new generic functions or new methods for existing generic functions.
> >>>> Adding new verbs which may be used with already-existing nouns is not a
> >>>> problem if namespaces contain verbs, which contain implementations per
> >>>> supported noun. But it is a problem if namespaces contain nouns, which
> >>>> contain implementations per supported verb.
> >>> Right. So here is a class of problem where one particular object system
> >>> gets in your way.
> >> The solution adopted by CLOS apparently being to make an object system
> >> that gets in the way for EVERY class of problem!
>
> > Why?
>
> Ditto.
>
> >> package.class.method (perhaps with inheritance) (Java uses this)
> >> package.method.class
> >> package1.class.package2.method
>
> >> that is, either packages namespace classes which namespace methods (Java
> >> model), packages namespace methods which namespace classes (don't know
> >> what uses this), or packages namespace both methods and classes.
>
> >> You seem to be saying that Lisp does the last of the three.
>
> > No.
>
> Yes.
>
> > In Lisp you have
>
> > package.symbol
>
> > and stop. This means there's no difference between
>
> > package.className and
> > package.genericFunctionName
>
> That's when you're referring to just one of those. I'm discussing the
> commonplace situation when you're referring to one of each. Then you
> need to specify 2 packages. Somehow.
You *need* to specify 2 packages only if you have imported *neither*
symbol in your package, which is quite unusual. Else, you can use
symbols unqualified, and this is the general case.
> >> The problem, partly, is the combinatorical explosion of possible package
> >> pairs in every invocation of a method when there are now two packages
> >> involved in resolving every method invocation instead of one.
>
> >> Regardless, there are no errors in my analysis. Ever.
>
> > Sure
>
> >>> One uniform mechanism that handles both cases with equal ease.
> >> Equality of ease isn't the be all and end all. Making it hard in all
> >> cases is worse than making it easy in some cases and hard in others, as
> >> a general rule.
>
> > Making it easy in all cases is better than making it easy in some
> > cases and hard in others, as a general rule.
>
> If you could actually do that, the above sentence would actually be
> relevant to this discussion.
>
> >>> That is one reason I think the Common Lisp object model is superior.
> >>> Another is multiple-dispatch, but that's a completely different
> >>> discussion.
>
> >> Heartburn macros upset stomach, dispatch tables diarrhea! Yay, Pepto-Bismol!
>
> >>> So if you want to have a
> >>> hierarchy of classes with different methods, you lose the benefits of
> >>> dynamic dispatch and have to manage that yourself. That sounds to me to
> >>> be a bit more tedious and potentially error-prone.
> >> It's going to be no matter what. If you want to add more classes and
> >> more methods both, or more classes with dispatch of a two-argument
> >> method based on the types of both parameters, then no simple inheritance
> >> system is going to work and you'll have to manually specify what to do
> >> for every possible pair ... somehow.
>
> > Or you can define a general case and specialize only the cases that
> > interest you, only for the "pairs" (or tuples) that make sense for the
> > problem at hand.
>
> The (foo foo) (bar bar) syntax does not allow to "define a general
> case", save if all project objects inherit from some class, say Object,
> and you put in a dispatch for (Object Object) (Object Object), and this
> respects inheritance, so any call lacking a more specialized applicable
> dispatch with arguments both inheriting from Object will get that dispatch.
>
> Then the real fun begins: enforcing "NO CLASSES NOT DERIVED FROM
> OBJECT!!" everywhere in the project. Unless CLOS already has an
> omni-superclass like Java's java.lang.Object class.
Guess what? It has, it's the class named T. So I can:
(defmethod do-something (arg1 arg2) ...) ;arg1 arg2 can be of any
class - generic behavior
(defmethod do-something ((arg1 my-class) arg2) ...) ;behavior specific
to my-class
(defmethod do-something ((arg1 subclass-of-my-class) arg2) ...) ;more
specific method
Nobody mentioned method combinations, and I won't now - already too
many things being discussed - but that's another of the big strengths
of CLOS.
> >> When it's one dimensional, you can use inheritance and have each
> >> subclass take care of itself.
>
> >> As soon as it's two-or-more dimensional, you can't. Some of the
> >> information about class X or whatever is going to be scattered about,
> >> and there's going to be something like a switch statement, pointer
> >> array, or other explicit dispatch mechanism in the source code.
>
> > Maybe then it's not information about class X, but about classes X, Y
> > and Z. It is precisely this kind of thing that is easy to express in
> > CLOS
>
> It is easy to express precisely nowhere. CLOS lets you lump everything
> to do with X, Y, and Z together in the same place. So? This might easily
> end up meaning pretty much the whole project. So much for namespaces,
> nevermind encapsulation, which we'd already given up on ages ago.
A fantasy example:
(defgeneric print (object medium))
(defmethod print ((object text) (medium terminal)) ...)
(defmethod print ((object text) (medium laser-printer)) ...)
(defmethod print ((object image) (medium terminal)) ...)
(defmethod print ((object image) (medium laser-printer)) ...)
This is easy to express in CLOS, not that easy to express in Java or C+
+ or Python or any other single-dispatch OO system.
One option is to arbitrarily make one of the two classes "more
important":
interface Printable {
public void printOn(Medium medium);
}
class Text implements Printable {
public void printOn(Medium medium) {
if(medium instanceof Terminal) {
...
} else if(medium instanceof LaserPrinter) {
...
} else {
throw new IllegalArgumentException("Don't know how to print " +
this + " on " + medium);
}
}
}
...same for Image...
Another option is to concentrate the printing code in a third class:
abstract class Printer {
public void print(Printable object, Medium medium) {
if((object instanceof Text) && (medium instanceof Terminal)) {
...
} else ... //you get the idea
}
}
Neither option is good imho, since both force you to explicitly code
dispatch tables and manually maintain them - exactly what you DON'T
have to do with CLOS.
> >> Lisp just sticks you with this by default instead of letting the cases
> >> that CAN be easy actually BE easy.
>
> >>>> The Lisp way around would present problems.
> >>> And yet, oddly enough, in practice there don't seem to be any. It works
> >>> just fine.
> >> So you claim. Color me skeptical.
>
> > What reason on Earth would Thomas have to say it works fine if it
> > didn't?
>
> I do not know, though strongly suspect "appearing to be the victor of a
> particular Usenet pissing match" to be among his motives. Nonetheless,
> what he claimed flies in the face of logic.
>
> > But if you confuse your personal preference with objective
> > truth, and write that "truth" in public, I - we - feel the need to
> > correct your claims.
>
> That statement makes several insulting and false insinuations about me.
I'm sorry, but I genuinely think you are in error, else I wouldn't
write here. The same is true for you wrt. me, I suppose.
> >> Adding a method to a class is changing the class, right?
> >> Lisp methods live in generic functions instead of classes, right?
> >> Ergo adding a method to a genetic function changes the generic function.
>
> > Yes
>
> I'm glad that particular dispute is finally settled.
>
> >> (Subclassing a class doesn't change the base class. But subclassing a
> >> class creates a new class that has its own name and is in its own
> >> package. Adding a method to a generic function does not create a new
> >> generic function that has its own name and is in its own package. It
> >> adds to the existing generic function instead, thus changing it.)
>
> > Subclassing a class DOES change the class, if you intend "class" as
> > the set of all possible instances of that type.
>
> Sophistry. It doesn't change the base class itself, and indeed, code
> that uses the base class won't be affected unless someone passes it a
> reference to a derived-class instance.
Then, it changes the class, since you get different results while
still using the same class.
> Since there aren't separate "base" and "derived" generic functions in
> Lisp, however, the above does not apply there, and the "base itself" IS
> changed.
>
> Uh-oh.
*in this context*, the following analogy more or less holds:
generic function --> abstract class
method --> concrete class
more specific method --> concrete subclass
The generic function is not changed any more than the abstract class
is.
> >>> And there is absolutely no reason that the code for your new class has
> >>> to be scattered anywhere. You can, if the organization makes the most
> >>> sense for your application, put the method definitions IN THE SAME FILE
> >>> as the class definition. If it makes more sense to organize around the
> >>> generic function instead, then you can. Or you can even mix it.
> >> Your coworkers are going to have SO much fun trying to guess where you
> >> put everything.
>
> > Not if you follow some convention in your team.
>
> Given all the places things can be squirreled away, a) defining such a
> convention to be both complete and consistent will be non-trivial and b)
> so will enforcing it.
>
> In fact, the potential complexity of the system you've described may
> suffice to invoke the incompleteness theorem, ensuring that NO
> convention could EVER be devised to be both complete and consistent.
>
> > This is not specific
> > to Lisp, conventions are needed in every language that allows more
> > than one way to do the same thing (IMHO, every serious language).
>
> But the more ways there are to do a thing, the worse it gets; indeed,
> you can easily get a combinatorial explosion like the one that nuked
> perl as a viable language for large-scale development efforts.
That's subjective, and I won't debate it here. I prefer the there's-
more-than-one-way-to-do-it philosophy, but it's just personal
preference.
> >>> Simply a misunderstanding of how Common Lisp programs are organized.
> >> I have misunderstood nothing. According to you, Common Lisp programs are
> >> organized at the whims of individual programmers. Not conducive to
> >> scaling up to a large development team, mind you.
>
> > Only if you let individual programmers do it at their whim. Just as if
> > there wasn't no convention among Java programmers in a team on how to
> > name packages, for example.
>
> Java needs relatively few conventions BESIDES how to name packages. Lisp
> will need a convention the documentation of which would consume 74,172
> trees (plus or minus five) to print and massing 11.3 tons. Looking up
> anything in the convention will take 1 month, 17 days, 3 hours and 11
> minutes, plus or minus one, assuming it's found on average halfway
> through. The one upside is that it will make one hell of a paperweight
> or doorstop.
Interesting, and which studies back up your precise data?
> >>> Well, we think that there is a fundamental difference between different
> >>> sorts of close and prefer to make sure they have different names.
> >> So instead of everything you can "close" having a "close" method, you
> >> end up "close"ing one type, "shut"ting another, "slam"ming a third,
> >> "plug"ging a fourth, and onward to increasingly unintuitive and
> >> unguessable names? Wow, that must REALLY help code readability.
>
> > No.
>
> Yes. Thomas said you'd not use "close" for everything that closes, which
> means Fun With Your Thesaurus time folks!
>
> > streams:close(file-stream)
>
> This vs. Java's fileStream.close(). And you guys said *Java* is bloated
> and looks like vomit?!
I personally don't think Java the language + standard library is
generally bloated. I believe some widely-adopted practices, and some
widely-used libraries, do favor bloat in Java.
I also don't think Java looks like vomit, if you don't make it look
like that. Though I do think that expressing some things in Java is
not as easy as in Lisp.
For what I know, both Java and Common Lisp have been accused of being
"bloated" for a period of their respective history.
I can only say - only personal experience, no scientific data - that
writing both Java and Common Lisp, I generally find Common Lisp more
expressive and more readable, even if I have much more experience in
Java than in Lisp. This might simply mean Lisp is more close than Java
to my own way of thinking.
Alessio Stalla wrote:
> On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>> > What if the package system scoped generic "names", and those "names"
>> > could be used to refer to verbs, nouns, pronouns, etc. etc.?
>>
>> That would be even worse: not only would methods and classes both have
>> to be scoped, so thing.method() would have to have two scopes decided
>> somehow (and the type of "thing" cannot be a factor in compile-time name
>> resolution, since as far as the compiler is concerned it could be
>> anything), but method names and class names could now collide with one
>> another, and possibly with other things too!
>
> They don't
Sure they do. Either two identical names collide, or they reside in
distinct namespaces. You just insinuated that methods and classes do not
reside in distinct namespaces (quoted material, very top of this post).
Therefore if one of each with the same name resides in a single one,
they collide. It's elementary logic, Alessio.
>> At first this might not seem so bad, since nouns and verbs are mostly
>> nonoverlapping sets. But some common cases are exceptions: a jump vs. to
>> jump, for example.
>>
>> There has been some example code and other text that collectively
>> implied that Lisp identifiers are not case-sensitive, which means that
>> using a Java-esque convention of Jump for the noun and jump for the verb
>> would not avoid a collision.
>>
>> Worse, this also means JUMP for a global constant will collide with both.
>>
>> What a mess!
>>
>>> the method MY:frobnodicate(MY:quux) is different from
>>> the method MY:frobnodicate(YOUR:quux) which is different from
>>> the method YOUR:frobnodicate(MY:quux) which is different from
>>> the method YOUR:frobnodicate(YOUR:quux)
>> The methods, yes. It's the little bit of code containing the dispatch
>> table that concerns me.
>
>> Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobdicate, for example.
>
> Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which may
> or may not make sense depending on what MY:frobnobdicate and YOUR:quux
> mean.
In your example, though, this combination was used, along with all three
other combinations of whose frobnobdicate and whose quux.
> it probably does not make much sense to do
>
> (defmethod db-library:open-transaction ((transaction-manager picture-
> library:jpeg-picture)) ...whatever...)
I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>> If that someone is you, then
>> you may become a bottleneck in the development effort. If that someone
>> is the owner of YOUR, then everyone can trample your MY:frobnobdicate
>> garden. Either way, as team size increases there will be growing pains.
>>
>> Add to that the misery of the user of these methods having to sort them
>> all out and explicitly scope at least part of at least three of them and
>> all of at least one of them.
>>
>>>>> BTW, in Common Lisp, namespaces are not tied to classes at all.
>>>> Big mistake.
>>> Why? I'm curious.
>> Encapsulation, among other things I've already explained in previous posts.
>
> You can have encapsulation even if packages are not tied to classes,
> since packages have the concept of internal ("private") and external
> ("public") symbols.
You can have THAT level of encapsulation in C, FFS. (Using or
withholding "extern" and with judicious omissions from the .h file.)
> Which, due to the generality of symbols,
> automatically can make private/public anything - classes, functions,
> variables, anything that can be named by a symbol.
But only at the granularity of whole packages. Not single classes or
smaller scales, aside from what Series elsewhere described as the
"natural encapsulation" of functions whereby ordinarily changes to the
function's body that don't change its signature or semantics don't break
code elsewhere in the program.
>>> In Lisp you have
>>> package.symbol
>>> and stop. This means there's no difference between
>>> package.className and
>>> package.genericFunctionName
>> That's when you're referring to just one of those. I'm discussing the
>> commonplace situation when you're referring to one of each. Then you
>> need to specify 2 packages. Somehow.
>
> You *need* to specify 2 packages only if you have imported *neither*
> symbol in your package, which is quite unusual. Else, you can use
> symbols unqualified, and this is the general case.
Verb collisions are the issue. So many things will have close methods,
for example. If you use several of them in one area, you'll only be able
to import one and you'll have to FQ the others. Unless of course the
library designer did as someone else recently suggested here and cracked
open his thesaurus. (Yuk.)
This is the flipside to the many-times-more-nouns-than-verbs thing. A
lot of verb collisions occur among a small set of especially
frequently-used verbs. The power-law scaling of word frequencies serves
to amplify the difference of nearly an order of magnitude in the numbers
of nouns vs. verbs.
>>> Or you can define a general case and specialize only the cases that
>>> interest you, only for the "pairs" (or tuples) that make sense for the
>>> problem at hand.
>> The (foo foo) (bar bar) syntax does not allow to "define a general
>> case", save if all project objects inherit from some class, say Object,
>> and you put in a dispatch for (Object Object) (Object Object), and this
>> respects inheritance, so any call lacking a more specialized applicable
>> dispatch with arguments both inheriting from Object will get that dispatch.
>>
>> Then the real fun begins: enforcing "NO CLASSES NOT DERIVED FROM
>> OBJECT!!" everywhere in the project. Unless CLOS already has an
>> omni-superclass like Java's java.lang.Object class.
>
> Guess what? It has, it's the class named T.
They have a problem with code readability or something? That reads like
true, a temporary, or, worst, a generic type parameter, not a class name.
> Nobody mentioned method combinations, and I won't now - already too
> many things being discussed - but that's another of the big strengths
> of CLOS.
I'll interpret this as "another of the big headaches of CLOS". It sounds
like one of the biggest headaches of Lisp is the sheer amount of stuff,
special forms, &c. that you'd have to learn to be able to read other
peoples' code written in the stuff. OK, perl is much worse, but still.
>>> Maybe then it's not information about class X, but about classes X, Y
>>> and Z. It is precisely this kind of thing that is easy to express in
>>> CLOS
>> It is easy to express precisely nowhere. CLOS lets you lump everything
>> to do with X, Y, and Z together in the same place. So? This might easily
>> end up meaning pretty much the whole project. So much for namespaces,
>> nevermind encapsulation, which we'd already given up on ages ago.
>
> A fantasy example:
>
> (defgeneric print (object medium))
>
> (defmethod print ((object text) (medium terminal)) ...)
> (defmethod print ((object text) (medium laser-printer)) ...)
>
> (defmethod print ((object image) (medium terminal)) ...)
> (defmethod print ((object image) (medium laser-printer)) ...)
>
> This is easy to express in CLOS, not that easy to express in Java or C+
> + or Python or any other single-dispatch OO system.
Eh, Java has already expressed this and very easily. Look at the Java2D
API. Corresponding to "text" and "image" we have Shape and subclasses,
which can draw themselves onto a Graphics2D (polymorphically). And
Graphics2D is gotten by various means, but is itself a polymorphic class
that knows how to turn turtle-graphics commands using the generic
Graphics2D interface into results on particular media. If you're
prepping a print job you'll draw on one subclass of Graphics2D, if on a
window you'll get another. No terminals though, Java2D is all about
bitmapped graphics.
For your example a Java programmer might make a Printable interface with
a printOn(Medium) method specified. Implementations would call Medium
methods such as outputString(String), toggleBold(), or whatever was
supported. VT100Terminal would send appropriate escape sequences for
things like toggleBold() and the string for outputString(String) to
System.out. LaserPrinter would send suitable printer control commands to
the parallel port.
Then you could have aText.printOn(aVT100), etc.
I don't know what you were hoping to do with images there; error when
the target was a terminal and print on a printer? That might require
Java2D and adding a getGraphics() to Medium, returning null for
VT100Terminal -- an OOB not-available value printOn would check for.
Image might attempt to gracefully degrade showing a Lynx-style "[IMAGE]"
or attempting to cruft up an ASCII-art approximation using some
algorithm or another, or just complain with an exception. Alternatively,
Medium could throw a GraphicsUnsupportedException or similar from
getGraphics() instead of returning null if the target didn't support
graphics.
All of this with single dispatch.
Where I find myself most wanting double dispatch is when there's two
type hierarchies that need some combined operations, but there's no
natural way to orthogonalize the operations. With most forms of drawing
or printing, though, you can turn the document into a series of
primitive operations of some kind at the document end, and implement the
primitive operations on the medium end. The Graphics2D class is a good
one to check out as its API contains such a set of primitive operations.
http://java.sun.com/javase/6/docs/api/java/awt/Graphics2D.html
A lot of the methods are inherited from
http://java.sun.com/javase/6/docs/api/java/awt/Graphics.html
> One option is to arbitrarily make one of the two classes "more
> important":
>
> interface Printable {
> public void printOn(Medium medium);
> }
>
> class Text implements Printable {
> public void printOn(Medium medium) {
> if(medium instanceof Terminal) {
> ...
> } else if(medium instanceof LaserPrinter) {
> ...
> } else {
> throw new IllegalArgumentException("Don't know how to print " +
> this + " on " + medium);
> }
> }
> }
>
> ...same for Image...
Bletcherous. See above for the alternative that avoids switch, enum,
instanceof, or any other similar kludge.
> Another option is to concentrate the printing code in a third class:
>
> abstract class Printer {
>
> public void print(Printable object, Medium medium) {
> if((object instanceof Text) && (medium instanceof Terminal)) {
> ...
> } else ... //you get the idea
> }
>
> }
>
> Neither option is good imho, since both force you to explicitly code
> dispatch tables and manually maintain them - exactly what you DON'T
> have to do with CLOS.
Except that a) I just showed how to avoid doing so -- in this case at
least -- in Java, and b) Anonymous C Lisper does exactly that with CLOS
to judge by his one major post containing sample Lisp code.
>>> But if you confuse your personal preference with objective
>>> truth, and write that "truth" in public, I - we - feel the need to
>>> correct your claims.
>> That statement makes several insulting and false insinuations about me.
>
> I'm sorry, but I genuinely think [repeats insults]
Think what you want, but please restrain the urge to blurt out uncivil
things in public. Weren't you taught any manners as a child?
>>>> (Subclassing a class doesn't change the base class. But subclassing a
>>>> class creates a new class that has its own name and is in its own
>>>> package. Adding a method to a generic function does not create a new
>>>> generic function that has its own name and is in its own package. It
>>>> adds to the existing generic function instead, thus changing it.)
>>> Subclassing a class DOES change the class, if you intend "class" as
>>> the set of all possible instances of that type.
>> Sophistry. It doesn't change the base class itself, and indeed, code
>> that uses the base class won't be affected unless someone passes it a
>> reference to a derived-class instance.
>
> Then, it changes the class
It does not.
>> Since there aren't separate "base" and "derived" generic functions in
>> Lisp, however, the above does not apply there, and the "base itself" IS
>> changed.
>>
>> Uh-oh.
>
> *in this context*, the following analogy more or less holds:
>
> generic function --> abstract class
> method --> concrete class
> more specific method --> concrete subclass
Except when you subclass a class, you're making an altered copy in
essence; when you add to a generic method, you're fiddling with the
original, not a copy, and maybe it wasn't "yours".
See above re: MY:frobnobdicate with YOUR:quux.
> The generic function is not changed any more than the abstract class
> is.
Sure it is. The abstract class still contains exactly the same methods.
The generic function contains new ones. Viewing both as lists, one grew
and one didn't.
>>> This is not specific
>>> to Lisp, conventions are needed in every language that allows more
>>> than one way to do the same thing (IMHO, every serious language).
>> But the more ways there are to do a thing, the worse it gets; indeed,
>> you can easily get a combinatorial explosion like the one that nuked
>> perl as a viable language for large-scale development efforts.
>
> That's subjective, and I won't debate it here. I prefer the there's-
> more-than-one-way-to-do-it philosophy, but it's just personal
> preference.
It's a preference that suggests you tend to work alone or on a small
team. Working on a large team results in there's-too-many-ways-to-do-it
being a very real possibility, with everyone doing the same "it"
differently and everyone having to know every single language feature,
however obscure.
Without the javadocs Java's standard library might plausibly have caused
some trouble of a similar nature by its sheer size. It helps though that
there's generally only one or a few clearly-near-optimum use patterns
for a given job, and that everything (mostly) has descriptive names too.
ListIterator and MessageDigest are names that convey quite a bit about
what they do; defgeneric and #:cl #:foo somewhat less so. :)
>>>> I have misunderstood nothing. According to you, Common Lisp programs are
>>>> organized at the whims of individual programmers. Not conducive to
>>>> scaling up to a large development team, mind you.
>>> Only if you let individual programmers do it at their whim. Just as if
>>> there wasn't no convention among Java programmers in a team on how to
>>> name packages, for example.
>> Java needs relatively few conventions BESIDES how to name packages. Lisp
>> will need a convention the documentation of which would consume 74,172
>> trees (plus or minus five) to print and massing 11.3 tons. Looking up
>> anything in the convention will take 1 month, 17 days, 3 hours and 11
>> minutes, plus or minus one, assuming it's found on average halfway
>> through. The one upside is that it will make one hell of a paperweight
>> or doorstop.
>
> Interesting
>
>>>>> Well, we think that there is a fundamental difference between different
>>>>> sorts of close and prefer to make sure they have different names.
>>>> So instead of everything you can "close" having a "close" method, you
>>>> end up "close"ing one type, "shut"ting another, "slam"ming a third,
>>>> "plug"ging a fourth, and onward to increasingly unintuitive and
>>>> unguessable names? Wow, that must REALLY help code readability.
>>> No.
>> Yes. Thomas said you'd not use "close" for everything that closes, which
>> means Fun With Your Thesaurus time folks!
Which topic came up again; see above.
>>> streams:close(file-stream)
>> This vs. Java's fileStream.close(). And you guys said *Java* is bloated
>> and looks like vomit?!
>
> I personally don't think Java the language + standard library is
> generally bloated. I believe some widely-adopted practices, and some
> widely-used libraries, do favor bloat in Java.
I'd agree with that assessment. But I didn't say *you specifically* said
Java code looked like vomit. Certainly *one* of you did, though, a few
days ago, and others appeared to hold comparable opinions.
> I also don't think Java looks like vomit, if you don't make it look
> like that. Though I do think that expressing some things in Java is
> not as easy as in Lisp.
Including especially the things that will fry your coworkers' brains, no
doubt. (Though you can be pretty evil with the reflection API, static
initializers and constructors with side effects, asserts with side
effects, ClassLoader tricks, and so forth.)
> For what I know, both Java and Common Lisp have been accused of being
> "bloated" for a period of their respective history.
Java's library and Common Lisp's object system, I'll bet. But users
don't have to learn the whole library and do have to learn the whole
object system...
> I can only say - only personal experience, no scientific data - that
> writing both Java and Common Lisp, I generally find Common Lisp more
> expressive and more readable, even if I have much more experience in
> Java than in Lisp. This might simply mean Lisp is more close than Java
> to my own way of thinking.
Subjective statements like that cannot resolve many of the questions
here; at worst they might fan the flames, though maybe with "Lew"
apparently bowing out of it the worst of those are over.
I actually don't think most people here disagree with my main thesis,
which is that Java and Lisp have relative tradeoffs, with neither
invariably superior to the other. The sticking points all seem to
involve specific things claimed to make Lisp superior at one time or
another by only a handful of the most extreme pro-Lisp partisans, and
why these features don't *actually* do so.
On May 20, 10:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Alessio Stalla wrote:
> >> > What if the package system scoped generic "names", and those "names"
> >> > could be used to refer to verbs, nouns, pronouns, etc. etc.?
>
> >> That would be even worse: not only would methods and classes both have
> >> to be scoped, so thing.method() would have to have two scopes decided
> >> somehow (and the type of "thing" cannot be a factor in compile-time name
> >> resolution, since as far as the compiler is concerned it could be
> >> anything), but method names and class names could now collide with one
> >> another, and possibly with other things too!
>
> > They don't
>
> Sure they do. Either two identical names collide, or they reside in
> distinct namespaces. You just insinuated that methods and classes do not
> reside in distinct namespaces (quoted material, very top of this post).
> Therefore if one of each with the same name resides in a single one,
> they collide. It's elementary logic, Alessio.
>
Do a field named foo and a method named foo in the same class collide
in Java? No.
Are they in the same namespace? Yes, because a class creates a
namespace in Java.
What happens is that, while foo is always the same symbol
(com.package.Class.foo), the compiler knows where it names a variable
and where it names a method, and those are two distinct cases, so no
collision ever appears. Lisp works just the same, only the namespace
is not created by a class but by an ad-hoc object, a package. So for
example you can have the symbol foo in package p, which happens to
name a variable and a function, and symbol foo in package q, which is
another symbol, and names a variable and a class.
>
> >> At first this might not seem so bad, since nouns and verbs are mostly
> >> nonoverlapping sets. But some common cases are exceptions: a jump vs. to
> >> jump, for example.
>
> >> There has been some example code and other text that collectively
> >> implied that Lisp identifiers are not case-sensitive, which means that
> >> using a Java-esque convention of Jump for the noun and jump for the verb
> >> would not avoid a collision.
>
> >> Worse, this also means JUMP for a global constant will collide with both.
>
> >> What a mess!
>
> >>> the method MY:frobnodicate(MY:quux) is different from
> >>> the method MY:frobnodicate(YOUR:quux) which is different from
> >>> the method YOUR:frobnodicate(MY:quux) which is different from
> >>> the method YOUR:frobnodicate(YOUR:quux)
> >> The methods, yes. It's the little bit of code containing the dispatch
> >> table that concerns me.
>
> >> Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobdicate, for example.
>
> > Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which may
> > or may not make sense depending on what MY:frobnobdicate and YOUR:quux
> > mean.
>
> In your example, though, this combination was used, along with all three
> other combinations of whose frobnobdicate and whose quux.
My example was meant to show all the possible combinations, not
suggest they usually are all used.
> > it probably does not make much sense to do
>
> > (defmethod db-library:open-transaction ((transaction-manager picture-
> > library:jpeg-picture)) ...whatever...)
>
> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>
See the parameter name - it's transaction-manager. A jpeg picture is
not a transaction manager, so this fictional method does not make much
sense.
>
> >> If that someone is you, then
> >> you may become a bottleneck in the development effort. If that someone
> >> is the owner of YOUR, then everyone can trample your MY:frobnobdicate
> >> garden. Either way, as team size increases there will be growing pains.
>
> >> Add to that the misery of the user of these methods having to sort them
> >> all out and explicitly scope at least part of at least three of them and
> >> all of at least one of them.
>
> >>>>> BTW, in Common Lisp, namespaces are not tied to classes at all.
> >>>> Big mistake.
> >>> Why? I'm curious.
> >> Encapsulation, among other things I've already explained in previous posts.
>
> > You can have encapsulation even if packages are not tied to classes,
> > since packages have the concept of internal ("private") and external
> > ("public") symbols.
>
> You can have THAT level of encapsulation in C, FFS. (Using or
> withholding "extern" and with judicious omissions from the .h file.)
I don't know C enough to comment on this.
> > Which, due to the generality of symbols,
> > automatically can make private/public anything - classes, functions,
> > variables, anything that can be named by a symbol.
>
> But only at the granularity of whole packages. Not single classes or
> smaller scales, aside from what Series elsewhere described as the
> "natural encapsulation" of functions whereby ordinarily changes to the
> function's body that don't change its signature or semantics don't break
> code elsewhere in the program.
The "natural encapsulation" is only natural in Java, C++ and languages
with a similar kind of OO. It's not the only possibility. In Lisp, the
natural encapsulation is at the package level; in another language, it
might be at the module level; and these are certainly not all the
possibilities. Each has its pros and cons. I find the Lisp one
convenient *in Lisp* because Lisp has first-class symbols. In Java the
same thing would be messier - it's more natural in Java that classes
create namespaces.
> >>> In Lisp you have
> >>> package.symbol
> >>> and stop. This means there's no difference between
> >>> package.className and
> >>> package.genericFunctionName
> >> That's when you're referring to just one of those. I'm discussing the
> >> commonplace situation when you're referring to one of each. Then you
> >> need to specify 2 packages. Somehow.
>
> > You *need* to specify 2 packages only if you have imported *neither*
> > symbol in your package, which is quite unusual. Else, you can use
> > symbols unqualified, and this is the general case.
>
> Verb collisions are the issue. So many things will have close methods,
> for example. If you use several of them in one area, you'll only be able
> to import one and you'll have to FQ the others. Unless of course the
> library designer did as someone else recently suggested here and cracked
> open his thesaurus. (Yuk.)
Sure, this is a possible problem. I know you probably won't believe
me, but it does not happen frequently; no more than it happens in Java
with two classes of the same name.
> This is the flipside to the many-times-more-nouns-than-verbs thing. A
> lot of verb collisions occur among a small set of especially
> frequently-used verbs. The power-law scaling of word frequencies serves
> to amplify the difference of nearly an order of magnitude in the numbers
> of nouns vs. verbs.
>
> >>> Or you can define a general case and specialize only the cases that
> >>> interest you, only for the "pairs" (or tuples) that make sense for the
> >>> problem at hand.
> >> The (foo foo) (bar bar) syntax does not allow to "define a general
> >> case", save if all project objects inherit from some class, say Object,
> >> and you put in a dispatch for (Object Object) (Object Object), and this
> >> respects inheritance, so any call lacking a more specialized applicable
> >> dispatch with arguments both inheriting from Object will get that dispatch.
>
> >> Then the real fun begins: enforcing "NO CLASSES NOT DERIVED FROM
> >> OBJECT!!" everywhere in the project. Unless CLOS already has an
> >> omni-superclass like Java's java.lang.Object class.
>
> > Guess what? It has, it's the class named T.
>
> They have a problem with code readability or something? That reads like
> true, a temporary, or, worst, a generic type parameter, not a class name.
T is the canonical way to represent true. Historically it has also
been used to designate the root of the type hierarchy - the type of
all objects - and naturally it has been used to designate the root of
the class hierarchy, too. Don't ask me why. Surely it does no harm :)
> > Nobody mentioned method combinations, and I won't now - already too
> > many things being discussed - but that's another of the big strengths
> > of CLOS.
>
> I'll interpret this as "another of the big headaches of CLOS". It sounds
> like one of the biggest headaches of Lisp is the sheer amount of stuff,
> special forms, &c. that you'd have to learn to be able to read other
> peoples' code written in the stuff. OK, perl is much worse, but still.
>
No comment.
>
> >>> Maybe then it's not information about class X, but about classes X, Y
> >>> and Z. It is precisely this kind of thing that is easy to express in
> >>> CLOS
> >> It is easy to express precisely nowhere. CLOS lets you lump everything
> >> to do with X, Y, and Z together in the same place. So? This might easily
> >> end up meaning pretty much the whole project. So much for namespaces,
> >> nevermind encapsulation, which we'd already given up on ages ago.
>
> > A fantasy example:
>
> > (defgeneric print (object medium))
>
> > (defmethod print ((object text) (medium terminal)) ...)
> > (defmethod print ((object text) (medium laser-printer)) ...)
>
> > (defmethod print ((object image) (medium terminal)) ...)
> > (defmethod print ((object image) (medium laser-printer)) ...)
>
> > This is easy to express in CLOS, not that easy to express in Java or C+
> > + or Python or any other single-dispatch OO system.
>
> Eh, Java has already expressed this and very easily. Look at the Java2D
> API. Corresponding to "text" and "image" we have Shape and subclasses,
> which can draw themselves onto a Graphics2D (polymorphically). And
> Graphics2D is gotten by various means, but is itself a polymorphic class
> that knows how to turn turtle-graphics commands using the generic
> Graphics2D interface into results on particular media. If you're
> prepping a print job you'll draw on one subclass of Graphics2D, if on a
> window you'll get another. No terminals though, Java2D is all about
> bitmapped graphics.
>
> For your example a Java programmer might make a Printable interface with
> a printOn(Medium) method specified. Implementations would call Medium
> methods such as outputString(String), toggleBold(), or whatever was
> supported. VT100Terminal would send appropriate escape sequences for
> things like toggleBold() and the string for outputString(String) to
> System.out. LaserPrinter would send suitable printer control commands to
> the parallel port.
>
> Then you could have aText.printOn(aVT100), etc.
>
> I don't know what you were hoping to do with images there; error when
> the target was a terminal and print on a printer? That might require
> Java2D and adding a getGraphics() to Medium, returning null for
> VT100Terminal -- an OOB not-available value printOn would check for.
> Image might attempt to gracefully degrade showing a Lynx-style "[IMAGE]"
> or attempting to cruft up an ASCII-art approximation using some
> algorithm or another, or just complain with an exception. Alternatively,
> Medium could throw a GraphicsUnsupportedException or similar from
> getGraphics() instead of returning null if the target didn't support
> graphics.
>
> All of this with single dispatch.
>
> Where I find myself most wanting double dispatch is when there's two
> type hierarchies that need some combined operations, but there's no
> natural way to orthogonalize the operations. With most forms of drawing
> or printing, though, you can turn the document into a series of
> primitive operations of some kind at the document end, and implement the
> primitive operations on the medium end. The Graphics2D class is a good
> one to check out as its API contains such a set of primitive operations.
>
> http://java.sun.com/javase/6/docs/api/java/awt/Graphics2D.html
>
> A lot of the methods are inherited from
>
> http://java.sun.com/javase/6/docs/api/java/awt/Graphics.html
Heh, Graphics2D is really an example of what I was saying :) it has
drawPolygon, drawOval, drawText, and a few other drawSomething. What
if I wanted it to draw the cool chart generated by my favourite
library? I'd have to transform the Chart in an Image first, or write a
drawChart(Chart, Graphics2D) utility method somewhere and use the
drawXXX primitives there. In CLOS, I would simply define a new method
specialized on Chart and Graphics2D, and it would be indistinguishable
from built-in methods that deal with polygons, text, and images.
> > One option is to arbitrarily make one of the two classes "more
> > important":
>
> > interface Printable {
> > public void printOn(Medium medium);
> > }
>
> > class Text implements Printable {
> > public void printOn(Medium medium) {
> > if(medium instanceof Terminal) {
> > ...
> > } else if(medium instanceof LaserPrinter) {
> > ...
> > } else {
> > throw new IllegalArgumentException("Don't know how to print " +
> > this + " on " + medium);
> > }
> > }
> > }
>
> > ...same for Image...
>
> Bletcherous. See above for the alternative that avoids switch, enum,
> instanceof, or any other similar kludge.
>
> > Another option is to concentrate the printing code in a third class:
>
> > abstract class Printer {
>
> > public void print(Printable object, Medium medium) {
> > if((object instanceof Text) && (medium instanceof Terminal)) {
> > ...
> > } else ... //you get the idea
> > }
>
> > }
>
> > Neither option is good imho, since both force you to explicitly code
> > dispatch tables and manually maintain them - exactly what you DON'T
> > have to do with CLOS.
>
> Except that a) I just showed how to avoid doing so -- in this case at
> least -- in Java, and b) Anonymous C Lisper does exactly that with CLOS
> to judge by his one major post containing sample Lisp code.
>
> >>> But if you confuse your personal preference with objective
> >>> truth, and write that "truth" in public, I - we - feel the need to
> >>> correct your claims.
> >> That statement makes several insulting and false insinuations about me.
>
> > I'm sorry, but I genuinely think [repeats insults]
>
> Think what you want, but please restrain the urge to blurt out uncivil
> things in public. Weren't you taught any manners as a child?
I don't think saying someone is in error about something is insulting
him.
> >>>> (Subclassing a class doesn't change the base class. But subclassing a
> >>>> class creates a new class that has its own name and is in its own
> >>>> package. Adding a method to a generic function does not create a new
> >>>> generic function that has its own name and is in its own package. It
> >>>> adds to the existing generic function instead, thus changing it.)
> >>> Subclassing a class DOES change the class, if you intend "class" as
> >>> the set of all possible instances of that type.
> >> Sophistry. It doesn't change the base class itself, and indeed, code
> >> that uses the base class won't be affected unless someone passes it a
> >> reference to a derived-class instance.
>
> > Then, it changes the class
>
> It does not.
>
> >> Since there aren't separate "base" and "derived" generic functions in
> >> Lisp, however, the above does not apply there, and the "base itself" IS
> >> changed.
>
> >> Uh-oh.
>
> > *in this context*, the following analogy more or less holds:
>
> > generic function --> abstract class
> > method --> concrete class
> > more specific method --> concrete subclass
>
> Except when you subclass a class, you're making an altered copy in
> essence; when you add to a generic method, you're fiddling with the
> original, not a copy, and maybe it wasn't "yours".
>
> See above re: MY:frobnobdicate with YOUR:quux.
If I write MY:frobnobdicate specialized on YOUR:quux, I'm not altering
the behavior of MY:frobnobdicate specialized on other objects. I'm
adding a possibility, not changing behavior. If you call
MY:frobnobdicate with MY:quux, the behavior is the same whether I have
defined the YOUR:quux version or not. Although methods are registered
in a "global" place - their generic function - each method is a thing
of its own, much like a derived class is distinct from its base class.
In pseudo-Java:
public abstract class MyGenericFunction<T1, ..., Tn> {
public abstract Object call(T1 arg1, ..., Tn argn);
}
public class MyMethod1 extends MyGenericFunction<my.Foo, ..., my.Bar>
{
public Object call(my.Foo arg1, ..., my.Bar argn) {
...
}
}
public class MyMethod2 extends MyGenericFunction<your.Foo, ...,
your.Bar> {
public Object call(your.Foo arg1, ..., your.Bar argn) {
...
}
}
If I add MyMethod3, the behavior of 1 and 2 does not change, yet I can
get different results from an instance of MyGenericFunction (when it
is an instance of MyMethod3).
> > The generic function is not changed any more than the abstract class
> > is.
>
> Sure it is. The abstract class still contains exactly the same methods.
> The generic function contains new ones. Viewing both as lists, one grew
> and one didn't.
Viewing one as a list and the other as a tree (class hierarchy), both
grew.
> >>> This is not specific
> >>> to Lisp, conventions are needed in every language that allows more
> >>> than one way to do the same thing (IMHO, every serious language).
> >> But the more ways there are to do a thing, the worse it gets; indeed,
> >> you can easily get a combinatorial explosion like the one that nuked
> >> perl as a viable language for large-scale development efforts.
>
> > That's subjective, and I won't debate it here. I prefer the there's-
> > more-than-one-way-to-do-it philosophy, but it's just personal
> > preference.
>
> It's a preference that suggests you tend to work alone or on a small
> team. Working on a large team results in there's-too-many-ways-to-do-it
> being a very real possibility, with everyone doing the same "it"
> differently and everyone having to know every single language feature,
> however obscure.
there's-only-one-way-and-it-is-not-optimal is a real possibility, too.
But this is OT.
> Without the javadocs Java's standard library might plausibly have caused
> some trouble of a similar nature by its sheer size. It helps though that
> there's generally only one or a few clearly-near-optimum use patterns
> for a given job, and that everything (mostly) has descriptive names too.
> ListIterator and MessageDigest are names that convey quite a bit about
> what they do; defgeneric and #:cl #:foo somewhat less so. :)
defgeneric DEFines a GENERIC function.
cl is shorthand for common-lisp, and foo... well, it's foo :)
> >>>> I have misunderstood nothing. According to you, Common Lisp programs are
> >>>> organized at the whims of individual programmers. Not conducive to
> >>>> scaling up to a large development team, mind you.
> >>> Only if you let individual programmers do it at their whim. Just as if
> >>> there wasn't no convention among Java programmers in a team on how to
> >>> name packages, for example.
> >> Java needs relatively few conventions BESIDES how to name packages. Lisp
> >> will need a convention the documentation of which would consume 74,172
> >> trees (plus or minus five) to print and massing 11.3 tons. Looking up
> >> anything in the convention will take 1 month, 17 days, 3 hours and 11
> >> minutes, plus or minus one, assuming it's found on average halfway
> >> through. The one upside is that it will make one hell of a paperweight
> >> or doorstop.
>
> > Interesting
>
> >>>>> Well, we think that there is a fundamental difference between different
> >>>>> sorts of close and prefer to make sure they have different names.
> >>>> So instead of everything you can "close" having a "close" method, you
> >>>> end up "close"ing one type, "shut"ting another, "slam"ming a third,
> >>>> "plug"ging a fourth, and onward to increasingly unintuitive and
> >>>> unguessable names? Wow, that must REALLY help code readability.
> >>> No.
> >> Yes. Thomas said you'd not use "close" for everything that closes, which
> >> means Fun With Your Thesaurus time folks!
>
> Which topic came up again; see above.
>
> >>> streams:close(file-stream)
> >> This vs. Java's fileStream.close(). And you guys said *Java* is bloated
> >> and looks like vomit?!
>
> > I personally don't think Java the language + standard library is
> > generally bloated. I believe some widely-adopted practices, and some
> > widely-used libraries, do favor bloat in Java.
>
> I'd agree with that assessment. But I didn't say *you specifically* said
> Java code looked like vomit. Certainly *one* of you did, though, a few
> days ago, and others appeared to hold comparable opinions.
>
> > I also don't think Java looks like vomit, if you don't make it look
> > like that. Though I do think that expressing some things in Java is
> > not as easy as in Lisp.
>
> Including especially the things that will fry your coworkers' brains, no
> doubt. (Though you can be pretty evil with the reflection API, static
> initializers and constructors with side effects, asserts with side
> effects, ClassLoader tricks, and so forth.)
>
> > For what I know, both Java and Common Lisp have been accused of being
> > "bloated" for a period of their respective history.
>
> Java's library and Common Lisp's object system, I'll bet. But users
> don't have to learn the whole library and do have to learn the whole
> object system...
>
> > I can only say - only personal experience, no scientific data - that
> > writing both Java and Common Lisp, I generally find Common Lisp more
> > expressive and more readable, even if I have much more experience in
> > Java than in Lisp. This might simply mean Lisp is more close than Java
> > to my own way of thinking.
>
> Subjective statements like that cannot resolve many of the questions
> here; at worst they might fan the flames, though maybe with "Lew"
> apparently bowing out of it the worst of those are over.
>
> I actually don't think most people here disagree with my main thesis,
> which is that Java and Lisp have relative tradeoffs, with neither
> invariably superior to the other. The sticking points all seem to
> involve specific things claimed to make Lisp superior at one time or
> another by only a handful of the most extreme pro-Lisp partisans, and
> why these features don't *actually* do so.
Mind you, I usually refrain from saying something is absolutely
"superior" because there are really many dimensions to be considered,
but I do think Lisp has some key ideas that are superior to what I
find in other languages. And yes, one of them is macros :)
I also think Java has a lot of nice features which probably many
lispers don't know about. Built-in serialization is one of those, for
example, as is the nice integration of URLs into the language, the
collections framework, ...
Maybe that's the reason I'm using, and sometimes contributing to, a
Lisp implementation running on the JVM... :)
Alessio Stalla wrote:
> On May 20, 10:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Alessio Stalla wrote:
>>>>> What if the package system scoped generic "names", and those "names"
>>>>> could be used to refer to verbs, nouns, pronouns, etc. etc.?
>>>> That would be even worse: not only would methods and classes both have
>>>> to be scoped, so thing.method() would have to have two scopes decided
>>>> somehow (and the type of "thing" cannot be a factor in compile-time name
>>>> resolution, since as far as the compiler is concerned it could be
>>>> anything), but method names and class names could now collide with one
>>>> another, and possibly with other things too!
>>> They don't
>> Sure they do. Either two identical names collide, or they reside in
>> distinct namespaces. You just insinuated that methods and classes do not
>> reside in distinct namespaces (quoted material, very top of this post).
>> Therefore if one of each with the same name resides in a single one,
>> they collide. It's elementary logic, Alessio.
>
> Do a field named foo and a method named foo in the same class collide
> in Java? No.
Because they reside in different namespaces. Java doesn't just consider
them both "symbols" and throw them together into a single namespace;
instead, it creates separate ones within the class for fields and for
methods.
However, an earlier poster said that Common Lisp just considers method
names and the like to be "symbols" and throws them all together into a
single namespace per package.
If that earlier poster was incorrect, take it up with him. Attacking me
for simply quoting him is pointless, rude, and should make you feel
guilty now that you realize the attack was aimed at the wrong target and
you just smacked an innocent bystander for someone else's offense.
>>>>> the method MY:frobnodicate(MY:quux) is different from
>>>>> the method MY:frobnodicate(YOUR:quux) which is different from
>>>>> the method YOUR:frobnodicate(MY:quux) which is different from
>>>>> the method YOUR:frobnodicate(YOUR:quux)
>>>> The methods, yes. It's the little bit of code containing the dispatch
>>>> table that concerns me.
>>>> Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobdicate, for example.
>>> Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which may
>>> or may not make sense depending on what MY:frobnobdicate and YOUR:quux
>>> mean.
>> In your example, though, this combination was used, along with all three
>> other combinations of whose frobnobdicate and whose quux.
>
> My example was meant to show all the possible combinations, not
> suggest they usually are all used.
Well, I was simply considering the possibility that they ARE all used,
and it seems that using two of them causes problems.
>>> it probably does not make much sense to do
>>> (defmethod db-library:open-transaction ((transaction-manager picture-
>>> library:jpeg-picture)) ...whatever...)
>> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>
> See the parameter name - it's transaction-manager.
What parameter name? All I see is a list of arguments. A
transaction-manager and a picture-library might conceivably both be
arguments to the same call.
>>> Which, due to the generality of symbols,
>>> automatically can make private/public anything - classes, functions,
>>> variables, anything that can be named by a symbol.
>> But only at the granularity of whole packages. Not single classes or
>> smaller scales, aside from what Series elsewhere described as the
>> "natural encapsulation" of functions whereby ordinarily changes to the
>> function's body that don't change its signature or semantics don't break
>> code elsewhere in the program.
>
> The "natural encapsulation" is only natural in Java, C++ and languages
> with a similar kind of OO. It's not the only possibility. In Lisp, the
> natural encapsulation is at the package level
My point was that Lisp's encapsulation granularity is much fucking
coarser!! Are you fucking dense?
>>>>> In Lisp you have
>>>>> package.symbol
>>>>> and stop. This means there's no difference between
>>>>> package.className and
>>>>> package.genericFunctionName
>>>> That's when you're referring to just one of those. I'm discussing the
>>>> commonplace situation when you're referring to one of each. Then you
>>>> need to specify 2 packages. Somehow.
>>> You *need* to specify 2 packages only if you have imported *neither*
>>> symbol in your package, which is quite unusual. Else, you can use
>>> symbols unqualified, and this is the general case.
>> Verb collisions are the issue. So many things will have close methods,
>> for example. If you use several of them in one area, you'll only be able
>> to import one and you'll have to FQ the others. Unless of course the
>> library designer did as someone else recently suggested here and cracked
>> open his thesaurus. (Yuk.)
>
> Sure, this is a possible problem.
Thank you for admitting the truth at last.
> I know you probably won't believe me, but it does not happen frequently
Ridiculous.
> no more than it happens in Java with two classes of the same name.
There are only a few class collisions in Java's standard library. I've
mentioned javax.sql.Date and java.util.Date before.
If methods could collide, there'd be 17,392 collisions of them (counting
N of the same name as N^2 collisions; if N-1, it's "only" a couple
thousand; in neither case counting polymorphic overrides as colliding
with the overridden version(s)). The names "close", "dispose", "next",
"readResolve", and "writeExternal" are particular culprits.
Stick THAT in your pipe and smoke it.
>>> Guess what? It has, it's the class named T.
>> They have a problem with code readability or something? That reads like
>> true, a temporary, or, worst, a generic type parameter, not a class name.
>
> T is the canonical way to represent true. Historically it has also
> been used to designate the root of the type hierarchy - the type of
> all objects - and naturally it has been used to designate the root of
> the class hierarchy, too. Don't ask me why. Surely it does no harm :)
This is what lack of a REAL type system gets you: one object doing
triple, quadruple, even quintuple duty. Jack of all trades, master of
none. (This last can also be a criticism of emacs.)
>>> Nobody mentioned method combinations, and I won't now - already too
>>> many things being discussed - but that's another of the big strengths
>>> of CLOS.
>> I'll interpret this as "another of the big headaches of CLOS". It sounds
>> like one of the biggest headaches of Lisp is the sheer amount of stuff,
>> special forms, &c. that you'd have to learn to be able to read other
>> peoples' code written in the stuff. OK, perl is much worse, but still.
>
> No comment.
As damning as when the same line is spoken on TV by a politician. :)
> Heh, Graphics2D is really an example of what I was saying :) it has
> drawPolygon, drawOval, drawText, and a few other drawSomething. What
> if I wanted it to draw the cool chart generated by my favourite
> library?
The chart would be an instance of some class, say Chart, implementing
the other interface, the one with a drawOn(Graphics2D) method specified.
The drawOn() method would call the Graphics2D methods. Code that wanted
to draw a chart on a Graphics2D would call the chart's drawOn() method
with the appropriate parameter. Different chart instances would produce
different drawings.
>>>>> But if you confuse your personal preference with objective
>>>>> truth, and write that "truth" in public, I - we - feel the need to
>>>>> correct your claims.
>>>> That statement makes several insulting and false insinuations about me.
>>> I'm sorry, but I genuinely think [repeats insults]
>> Think what you want, but please restrain the urge to blurt out uncivil
>> things in public. Weren't you taught any manners as a child?
>
> I don't think
That needs rectifying right away, then.
>>>> Since there aren't separate "base" and "derived" generic functions in
>>>> Lisp, however, the above does not apply there, and the "base itself" IS
>>>> changed.
>>>> Uh-oh.
>>> *in this context*, the following analogy more or less holds:
>>> generic function --> abstract class
>>> method --> concrete class
>>> more specific method --> concrete subclass
>> Except when you subclass a class, you're making an altered copy in
>> essence; when you add to a generic method, you're fiddling with the
>> original, not a copy, and maybe it wasn't "yours".
>>
>> See above re: MY:frobnobdicate with YOUR:quux.
>
> If I write MY:frobnobdicate specialized on YOUR:quux, I'm not altering
> the behavior of MY:frobnobdicate specialized on other objects.
Cop-out. Are you or are you not altering MY:frobnobdicate?
> I'm adding a possibility, not changing behavior.
You are changing behavior. Suppose I had code that passed a quux
superclass object around, gotten from somewhere, and called
MY:frobnobdicate on it? Add the quux class and pass one to my code, and
its behavior changes. Not because you subclassed my class to make quux
and put a polymorphic method in YOUR:quux but because you subclassed by
class to make quux and put a polymorphic method in MY:frobnobdicate!
See the difference? In Java you put the method in your own class. In
Lisp you put it in MY generic function. Mine, I tell you, mine!
This seems a minor wart. Until you have experience working in a large
development effort with many many people involved, and this inability to
fence off parts of things goes from wart to colossal headache.
> In pseudo-Java:
[snip]
Poor analogy. Once again, you are subclassing under a new name instead
of changing the original. Because that's what Java does. It supports
exactly the kind of modularization and localization of code changes that
Lisp doesn't.
>>> The generic function is not changed any more than the abstract class
>>> is.
>> Sure it is. The abstract class still contains exactly the same methods.
>> The generic function contains new ones. Viewing both as lists, one grew
>> and one didn't.
>
> Viewing one as a list and the other as a tree (class hierarchy)
A simple strategy: when an apples-to-apples comparison makes your side
look bad, rebut by comparing apples to oranges instead!
>>> That's subjective, and I won't debate it here. I prefer the there's-
>>> more-than-one-way-to-do-it philosophy, but it's just personal
>>> preference.
>> It's a preference that suggests you tend to work alone or on a small
>> team. Working on a large team results in there's-too-many-ways-to-do-it
>> being a very real possibility, with everyone doing the same "it"
>> differently and everyone having to know every single language feature,
>> however obscure.
>
> there's-only-one-way-and-it-is-not-optimal is a real possibility, too.
That's why it's better to find a happy middle:
too few ways too many ways
BASIC FORTRAN Pascal Java C++ Lisp perl
>> Without the javadocs Java's standard library might plausibly have caused
>> some trouble of a similar nature by its sheer size. It helps though that
>> there's generally only one or a few clearly-near-optimum use patterns
>> for a given job, and that everything (mostly) has descriptive names too.
>> ListIterator and MessageDigest are names that convey quite a bit about
>> what they do; defgeneric and #:cl #:foo somewhat less so. :)
>
> defgeneric DEFines a GENERIC function.
> cl is shorthand for common-lisp, and foo... well, it's foo :)
I know this. The point is, the names are less SELF-explanatory. (And you
omitted to state what the #: bit is for the latter.)
>>>>>>> Well, we think that there is a fundamental difference between different
>>>>>>> sorts of close and prefer to make sure they have different names.
>>>>>> So instead of everything you can "close" having a "close" method, you
>>>>>> end up "close"ing one type, "shut"ting another, "slam"ming a third,
>>>>>> "plug"ging a fourth, and onward to increasingly unintuitive and
>>>>>> unguessable names? Wow, that must REALLY help code readability.
>>>>> No.
I had been being sarcastic about code readability.
[quite a lot of untrimmed-but-unused quoted material now trimmed]
>> I actually don't think most people here disagree with my main thesis,
>> which is that Java and Lisp have relative tradeoffs, with neither
>> invariably superior to the other. The sticking points all seem to
>> involve specific things claimed to make Lisp superior at one time or
>> another by only a handful of the most extreme pro-Lisp partisans, and
>> why these features don't *actually* do so.
>
> Mind you, I usually refrain from saying something is absolutely
> "superior" because there are really many dimensions to be considered
Good good.
> but
Ah, there's always a "but", isn't there?
> I do think [subjective opinions and stuff]
Which I'm sure are absolutely fascinating, but which prove nothing in
this debate.
> I also think Java has a lot of nice features which probably many
> lispers don't know about. Built-in serialization is one of those, for
> example, as is the nice integration of URLs into the language, the
> collections framework, ...
The URLs leave a thing or two to be desired. For one thing they're not
integrated, there's just a standard library class for 'em, and OOTB it
only works with HTTP and one or two other things, one their own
Java-specific jar: protocol.
I don't think they should be integrated more than that, mind you, but
there's some warts, like MalformedURLException's handling (and more
generally, illegal argument exceptions should not be checked
exceptions!) and some awkwardness with certain patterns of use. Just
constructing a URL triggers some behavior beyond mere construction,
unlike a File abstract pathname object, which I disagree with.
Constructors that do more than construct are evil.
> Maybe that's the reason I'm using, and sometimes contributing to, a
> Lisp implementation running on the JVM... :)
Clojure?
On May 22, 12:23 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 20, 10:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Alessio Stalla wrote:
> >>> On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Alessio Stalla wrote:
> >>>>> What if the package system scoped generic "names", and those "names"
> >>>>> could be used to refer to verbs, nouns, pronouns, etc. etc.?
> >>>> That would be even worse: not only would methods and classes both have
> >>>> to be scoped, so thing.method() would have to have two scopes decided
> >>>> somehow (and the type of "thing" cannot be a factor in compile-time name
> >>>> resolution, since as far as the compiler is concerned it could be
> >>>> anything), but method names and class names could now collide with one
> >>>> another, and possibly with other things too!
> >>> They don't
> >> Sure they do. Either two identical names collide, or they reside in
> >> distinct namespaces. You just insinuated that methods and classes do not
> >> reside in distinct namespaces (quoted material, very top of this post).
> >> Therefore if one of each with the same name resides in a single one,
> >> they collide. It's elementary logic, Alessio.
>
> > Do a field named foo and a method named foo in the same class collide
> > in Java? No.
>
> Because they reside in different namespaces. Java doesn't just consider
> them both "symbols" and throw them together into a single namespace;
> instead, it creates separate ones within the class for fields and for
> methods.
By saying that, you reveal your ignorance of Common Lisp.
Each symbol could have any number of things associated with it:
- A function OR a special form OR a macro OR a generic fn (and thus,
methods) (when the symbol is used as a function/macro/etc)
- A value (when the symbol is used as a variable)
- A home package
- A name (every symbol has this)
- A plist -- this is more of a dumping-ground for implementation-
dependant stuff
- A type (for example, the symbol FIXNUM has the type information for
the fixnum type associated with it)
>
> However, an earlier poster said that Common Lisp just considers method
> names and the like to be "symbols" and throws them all together into a
> single namespace per package.
>
> If that earlier poster was incorrect, take it up with him. Attacking me
> for simply quoting him is pointless, rude, and should make you feel
> guilty now that you realize the attack was aimed at the wrong target and
> you just smacked an innocent bystander for someone else's offense.
I'm not attacking you, I'm saying that you didn't understand a key
feature of Common Lisp which caused you to misinterpret what Alessio
said. That's a statement of fact.
> >>> it probably does not make much sense to do
> >>> (defmethod db-library:open-transaction ((transaction-manager picture-
> >>> library:jpeg-picture)) ...whatever...)
> >> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>
> > See the parameter name - it's transaction-manager.
>
> What parameter name? All I see is a list of arguments. A
> transaction-manager and a picture-library might conceivably both be
> arguments to the same call.
Where it says transaction-manager in the quoted code is the class
specifier for the argument picture-library.
> >>>>> But if you confuse your personal preference with objective
> >>>>> truth, and write that "truth" in public, I - we - feel the need to
> >>>>> correct your claims.
> >>>> That statement makes several insulting and false insinuations about me.
> >>> I'm sorry, but I genuinely think [repeats insults]
> >> Think what you want, but please restrain the urge to blurt out uncivil
> >> things in public. Weren't you taught any manners as a child?
>
> > I don't think
>
> That needs rectifying right away, then.
You complained earlier about people mincing up your messages before
replying to them. Don't do that to others. Weren't YOU ever taught the
Golden Rule as a child?
> >> Without the javadocs Java's standard library might plausibly have caused
> >> some trouble of a similar nature by its sheer size. It helps though that
> >> there's generally only one or a few clearly-near-optimum use patterns
> >> for a given job, and that everything (mostly) has descriptive names too.
> >> ListIterator and MessageDigest are names that convey quite a bit about
> >> what they do; defgeneric and #:cl #:foo somewhat less so. :)
>
> > defgeneric DEFines a GENERIC function.
> > cl is shorthand for common-lisp, and foo... well, it's foo :)
>
> I know this. The point is, the names are less SELF-explanatory. (And you
> omitted to state what the #: bit is for the latter.)
It's a read-macro -- Common Lisp's equivalent of syntax. Your question
is like asking what the ; is for in "import foo;"
- Adlai
Adlai wrote:
> On May 22, 12:23 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> On May 20, 10:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Alessio Stalla wrote:
>>>>> On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> Alessio Stalla wrote:
>>>>>>> What if the package system scoped generic "names", and those "names"
>>>>>>> could be used to refer to verbs, nouns, pronouns, etc. etc.?
>>>>>> That would be even worse: not only would methods and classes both have
>>>>>> to be scoped, so thing.method() would have to have two scopes decided
>>>>>> somehow (and the type of "thing" cannot be a factor in compile-time name
>>>>>> resolution, since as far as the compiler is concerned it could be
>>>>>> anything), but method names and class names could now collide with one
>>>>>> another, and possibly with other things too!
>>>>> They don't
>>>> Sure they do. Either two identical names collide, or they reside in
>>>> distinct namespaces. You just insinuated that methods and classes do not
>>>> reside in distinct namespaces (quoted material, very top of this post).
>>>> Therefore if one of each with the same name resides in a single one,
>>>> they collide. It's elementary logic, Alessio.
>>> Do a field named foo and a method named foo in the same class collide
>>> in Java? No.
>> Because they reside in different namespaces. Java doesn't just consider
>> them both "symbols" and throw them together into a single namespace;
>> instead, it creates separate ones within the class for fields and for
>> methods.
>
> By saying that, you reveal your ignorance
That's it. I've had enough of being insulted every time I open my mouth.
Fuck you!
The truly egregious thing here is that I quite clearly know a LOT more
about Java than you do, and you even attack me for my statements about Java.
I don't think you're here to debate Lisp anymore. You're here to flame
people and be generally boorish in public. The only question is: why?
It does not matter. I deserve to be treated with a modicum of respect.
People will stop criticizing me and confine their discussions to the
programming languages under discussion here. The subject "Seamus MacRae"
is off-topic. Got it?
>> However, an earlier poster said that Common Lisp just considers method
>> names and the like to be "symbols" and throws them all together into a
>> single namespace per package.
>>
>> If that earlier poster was incorrect, take it up with him. Attacking me
>> for simply quoting him is pointless, rude, and should make you feel
>> guilty now that you realize the attack was aimed at the wrong target and
>> you just smacked an innocent bystander for someone else's offense.
>
> I'm not attacking you
That's a laugh.
> I'm saying that you didn't understand ... caused you to misinterpret ...
> that's a ... fact.
No, it's another pack of vicious lies. What is the MATTER with you? Have
you gone off the deep end? Are you physically incapable of carrying out
a discussion without having to either agree with each other person or
else flame him/her? Does disagreeing *without* acrimony simply not
compute for you, or what?
>>>>> it probably does not make much sense to do
>>>>> (defmethod db-library:open-transaction ((transaction-manager picture-
>>>>> library:jpeg-picture)) ...whatever...)
>>>> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>>> See the parameter name - it's transaction-manager.
>> What parameter name? All I see is a list of arguments. A
>> transaction-manager and a picture-library might conceivably both be
>> arguments to the same call.
>
> Where it says transaction-manager in the quoted code is the class
> specifier for the argument picture-library.
You're not making much sense. I see a method with a list of two
arguments here. Java would have "int foo, float bar" or the like, but
Lisp functions lack argument types so that would just become "foo, bar"
and Lisp list items are space-separated instead of comma-separated so
that would just become "(foo bar)".
>>>>>>> But if you confuse your personal preference with objective
>>>>>>> truth, and write that "truth" in public, I - we - feel the need to
>>>>>>> correct your claims.
>>>>>> That statement makes several insulting and false insinuations about me.
>>>>> I'm sorry, but I genuinely think [repeats insults]
>>>> Think what you want, but please restrain the urge to blurt out uncivil
>>>> things in public. Weren't you taught any manners as a child?
>>> I don't think
>> That needs rectifying right away, then.
>
> You complained earlier about people mincing up your messages before
> replying to them. Don't do that to others. Weren't YOU ever taught the
> Golden Rule as a child?
Yes, but I was also taught game theory, and "tit for tat" tends to be a
winning strategy. You do it to me enough times, I do it once to you as a
little reminder.
Now kindly return to the subject of Java and Lisp and stop discussing me
or your opinions of me in public. It is not on-topic in either
comp.lang.lisp or comp.lang.java.programmer and in fact so far as I am
aware there is no alt.fan.seamus-macrae newsgroup, so it's off-topic
everywhere.
Let it drop.
>>>> Without the javadocs Java's standard library might plausibly have caused
>>>> some trouble of a similar nature by its sheer size. It helps though that
>>>> there's generally only one or a few clearly-near-optimum use patterns
>>>> for a given job, and that everything (mostly) has descriptive names too.
>>>> ListIterator and MessageDigest are names that convey quite a bit about
>>>> what they do; defgeneric and #:cl #:foo somewhat less so. :)
>>> defgeneric DEFines a GENERIC function.
>>> cl is shorthand for common-lisp, and foo... well, it's foo :)
>> I know this. The point is, the names are less SELF-explanatory. (And you
>> omitted to state what the #: bit is for the latter.)
>
> It's a read-macro -- Common Lisp's equivalent of syntax.
With syntax like that, who needs enemies? :P
> Your question is like asking what the ; is for in "import foo;"
Not really. A statement separator is pretty obvious. Lisp just uses
spaces as separators, so the #: prefix (not used much of anywhere else)
remains mysterious.
On May 22, 1:40 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Adlai wrote:
> > On May 22, 12:23 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Alessio Stalla wrote:
> >>> On May 20, 10:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Alessio Stalla wrote:
> >>>>> On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>>>> Alessio Stalla wrote:
> >>>>>>> What if the package system scoped generic "names", and those "names"
> >>>>>>> could be used to refer to verbs, nouns, pronouns, etc. etc.?
> >>>>>> That would be even worse: not only would methods and classes both have
> >>>>>> to be scoped, so thing.method() would have to have two scopes decided
> >>>>>> somehow (and the type of "thing" cannot be a factor in compile-time name
> >>>>>> resolution, since as far as the compiler is concerned it could be
> >>>>>> anything), but method names and class names could now collide with one
> >>>>>> another, and possibly with other things too!
> >>>>> They don't
> >>>> Sure they do. Either two identical names collide, or they reside in
> >>>> distinct namespaces. You just insinuated that methods and classes do not
> >>>> reside in distinct namespaces (quoted material, very top of this post).
> >>>> Therefore if one of each with the same name resides in a single one,
> >>>> they collide. It's elementary logic, Alessio.
> >>> Do a field named foo and a method named foo in the same class collide
> >>> in Java? No.
> >> Because they reside in different namespaces. Java doesn't just consider
> >> them both "symbols" and throw them together into a single namespace;
> >> instead, it creates separate ones within the class for fields and for
> >> methods.
>
> > By saying that, you reveal your ignorance
>
> That's it. I've had enough of being insulted every time I open my mouth.
>
> Fuck you!
Please don't split my sentances like that.
Now, what would you want me to say, if after reading something you
said, I concluded that you weren't fully aware of the facts?
Earlier in this discussion I said something that was just plain
incorrect (re: lists in Java). I was corrected, and I accepted that as
part of a discussion -- the part where you learn things you didn't
know before.
I'm glad when somebody corrects me. Of course, I wouldn't be happy if
the corrections themselves were false -- but I can check that out
easily on various sources (Java spec, Lisp spec, etc), and confirm for
myself whether something is right or not. If I said something that was
factually wrong, and somebody pointed that out and said what was
correct, I would be thankful to them for doing so.
So, my sincere question to you is: If I think that your knowledge
about some fact is incorrect, how would you want me to tell you that?
Surely there has to be some way of doing so in any discussion where
participants hope to learn.
>
> The truly egregious thing here is that I quite clearly know a LOT more
> about Java than you do, and you even attack me for my statements about Java.
I wasn't criticising your statement about Java -- I was criticising
your sentiment that because CL packages only have symbols, then there
are collisions between similarly-named variables, types, classes,
methods, etc.
>
> I don't think you're here to debate Lisp anymore. You're here to flame
> people and be generally boorish in public. The only question is: why?
It makes me sad that you think that. I'll admit it, some things that
have been said in this thread have made me laugh; however, this last
paragraph just makes me sad that you think that. Did you read the
section I wrote about what a symbol could mean in various contexts? Do
you remember my posts explaining various features of CL? Yes, I've had
some less-genteel posts, but you can't judge somebody by the worst of
their behaviour; if you did that, everybody in this thread would be a
"drive-by flamer".
>
> It does not matter. I deserve to be treated with a modicum of respect.
> People will stop criticizing me and confine their discussions to the
> programming languages under discussion here. The subject "Seamus MacRae"
> is off-topic. Got it?
Of course you deserve to be treated with respect; however, I don't
think it's disrespecting you to say that you have some facts
backwards. That's all I was saying. I wasn't saying "this guy doesn't
know his shit", which has been some of what other people have said. I
was trying to help you understand an aspect of the language, so that
maybe some other people won't think you as clueless as they seem to.
>
> >> However, an earlier poster said that Common Lisp just considers method
> >> names and the like to be "symbols" and throws them all together into a
> >> single namespace per package.
>
> >> If that earlier poster was incorrect, take it up with him. Attacking me
> >> for simply quoting him is pointless, rude, and should make you feel
> >> guilty now that you realize the attack was aimed at the wrong target and
> >> you just smacked an innocent bystander for someone else's offense.
>
> > I'm not attacking you
>
> That's a laugh.
>
> > I'm saying that you didn't understand ... caused you to misinterpret ...
> > that's a ... fact.
>
> No, it's another pack of vicious lies. What is the MATTER with you? Have
> you gone off the deep end? Are you physically incapable of carrying out
> a discussion without having to either agree with each other person or
> else flame him/her? Does disagreeing *without* acrimony simply not
> compute for you, or what?
If anything displays a lack of respect, it's mincing somebody's words
like that. I really do hope you read what I wrote before you replied
to it, because the sentiment expressed by your "remix" of what I said
is not at all like that of my original post.
>
> >>>>> it probably does not make much sense to do
> >>>>> (defmethod db-library:open-transaction ((transaction-manager picture-
> >>>>> library:jpeg-picture)) ...whatever...)
> >>>> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
> >>> See the parameter name - it's transaction-manager.
> >> What parameter name? All I see is a list of arguments. A
> >> transaction-manager and a picture-library might conceivably both be
> >> arguments to the same call.
>
> > Where it says transaction-manager in the quoted code is the class
> > specifier for the argument picture-library.
>
> You're not making much sense. I see a method with a list of two
> arguments here. Java would have "int foo, float bar" or the like, but
> Lisp functions lack argument types so that would just become "foo, bar"
> and Lisp list items are space-separated instead of comma-separated so
> that would just become "(foo bar)".
The method-definition syntax equivalent to Java's (int foo, float bar)
is ((int foo) (float bar)). (btw, this is something that I had wrong
earlier in the thread, and somebody corrected me about it very
bluntly, but who cares? I was wrong)
If you look at that method definition, you'll see: ((transaction-
manager picture-library:jpeg-picture))
The outside parentheses are the entire argument list; the inner
parentheses denote one argument.
>
> >>>>>>> But if you confuse your personal preference with objective
> >>>>>>> truth, and write that "truth" in public, I - we - feel the need to
> >>>>>>> correct your claims.
> >>>>>> That statement makes several insulting and false insinuations about me.
> >>>>> I'm sorry, but I genuinely think [repeats insults]
> >>>> Think what you want, but please restrain the urge to blurt out uncivil
> >>>> things in public. Weren't you taught any manners as a child?
> >>> I don't think
> >> That needs rectifying right away, then.
>
> > You complained earlier about people mincing up your messages before
> > replying to them. Don't do that to others. Weren't YOU ever taught the
> > Golden Rule as a child?
>
> Yes, but I was also taught game theory, and "tit for tat" tends to be a
> winning strategy. You do it to me enough times, I do it once to you as a
> little reminder.
>
> Now kindly return to the subject of Java and Lisp and stop discussing me
> or your opinions of me in public. It is not on-topic in either
> comp.lang.lisp or comp.lang.java.programmer and in fact so far as I am
> aware there is no alt.fan.seamus-macrae newsgroup, so it's off-topic
> everywhere.
>
> Let it drop.
I'm just asking you to not chop up what people wrote, when you answer
them. I think that I'm allowed to request that as part of the
standards for a "reasonable discussion".
>
> >>>> Without the javadocs Java's standard library might plausibly have caused
> >>>> some trouble of a similar nature by its sheer size. It helps though that
> >>>> there's generally only one or a few clearly-near-optimum use patterns
> >>>> for a given job, and that everything (mostly) has descriptive names too.
> >>>> ListIterator and MessageDigest are names that convey quite a bit about
> >>>> what they do; defgeneric and #:cl #:foo somewhat less so. :)
> >>> defgeneric DEFines a GENERIC function.
> >>> cl is shorthand for common-lisp, and foo... well, it's foo :)
> >> I know this. The point is, the names are less SELF-explanatory. (And you
> >> omitted to state what the #: bit is for the latter.)
>
> > It's a read-macro -- Common Lisp's equivalent of syntax.
(I'm actually not sure whether it's technically a read-macro, although
it does change the way the reader interprets the symbol, so I'm
guessing it's some form of read-macro)
>
> With syntax like that, who needs enemies? :P
>
> > Your question is like asking what the ; is for in "import foo;"
>
> Not really. A statement separator is pretty obvious. Lisp just uses
> spaces as separators, so the #: prefix (not used much of anywhere else)
> remains mysterious.
Well it's not exactly the same. However, it is a bit of syntax, which
does get used in GENSYMs, which crop up all over the place when you're
doing macros, so it's an important bit of syntax.
The condition ? exp1 : exp2; syntax isn't as common as ; or . in Java,
but it's also worth being familiar with because it's a tidy bit of
syntax when it is used.
Compared to most other languages, Lisp has no syntax in the core
language, and just a handful of abbreviations (such as ' and #' and
the backquote syntax). However, that syntax is just as important as
any other feature of CL, for understanding code.
- Adlai
Adlai wrote:
> On May 22, 1:40 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Adlai wrote:
>>> On May 22, 12:23 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Alessio Stalla wrote:
>>>>> On May 20, 10:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> Alessio Stalla wrote:
>>>>>>> On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>>>> Alessio Stalla wrote:
>>>>>>>>> What if the package system scoped generic "names", and those "names"
>>>>>>>>> could be used to refer to verbs, nouns, pronouns, etc. etc.?
>>>>>>>> That would be even worse: not only would methods and classes both have
>>>>>>>> to be scoped, so thing.method() would have to have two scopes decided
>>>>>>>> somehow (and the type of "thing" cannot be a factor in compile-time name
>>>>>>>> resolution, since as far as the compiler is concerned it could be
>>>>>>>> anything), but method names and class names could now collide with one
>>>>>>>> another, and possibly with other things too!
>>>>>>> They don't
>>>>>> Sure they do. Either two identical names collide, or they reside in
>>>>>> distinct namespaces. You just insinuated that methods and classes do not
>>>>>> reside in distinct namespaces (quoted material, very top of this post).
>>>>>> Therefore if one of each with the same name resides in a single one,
>>>>>> they collide. It's elementary logic, Alessio.
>>>>> Do a field named foo and a method named foo in the same class collide
>>>>> in Java? No.
>>>> Because they reside in different namespaces. Java doesn't just consider
>>>> them both "symbols" and throw them together into a single namespace;
>>>> instead, it creates separate ones within the class for fields and for
>>>> methods.
>>> By saying that, you reveal your ignorance
>> That's it. I've had enough of being insulted every time I open my mouth.
>>
>> Fuck you!
>
> Please don't split my sentances like that.
Then don't insult me.
> Now, what would you want me to say, if after reading something you
> said, I concluded that you weren't fully aware of the facts?
Nothing. Keep your negative opinions of others to yourself please.
> Earlier in this discussion I said something that was just plain
> incorrect (re: lists in Java). I was corrected, and I accepted that as
> part of a discussion -- the part where you learn things you didn't
> know before.
That was different: you were actually wrong.
> I'm glad when somebody corrects me.
I expect that should vary depending on a few factors, including:
* Were you actually wrong? If not, then not so good.
* What tone accompanied this "correction"? If unpleasant, then not so
good.
* Was it done discreetly, or loudly in a public place? If the latter,
then not so good.
* Was the "correction" useful, mere pedantry, or outright wrong? If
the latter two, then not so good, especially if the last item.
> Surely there has to be some way of doing so in any discussion where
> participants hope to learn.
Is learning the objective here? The debate seems to contain five
identifiable components.
One is the original Lisp vs. Java debate. This appears to involve some
factual statements about macros, type-safety, and what-have-you, but to
ultimately be a showdown between two unprovable opinions. There is
little to learn since opinions are inherently subjective, and opinions
also tend to be entrenched. Especially once one side makes things
personal, as yours has done.
A second is the emacs vs. Eclipse and more generally text vs. GUI debate
which likewise appears to boil down to opinion rather than fact.
Third is the argument over how awful a person Seamus MacRae is. This is
clearly also opinion, and furthermore uncivilized debate and off-topic
in both newsgroups. There is certainly nothing new to be learned here.
Fourth is the argument over how awful a person Series Expansion is. This
is entirely analogous to item number three.
Last but not least has been some odd paranoid ravings by several people,
notably Arne and Lars, centered on some kind of conspiracy theory
involving myself, Series, and several named individuals all but one of
whom is absent from this thread (the remaining one only showed up AFTER
being badmouthed by Lars a time or two, for no reason apparent to me,
and evidently getting mad about this). Obviously there is little to
learn here unless one's field of study is abnormal psychology, in which
case Lars and Arne may make excellent case studies on the topic of
shared delusions.
The final three items on the list are quite unfortunate. It is worth
noting that the targets of the flamage seem to be exclusively on the
Java/Eclipse/GUI side of the first two items now. It seems a
meta-argument can be made for the Java/Eclipse/GUI side that they're
better behaved than their Lisp/emacs/text counterparts on average.
>> The truly egregious thing here is that I quite clearly know a LOT more
>> about Java than you do, and you even attack me for my statements about Java.
>
> I wasn't criticising your statement about Java
Reminder time:
>>>> Because they reside in different namespaces. Java doesn't just consider
>>>> them both "symbols" and throw them together into a single namespace;
>>>> instead, it creates separate ones within the class for fields and for
>>>> methods.
That's me, making statements about Java.
>>> By saying that, you reveal your ignorance
And that's you, clearly attacking my statements about Java.
Now please retract your lie above about not criticizing my statements
about Java.
> I was criticising
Don't. I didn't come here to be criticized, I came here to explain why
Java is superior to Lisp. :)
>> I don't think you're here to debate Lisp anymore. You're here to flame
>> people and be generally boorish in public. The only question is: why?
>
> It makes me sad that you think that.
If you wish me to think otherwise, then alter your behavior. What I
think about your motives is the result of inference based on the
available evidence, namely, what I've seen you doing and heard you
saying. If your behavior is leading me to believe the above (so far it
is), and you'd prefer I believe something different, then the way to
make that preferred state come about is to alter your behavior so that
different conclusions are drawn from it. Insulting me and then lying
about it is a very poor start however.
> I'll admit it, some things that have been said in this thread have
> made me laugh;
I've found little amusing except the "9th-dan black belt in usenet-fu"
remark found in a drive-by flame a while ago and a recent quip about xterms.
> Yes, I've had
> some less-genteel posts, but you can't judge somebody by the worst of
> their behaviour; if you did that, everybody in this thread would be a
> "drive-by flamer".
Actually, a drive-by flamer is, more or less by definition, posting one
or a handful of flames and then relurking. Most of the people flaming
here are also sticking around. Unfortunately.
>> It does not matter. I deserve to be treated with a modicum of respect.
>> People will stop criticizing me and confine their discussions to the
>> programming languages under discussion here. The subject "Seamus MacRae"
>> is off-topic. Got it?
>
> Of course you deserve to be treated with respect
Then please start doing so.
> however, I don't think it's disrespecting you to say that you [are
> stupid]
Oh, really? I dispute that.
> I wasn't saying "this guy doesn't know his shit"
Sure looked that way.
>>> I'm saying that you didn't understand ... caused you to misinterpret ...
>>> that's a ... fact.
>> No, it's another pack of vicious lies. What is the MATTER with you? Have
>> you gone off the deep end? Are you physically incapable of carrying out
>> a discussion without having to either agree with each other person or
>> else flame him/her? Does disagreeing *without* acrimony simply not
>> compute for you, or what?
>
> If anything displays a lack of respect, it's mincing somebody's words
> like that.
They were insulting words. I don't feel a lot of respect for insults. So
I reduced it to a summary that conveys the gist.
> I really do hope you read what I wrote before you replied
> to it, because the sentiment expressed by your "remix" of what I said
> is not at all like that of my original post.
Sure it is. It was, and remains, crystal clear. You think I don't
understand. You think I misinterpret. You also, especially
unfortunately, think your opinions of me are ironclad facts rather than
mere opinions.
>>>>>>> it probably does not make much sense to do
>>>>>>> (defmethod db-library:open-transaction ((transaction-manager picture-
>>>>>>> library:jpeg-picture)) ...whatever...)
>>>>>> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>>>>> See the parameter name - it's transaction-manager.
>>>> What parameter name? All I see is a list of arguments. A
>>>> transaction-manager and a picture-library might conceivably both be
>>>> arguments to the same call.
>>> Where it says transaction-manager in the quoted code is the class
>>> specifier for the argument picture-library.
>> You're not making much sense. I see a method with a list of two
>> arguments here. Java would have "int foo, float bar" or the like, but
>> Lisp functions lack argument types so that would just become "foo, bar"
>> and Lisp list items are space-separated instead of comma-separated so
>> that would just become "(foo bar)".
>
> The method-definition syntax equivalent to Java's (int foo, float bar)
> is ((int foo) (float bar)). (btw, this is something that I had wrong
> earlier in the thread, and somebody corrected me about it very
> bluntly, but who cares? I was wrong)
Politeness does not count for you? It's at the "who cares" level of
importance? I suppose that would explain your own behavior.
> If you look at that method definition, you'll see: ((transaction-
> manager picture-library:jpeg-picture))
> The outside parentheses are the entire argument list; the inner
> parentheses denote one argument.
Then it doesn't make sense the way you interpreted it -- it then looks
like one has named a transaction-manager typed variable jpeg-picture. It
also has other problems, such as a scope on the parameter name. How can
a parameter name be scoped? It's automatically a local variable of the
method. Last but not least though, how can that variable have a type at
all? Variables don't have types in Lisp. Data sometimes seems to, but
not variables.
>> Now kindly return to the subject of Java and Lisp and stop discussing me
>> or your opinions of me in public. It is not on-topic in either
>> comp.lang.lisp or comp.lang.java.programmer and in fact so far as I am
>> aware there is no alt.fan.seamus-macrae newsgroup, so it's off-topic
>> everywhere.
>>
>> Let it drop.
>
> I'm just asking you
I said, let it drop.
> I think that I'm allowed to request that as part of the
> standards for a "reasonable discussion".
You first.
>>> Your question is like asking what the ; is for in "import foo;"
>> Not really. A statement separator is pretty obvious. Lisp just uses
>> spaces as separators, so the #: prefix (not used much of anywhere else)
>> remains mysterious.
>
> Well it's not exactly the same.
Told you.
> The condition ? exp1 : exp2; syntax isn't as common as ; or . in Java,
> but it's also worth being familiar with because it's a tidy bit of
> syntax when it is used.
Actually it originated with C, and is in C++ as well. And it's maybe not
very self explanatory, but it's not encountered within the first five
minutes of running into C code, either. That #: shit, on the other hand,
is on just about every import statement.
> Compared to most other languages, Lisp has no syntax in the core
> language, and just a handful of abbreviations (such as ' and #' and
> the backquote syntax).
I know this. But it was #: that was at issue, not #'.
> However, that syntax is just as important as
> any other feature of CL, for understanding code.
I expect it would be. Too bad it appears to ultimately be hairier than
Java's. Java's ?: is tame compared to #:. It's simple to explain, the
expression evaluates to the second argument if the first is true, else
the third argument. No rocket science involving "read macro" and other
compiler-theory type stuff needed. Java doesn't force you to get your
hands that dirty unless you're implementing parts of a Java toolchain,
monkeying with bytecode, or tinkering with ClassLoader.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>>> If you look at that method definition, you'll see: ((transaction-
>>> manager picture-library:jpeg-picture))
>>> The outside parentheses are the entire argument list; the inner
>>> parentheses denote one argument.
>> Then it doesn't make sense the way you interpreted it -- it then looks
>> like one has named a transaction-manager typed variable
>> jpeg-picture.
>
> Adlai has it backwards: the first symbol is the parameter name, the
> second is the type.
What? That's like writing
foo int;
instead of
int foo;
Why would anyone do it like that, unless they were Hebrew or Arabic
speaking? (And even then -- most language designs seem to have
originated not only in left-to-right writing countries, but specifically
in English-speaking countries, by and large!)
>> Last but not least though, how can
>> that variable have a type at all? Variables don't have types in
>> Lisp. Data sometimes seems to, but not variables.
>
> So you keep saying.
(let ('variable value)). (defun 'name (param1 param2) (body)). Where are
the types? There only seem to be the argument names and variable names
in these places.
Lisp does not have typed variables and parameters. Maybe CLOS does, but
Lisp does not.
> Since you obviously know far more about Lisp than
> people who actually use and implement Lisp, you must be right.
Don't be ridiculous.
> Obviously CLOS doesn't actually work; we just photoshop the screenshots
> to make it look that way.
Obviously it does work, just not quite the way some people are
describing it here.
Seamus MacRae <··········@live.ca.nospam> writes:
> (let ('variable value)). (defun 'name (param1 param2) (body)). Where are
> the types? There only seem to be the argument names and variable names
> in these places.
That's because you haven't put the type declarations in. Also, there
are extraneous quotes, and the LET form you wrote, although legal,
doesn't do what you think it does.
> Lisp does not have typed variables and parameters.
Incorrect. "It is possible to declare that a variable takes on only
values of a given type by making an explicit type
declaration."
http://www.lispworks.com/documentation/HyperSpec/Body/04_a.htm
> Maybe CLOS does, but Lisp does not.
Incorrect. CLOS is part of the Common Lisp specification, which makes
it a part of Lisp. Your statement is like saying "classes have methods
but Java does not."
> Obviously it does work, just not quite the way some people are
> describing it here.
Of course it works the way people describe it here. It doesn't,
however, work the way you imagine it to work. So the problem lies in
your interpretation of how it works.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 22, 12:50 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
> > (let ('variable value)). (defun 'name (param1 param2) (body)). Where are
> > the types? There only seem to be the argument names and variable names
> > in these places.
>
> That's because you haven't put the type declarations in. Also, there
> are extraneous quotes, and the LET form you wrote, although legal,
> doesn't do what you think it does.
>
> > Lisp does not have typed variables and parameters.
>
> Incorrect. "It is possible to declare that a variable takes on only
> values of a given type by making an explicit type
> declaration."
>
> http://www.lispworks.com/documentation/HyperSpec/Body/04_a.htm
>
> > Maybe CLOS does, but Lisp does not.
>
> Incorrect. CLOS is part of the Common Lisp specification, which makes
> it a part of Lisp. Your statement is like saying "classes have methods
> but Java does not."
>
> > Obviously it does work, just not quite the way some people are
> > describing it here.
>
> Of course it works the way people describe it here. It doesn't,
> however, work the way you imagine it to work. So the problem lies in
> your interpretation of how it works.
The problem lies with people like you that badmouth other people where
they won't see it and defend themselves.
On May 22, 6:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> (let ('variable value)). (defun 'name (param1 param2) (body)). Where are
> the types? There only seem to be the argument names and variable names
> in these places.
Those two Lisp forms that you tried to make there show some SERIOUS
ignorance of basic concepts. Seamus, I'm sorry to say, but you really
do seem to have no clue what you're talking about. Not just in terms
of the more complicated stuff -- packages etc -- but also in terms of
basic Lisp syntax.
- Adlai
Adlai wrote:
> Those two Lisp forms that you tried to make there show some SERIOUS
> ignorance
What they show is that I haven't used Lisp in quite a while and don't
have a reference or an implementation handy at the moment, nothing more.
The remainder of your insults and unwarranted jumping-to-conclusions has
been deleted without dignifying any of it with point-by-point responses.
Suffice it to say that Google's archiving of your post will be more
embarrassing to you than to me.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> Adlai has it backwards: the first symbol is the parameter name, the
>>> second is the type.
>> What? That's like writing
>>
>> foo int;
>>
>> instead of
>>
>> int foo;
>>
>> Why would anyone do it like that, unless they were Hebrew or Arabic
>> speaking? (And even then -- most language designs seem to have
>> originated not only in left-to-right writing countries, but
>> specifically in English-speaking countries, by and large!)
>
> Ye-es.
>
> Why would you want to write "int foo;", unless you were Yoda?
When 900 years old you reach, look as good you will not, hmm?
>>>> Last but not least though, how can
>>>> that variable have a type at all? Variables don't have types in
>>>> Lisp. Data sometimes seems to, but not variables.
>>> So you keep saying.
>> (let ('variable value)). (defun 'name (param1 param2) (body)). Where
>
> [pedantry deleted]
>
>> are the types? There only seem to be the argument names and variable
>> names in these places.
>
> The types are implicit, unless you make them explicit. The type of
> each thing above is implicitly T (read: java.lang.Object).
Then (param1 param2) is ambiguous: param2 might be a second parameter,
or a type for the first.
> [The type system is far more flexible than Java's, too!
One you can totally ignore or circumvent at any time tends to have that
trait, yes.
> You can just say "var is an integer", but you can also say "var is a
> prime between 7 and 139", if you want...what's the type for that in
> Java?
A class of your own devising, if you want such a type. The number of
such primes is small enough for it to likely be feasible to make it an enum.
> (Granted, the compiler's not likely to do much with that)
In Lisp, perhaps not. In Java, it could ensure that expressions assigned
to that variable had a compatible type, or else a run-time check to
throw an exception whenever they were not.
>>> Since you obviously know far more about Lisp than
>>> people who actually use and implement Lisp, you must be right.
>> Don't be ridiculous.
>
> Well, you keep very forcefully asserting these things about Lisp
The things I "very forcefully assert" about Lisp that are not mere
opinions are restatements of, or deduced from, the things you "very
forcefully assert" about Lisp.
> ISTM either of two possibilities must obtain: (1) we're all
> idiots: you know Lisp better than us, or (2) you don't know what
> you're talking about and are incapable of being educated, making
> you the idiot. And you keep disclaiming the latter, so I assumed
> the former must be true. No?
No. The most plausible explanation is that the things you "very
forcefully assert" about Lisp include honest mistakes, as well as
omissions that are misleading and unclear or ambiguous statements with
the property that the interpretation that is most plausible to someone
without specific prior knowledge otherwise, and the interpretation that
you intended, are distinct.
In simpler language, that you're not idiots, but not managing to explain
things very well either, at least partly due to some internal
disagreements. It is possible that there have been statements made about
several versions of Lisp that are inconsistent if treated as statements
solely about Common Lisp, as well, and therefore that the impression of
Lisp you have created inadvertently is of a chimerical fusion of several
actual Lisps, yet identical to none of them.
(In much of the above, "you" can be taken as referring to multiple
persons from comp.lang.lisp, rather than you personally.)
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>>> The types are implicit, unless you make them explicit. The type of
>>> each thing above is implicitly T (read: java.lang.Object).
>> Then (param1 param2) is ambiguous: param2 might be a second parameter,
>> or a type for the first.
>
> Context matters. In some contexts (x y) is two parameter names. In
> some contexts, it's a name and a value.
> In some, it's a function and argument. In some it's a variable name
> and type. In some, it's just data - a two-element list.
Apparently including in at least one pair of contexts that look the same
to human eyes.
>>> [The type system is far more flexible than Java's, too!
>> One you can totally ignore or circumvent at any time tends to have
>> that trait, yes.
>
> If you ignore and circumvent the type system, you either get errors at
> compile time (if Lisp can detect what you've done), errors at run time
> (if the compiler is set to perform run-time checks), or segfaults and
> other misbehaviour at run-time (if it isn't)
What you are describing is the behavior of a statically-typed language
like C.
Without the ability to get direct access to machine pointers like you
can in C, and then alter their values arbitrarily or increment them, nor
the ability to deallocate an object still referenced, I would consider
any occurrence of a segfault evidence of an implementation bug.
Certainly if a JVM ever segfaults, and it isn't due to buggy
non-standard-library native code called through JNI, then it is
indicative of an implementation bug.
> Just a pointless example. Extend it to whatever range you like.
> [And any random value that fits the specification, from a source that
> knows nothing about your "class of your own devising" should test as
> being of that type]
For that, you'd need either to make your own higher-level type system
with explicit predicate functions, or else have a conversion function
that returns a value as a particular type if possible and throws an
exception otherwise.
>>> (Granted, the compiler's not likely to do much with that)
>> In Lisp, perhaps not. In Java, it could ensure that expressions
>> assigned to that variable had a compatible type, or else a run-time
>> check to throw an exception whenever they were not.
>
> It'll do /that/ much in Lisp
Run-time checks I'll grant you.
> but it's not likely to compile better code with that information,
> etc., the way it can if it knows you have an integer that fits in a
> hardware register, etc.
This is an excellent argument in favor of using a Java- or C-like
language possessing modulo types like int, short, and long, rather than
a language that (conceptually, at least) has all numbers be bignums.
(Smalltalk is the other noteworthy culprit here, though it helps that
all small-enough integers are automatically made instances of
SmallInteger, which is a bit smaller in capacity than the machine-native
int since a bit is reserved for flagging whether the data stored is a
SmallInteger or a pointer. The pointer is also shortened, but this just
means Smalltalk has to allocate everything at an even address and mask
off the bit or else have that bit be a zero for pointers and a one for
integers instead of the other way around. Typical systems prefer to
allocate everything at addresses that are multiples of larger numbers,
like 4 or 16, anyway. Java objects are all word-aligned in memory, too.)
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>> The types are implicit, unless you make them explicit. The type of
>>>>> each thing above is implicitly T (read: java.lang.Object).
>>>> Then (param1 param2) is ambiguous: param2 might be a second parameter,
>>>> or a type for the first.
>>> Context matters. In some contexts (x y) is two parameter names. In
>>> some contexts, it's a name and a value.
>>> In some, it's a function and argument. In some it's a variable name
>>> and type. In some, it's just data - a two-element list.
>> Apparently including in at least one pair of contexts that look the
>> same to human eyes.
>
> But not to human eyes attached to a human brain that understands what
> it's looking at.
This is another example of a pointless and irrelevant personal attack.
Blow it out your USB port.
>>>>> [The type system is far more flexible than Java's, too!
>>>> One you can totally ignore or circumvent at any time tends to have
>>>> that trait, yes.
>>> If you ignore and circumvent the type system, you either get errors
>>> at
>>> compile time (if Lisp can detect what you've done), errors at run time
>>> (if the compiler is set to perform run-time checks), or segfaults and
>>> other misbehaviour at run-time (if it isn't)
>> What you are describing is the behavior of a statically-typed language
>> like C.
>>
>> Without the ability to get direct access to machine pointers like you
>> can in C, and then alter their values arbitrarily or increment them,
>> nor the ability to deallocate an object still referenced, I would
>> consider any occurrence of a segfault evidence of an implementation
>> bug.
>
> It isn't a "bug" if you deliberately caused it by going out of your
> way to circumvent the type system.
The point is that you should not be able to cause it in that way. You
cannot in a bug-free Java implementation, even messing with reflection,
setAccessible(true), and using Object references for everything. You can
completely subvert compile-time type safety and encapsulation and the
worst a bug-free Java implementation will give you is a Java exception
stack trace, unless you call into buggy C code through JNI. Even
directly hacking the bytecode in class files shouldn't enable you to
crash a properly-functioning JVM.
>>> but it's not likely to compile better code with that information,
>>> etc., the way it can if it knows you have an integer that fits in a
>>> hardware register, etc.
>> This is an excellent argument in favor of using a Java- or C-like
>> language possessing modulo types like int, short, and long, rather
>> than a language that (conceptually, at least) has all numbers be
>> bignums.
>
> Indeed...or Lisp, which, as I've said, can also declare types like
> restricted integers and such
Not the same thing. A Java int is intrinsically known by, and thus
easily optimized by, the compiler. However, if I were to take Java's
BigInteger and subclass it to create a version with a limited range,
contained within that of an int, and use it in my code, the Java
compiler could not optimize it because it would know nothing about it
save that it was a subtype of BigInteger.
Similarly, your Lisp compiler cannot know about a user-defined type in
any real detail, only perhaps what it's a subtype of and what its own
subtypes are. (Perhaps the macro processor can know more, because the
macros themselves can, but the backend that translates things into
machine code cannot.) A user-defined type might represent anything from
a small integer to a big collection of strings. The only way around this
would be for the compiler to have as much knowledge of the program's
global semantics as the human programmer. Yet compilers, almost by
definition as well as by technological necessity, concern themselves
only with local semantics.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Not the same thing. A Java int is intrinsically known by, and thus
>> easily optimized by, the compiler.
>
> A Lisp integer is intrinsically known by, and thus easily optimized
> by, the compiler.
Disingenuous. A Lisp integer is a bignum, rather than a machine word in
size, and the compiler cannot know at compile time the sizes of the
integers that actually will occur.
And if somehow it could, Java's compiler could similarly optimize
BigInteger, since the latter is a standard library class.
>> Similarly, your Lisp compiler cannot know about a user-defined type in
>> any real detail, only perhaps what it's a subtype of and what its own
>> subtypes are. (Perhaps the macro processor can know more, because the
>
> The "macro processor" is Lisp.
The macro processor is a part of any conforming Lisp implementation,
yes, but this is both obvious and irrelevant.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> Not the same thing. A Java int is intrinsically known by, and thus
>>>> easily optimized by, the compiler.
>>> A Lisp integer is intrinsically known by, and thus easily optimized
>>> by, the compiler.
>> Disingenuous. A Lisp integer is a bignum, rather than a machine word
>> in size, and the compiler cannot know at compile time the sizes of the
>> integers that actually will occur.
>
> It can if either (a) it knows the source of the integer, or (b) the
> programmer tells it.
(a) would require that the integer can be proved to be, and remain,
small by static analysis. And then Java's compiler could do the same, in
principle, with BigInteger, and you have again failed to prove Lisp
intrinsically superior to Java.
(b) would of course require that Lisp not by dynamically typed.
>>>> Similarly, your Lisp compiler cannot know about a user-defined type in
>>>> any real detail, only perhaps what it's a subtype of and what its own
>>>> subtypes are. (Perhaps the macro processor can know more, because the
>>> The "macro processor" is Lisp.
>> The macro processor is a part of any conforming Lisp implementation,
>> yes, but this is both obvious and irrelevant.
>
> It's not "part of any conforming Lisp implementation", it /is/ that
> Lisp implementation.
Nonsense. The macro processor alone is incapable of generating bytecodes
or native machine code, only changing source code into other source
code. Therefore, the macro processor cannot even be the entirety of the
compiler, let alone the implementation as a whole, which contains that
compiler but also for instance the interactive REPL/interpreter,
additional tools, the standard library classes and functions, and
potentially other types of component.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>>> Not the same thing. A Java int is intrinsically known by, and thus
>>>>>> easily optimized by, the compiler.
>>>>> A Lisp integer is intrinsically known by, and thus easily optimized
>>>>> by, the compiler.
>>>> Disingenuous. A Lisp integer is a bignum, rather than a machine word
>>>> in size, and the compiler cannot know at compile time the sizes of the
>>>> integers that actually will occur.
>>> It can if either (a) it knows the source of the integer, or (b) the
>>> programmer tells it.
>> (a) would require that the integer can be proved to be, and remain,
>> small by static analysis. And then Java's compiler could do the same,
>
> Yes. So?
I was getting to that:
>> in principle, with BigInteger, and you have again failed to prove Lisp
>> intrinsically superior to Java.
>
> Since I'm not /trying/ to prove Lisp is intrinsically superior to
> Java, that's no great shock.
This entire thread has largely been your efforts to prove Lisp superior
to Java. If you have now given up on that goal, why are you still
posting to it?
>> (b) would of course require that Lisp not by dynamically typed.
>
> You mean (b) would require
that Lisp not be dynamically typed.
On Sat, 23 May 2009 01:37:01 +1200, http://public.xdi.org/=pf wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> that variable have a type at all? Variables don't have types in Lisp.
>> Data sometimes seems to, but not variables.
>
> So you keep saying. Since you obviously know far more about Lisp than
> people who actually use and implement Lisp, you must be right. Obviously
> CLOS doesn't actually work; we just photoshop the screenshots to make it
> look that way.
Well, at least Photoshop has macros :-)
Tamas
Tamas K Papp wrote:
> On Sat, 23 May 2009 01:37:01 +1200, http://public.xdi.org/=pf wrote:
>
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>> that variable have a type at all? Variables don't have types in Lisp.
>>> Data sometimes seems to, but not variables.
>> So you keep saying. Since you obviously know far more about Lisp than
>> people who actually use and implement Lisp, you must be right. Obviously
>> CLOS doesn't actually work; we just photoshop the screenshots to make it
>> look that way.
>
> Well, at least Photoshop has macros :-)
Paul Foley is being ridiculous here. I never claimed to know "far more
about Lisp", nor that CLOS didn't work, only that I didn't know
*nothing* about it and that CLOS is in some ways clunky.
Adlai wrote:
> On May 22, 1:40 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> That's it. I've had enough of being insulted every time I open my mouth.
>>
>> Fuck you!
>
> Please don't split my sentances like that.
>
> Now, what would you want me to say, if after reading something you
> said, I concluded that you weren't fully aware of the facts?
>
> Earlier in this discussion I said something that was just plain
> incorrect (re: lists in Java). I was corrected, and I accepted that as
> part of a discussion -- the part where you learn things you didn't
> know before.
>
> I'm glad when somebody corrects me. Of course, I wouldn't be happy if
> the corrections themselves were false -- but I can check that out
> easily on various sources (Java spec, Lisp spec, etc), and confirm for
> myself whether something is right or not. If I said something that was
> factually wrong, and somebody pointed that out and said what was
> correct, I would be thankful to them for doing so.
>
> So, my sincere question to you is: If I think that your knowledge
> about some fact is incorrect, how would you want me to tell you that?
Very good question.
Most likely he would assume that never happens.
(even though it happen all the time)
Arne
Arne Vajh�j wrote:
> Adlai wrote:
>> So, my sincere question to you is: If I think that your knowledge
>> about some fact is incorrect, how would you want me to tell you that?
>
> Very good question.
No, it's a silly question, since it's clearly irrelevant to the great
Lisp vs. Java debate.
> (even though it happen all the time)
It does not. Personal attacks from you, however, do seem to "happen all
the time". Perhaps you should find something more constructive to do?
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Not really. A statement separator is pretty obvious. Lisp just uses
>> spaces as separators, so the #: prefix (not used much of anywhere
>> else) remains mysterious.
>
> It's mysterious /to you/ because you refuse to learn anything at all
*sigh* More useless flaming.
> claiming you just know everything there is to know by virtue of your
> infallible logic. See how that doesn't work out?
No. I have made no such claims of knowing everything. I have claimed to
be able to make logical deductions from data. Not the same thing.
I had no basis for deducing anything about what #: might mean. Indeed
that was my point, that it was cryptic and probably needlessly so.
And so I asked. You seem to think it a vice rather than a virtue to
respond to not knowing something by asking. This is evidenced by your
rude demands ("go read a book" etc. for the umpteenth time) and personal
attacks (you don't know that? what an idiot!) in response to the question.
> #:foo is how you write a symbol named foo that isn't in any package.
Another contradiction! Earlier Alessio said something made something
that wasn't in any package, thus (he claimed) making it inaccessible to
anything that didn't already have the reference. Looks like according to
you, things that are not in any package aren't quite so inaccessible.
Care to get your stories straight before continuing this debate, you two?
Seamus MacRae <··········@live.ca.nospam> writes:
> Paul Foley (http://public.xdi.org/=pf) wrote:
>
> > claiming you just know everything there is to know by virtue of your
> > infallible logic. See how that doesn't work out?
>
> No. I have made no such claims of knowing everything. I have claimed to
> be able to make logical deductions from data. Not the same thing.
Well, while you claim to be able to make logical deductions from data,
you have demonstrated an inability to actually make logical deductions
from data. You seem to supplement any data you are given with
unwarranted assumptions that are drawn from a profound ignorance of the
underlying technology.
> I had no basis for deducing anything about what #: might mean. Indeed
> that was my point, that it was cryptic and probably needlessly so.
But that didn't stop you from trying to make deductions based on it,
right? And it didn't lead to ask for a simple clarification.
> And so I asked. You seem to think it a vice rather than a virtue to
> respond to not knowing something by asking. This is evidenced by your
> rude demands ("go read a book" etc. for the umpteenth time) and personal
> attacks (you don't know that? what an idiot!) in response to the
> question.
Well, for someone who wants to make technical claims, you display a
profound lack of understanding of the technical artifact that you wish
to analyze. And you seem to positively revel in refusing to go to any
sources to actually learn something about the technology.
And for the record, pointing out ignorance is not a personal attack. It
is a statement of fact, given that you demonstrate a lack of knowledge.
ignorance: (Noun) lack of knowledge or education
Fortunately, for most people ignorance can be cured. It just requires a
desire to learn, rather than an aversion to learning. Idiocy, on the
other hand, does not have any cure that I'm aware of.
> > #:foo is how you write a symbol named foo that isn't in any package.
>
> Another contradiction! Earlier Alessio said something made something
> that wasn't in any package, thus (he claimed) making it inaccessible to
> anything that didn't already have the reference. Looks like according to
> you, things that are not in any package aren't quite so inaccessible.
>
> Care to get your stories straight before continuing this debate, you two?
Another argument from ignorance.
What makes you think that #:foo makes the symbol accessible? In fact,
it doesn't. But to understand that you would have to actually know
something about Common Lisp. But instead, you prefer to jump to
conclusions that are patently false. Ponder the following snippets of
lisp code:
(eq 'foo 'foo) ; ==> T
(eq '#:foo '#:foo) ; ==> NIL
Since uninterned symbols don't live in any package, and are not
accessible via their print names, you can, in fact, have any number of
uninterned symbols with the same symbol-name that are different
symbols. Now before you go off making additional unwarranted
assumptions, let me point out that this description was carefully
crafted using specific terms that are well-defined in the Common Lisp
specification. So, before you invent some fanciful interpretation, it
would be wise to check the specification first to see what the proper
and correct interpretation is.
It is also possible to have any number of interned symbols with the same
symbol-name that are different symbols as well. They just have to be in
different packages. This is, of course, no different than the way Java
would let you have any number of different methods or fields with a
given name, as long as they were in different namespaces.
Oh, and here are a couple more interesting examples using uninterned
symbols:
(let ((s1 '#:foo)
(s2 '#:foo)
(s3 'foo)
(s4 'foo))
(eq s1 s1) ; ==> T
(eq s1 s2) ; ==> NIL
(eq s1 '#:foo) ; ==> NIL
(eq s3 s3) ; ==> T
(eq s3 s4) ; ==> T
(eq s3 'foo) ; ==> T
)
BTW, argumentum ad ignorantiam is also a logical fallacy
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Paul Foley (http://public.xdi.org/=pf) wrote:
>>> claiming you just know everything there is to know by virtue of your
>>> infallible logic. See how that doesn't work out?
>> No. I have made no such claims of knowing everything. I have claimed to
>> be able to make logical deductions from data. Not the same thing.
>
> Well, while you claim to be able to make logical deductions from data,
> you have demonstrated an inability to actually make logical deductions
> from data.
This, of course, is a vicious lie.
[much else in the way of insulting tripe deleted]
>> I had no basis for deducing anything about what #: might mean. Indeed
>> that was my point, that it was cryptic and probably needlessly so.
>
> But
But nothing. It's cryptic, pure and simple.
>> And so I asked. You seem to think it a vice rather than a virtue to
>> respond to not knowing something by asking. This is evidenced by your
>> rude demands ("go read a book" etc. for the umpteenth time) and personal
>> attacks (you don't know that? what an idiot!) in response to the
>> question.
>
> Well, for someone who wants to make technical claims, you display
> blah blah blah blah blah blah blah blah ...
Your arguments lack substance. Unfortunately, they tend to substitute
namecalling for it.
>>> #:foo is how you write a symbol named foo that isn't in any package.
>> Another contradiction! Earlier Alessio said something made something
>> that wasn't in any package, thus (he claimed) making it inaccessible to
>> anything that didn't already have the reference. Looks like according to
>> you, things that are not in any package aren't quite so inaccessible.
>>
>> Care to get your stories straight before continuing this debate, you two?
>
> Another argument from ignorance.
Your ignorance, and your inability to get your own stories straight.
> [calls me a liar]
Buzz off.
> Since uninterned symbols don't live in any package, and are not
> accessible via their print names, you can, in fact, have any number of
> uninterned symbols with the same symbol-name that are different
> symbols.
With the one caveat: as a consequence, you can't use the same one twice.
Write-only variables. What a wonderful idea!
[condescension deleted]
> BTW, argumentum ad ignorantiam is also a logical fallacy
So is argumentum ad hominem, asshole.
["Followup-To:" header set to comp.lang.lisp.]
On 2009-05-22, Paul Foley <···@below.invalid> wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Not really. A statement separator is pretty obvious. Lisp just uses
>> spaces as separators, so the #: prefix (not used much of anywhere
>> else) remains mysterious.
>
> It's mysterious /to you/ because you refuse to learn anything at all
> about Common Lisp (even the things that people tell you directly, that
> don't even require you to go the trouble of clicking a link), claiming
> you just know everything there is to know by virtue of your infallible
> logic. See how that doesn't work out?
>
> #:foo is how you write a symbol named foo that isn't in any package.
Not quite.
The notation means that FOO doesn't have a home package, not that it isn't
present in any package.
However, the situation of a symbol with no home package which is nevertheless
present in some packages is rare, and not easy to create. You see whenever a
``homeless'' symbol is imported into a package, it is ``rehomed'' to that
package.
So we have to enter a symbol into two packages, and then remove it
from its home one.
Define a pkg package:
[1]> (defpackage :pkg)
#<PACKAGE PKG>
Intern a new symbol foo in pkg; pkg becomes its home package.
[2]> (intern "FOO" :pkg)
PKG::FOO ;
NIL
Import that symbol into the current package (cl-user):
[3]> (import 'pkg::foo)
T
Now blow it out of the pkg package, which is its home.
The symbol is now homeless.
[4]> (unintern 'pkg::foo :pkg)
T
Foo is still interned in the current package, and we can refer to it without
qualification. What is its print syntax?
[5]> 'foo
#:FOO
:)
On May 22, 7:42 pm, Kaz Kylheku <········@gmail.com> wrote:
> ["Followup-To:" header set to comp.lang.lisp.]
> On 2009-05-22, Paul Foley <····@below.invalid> wrote:
>
> > Seamus MacRae <··········@live.ca.nospam> writes:
>
> >> Not really. A statement separator is pretty obvious. Lisp just uses
> >> spaces as separators, so the #: prefix (not used much of anywhere
> >> else) remains mysterious.
>
> > It's mysterious /to you/ because you refuse to learn anything at all
> > about Common Lisp (even the things that people tell you directly, that
> > don't even require you to go the trouble of clicking a link), claiming
> > you just know everything there is to know by virtue of your infallible
> > logic. See how that doesn't work out?
>
> > #:foo is how you write a symbol named foo that isn't in any package.
>
> Not quite.
>
> The notation means that FOO doesn't have a home package, not that it isn't
> present in any package.
>
> However, the situation of a symbol with no home package which is nevertheless
> present in some packages is rare, and not easy to create. You see whenever a
> ``homeless'' symbol is imported into a package, it is ``rehomed'' to that
> package.
>
> So we have to enter a symbol into two packages, and then remove it
> from its home one.
>
> Define a pkg package:
>
> [1]> (defpackage :pkg)
> #<PACKAGE PKG>
>
> Intern a new symbol foo in pkg; pkg becomes its home package.
>
> [2]> (intern "FOO" :pkg)
> PKG::FOO ;
> NIL
>
> Import that symbol into the current package (cl-user):
>
> [3]> (import 'pkg::foo)
> T
>
> Now blow it out of the pkg package, which is its home.
> The symbol is now homeless.
>
> [4]> (unintern 'pkg::foo :pkg)
> T
>
> Foo is still interned in the current package, and we can refer to it without
> qualification. What is its print syntax?
>
> [5]> 'foo
> #:FOO
>
> :)
OHH, THANKS! Finally I learn something from this thread :D it HAD to
be worth something!
BTW, is it just me or we're (Seamus and I) destroying Google Groups?
Better stop posting here ;)
On Fri, 2009-05-22 at 12:06 -0700, Alessio Stalla wrote:
> On May 22, 7:42 pm, Kaz Kylheku <········@gmail.com> wrote:
> > ["Followup-To:" header set to comp.lang.lisp.]
> > On 2009-05-22, Paul Foley <····@below.invalid> wrote:
> >
> > > Seamus MacRae <··········@live.ca.nospam> writes:
> >
> > >> Not really. A statement separator is pretty obvious. Lisp just uses
> > >> spaces as separators, so the #: prefix (not used much of anywhere
> > >> else) remains mysterious.
> >
> > > It's mysterious /to you/ because you refuse to learn anything at all
> > > about Common Lisp (even the things that people tell you directly, that
> > > don't even require you to go the trouble of clicking a link), claiming
> > > you just know everything there is to know by virtue of your infallible
> > > logic. See how that doesn't work out?
> >
> > > #:foo is how you write a symbol named foo that isn't in any package.
> >
> > Not quite.
> >
> > The notation means that FOO doesn't have a home package, not that it isn't
> > present in any package.
> >
> > However, the situation of a symbol with no home package which is nevertheless
> > present in some packages is rare, and not easy to create. You see whenever a
> > ``homeless'' symbol is imported into a package, it is ``rehomed'' to that
> > package.
> >
> > So we have to enter a symbol into two packages, and then remove it
> > from its home one.
> >
> > Define a pkg package:
> >
> > [1]> (defpackage :pkg)
> > #<PACKAGE PKG>
> >
> > Intern a new symbol foo in pkg; pkg becomes its home package.
> >
> > [2]> (intern "FOO" :pkg)
> > PKG::FOO ;
> > NIL
> >
> > Import that symbol into the current package (cl-user):
> >
> > [3]> (import 'pkg::foo)
> > T
> >
> > Now blow it out of the pkg package, which is its home.
> > The symbol is now homeless.
> >
> > [4]> (unintern 'pkg::foo :pkg)
> > T
> >
> > Foo is still interned in the current package, and we can refer to it without
> > qualification. What is its print syntax?
> >
> > [5]> 'foo
> > #:FOO
> >
> > :)
>
> OHH, THANKS! Finally I learn something from this thread :D it HAD to
> be worth something!
> BTW, is it just me or we're (Seamus and I) destroying Google Groups?
> Better stop posting here ;)
*STACK OVERFLOW!* Google Groups is implemented in Python; send more SICP
books to Guido!
( http://twitter.com/gvanrossum/status/1838308947 )
..next up; discussion about TCO in (next) CL standard.
Lars Rune N�stdal wrote:
> On Fri, 2009-05-22 at 12:06 -0700, Alessio Stalla wrote:
>> On May 22, 7:42 pm, Kaz Kylheku <········@gmail.com> wrote:
>>> ["Followup-To:" header set to comp.lang.lisp.]
>>> On 2009-05-22, Paul Foley <····@below.invalid> wrote:
>>>
>>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>>> Not really. A statement separator is pretty obvious. Lisp just uses
>>>>> spaces as separators, so the #: prefix (not used much of anywhere
>>>>> else) remains mysterious.
>>>> It's mysterious /to you/ because you refuse to learn anything at all
This statement of Paul's is incorrect. Please don't quote it as if it
were truth.
>>>> #:foo is how you write a symbol named foo that isn't in any package.
>>> Not quite.
More internal disagreements. Please stop posting about me here and get
back to me when you've finally sorted yourselves out and can present a
coherent front in this debate.
>> BTW, is it just me or we're (Seamus and I) destroying Google Groups?
I most certainly am not, though I cannot of course vouch for anybody else.
> *STACK OVERFLOW!* Google Groups is implemented in Python; send more SICP
> books to Guido!
Incoherent.
Alessio Stalla wrote:
> On May 22, 7:42 pm, Kaz Kylheku <········@gmail.com> wrote:
>> ["Followup-To:" header set to comp.lang.lisp.]
>> On 2009-05-22, Paul Foley <····@below.invalid> wrote:
>>
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>> Not really. A statement separator is pretty obvious. Lisp just uses
>>>> spaces as separators, so the #: prefix (not used much of anywhere
>>>> else) remains mysterious.
>>> It's mysterious /to you/ because you refuse to learn anything at all
This statement of Paul's is incorrect. Please don't quote it as if it
were truth.
>>> about Common Lisp (even the things that people tell you directly, that
>>> don't even require you to go the trouble of clicking a link), claiming
>>> you just know everything there is to know by virtue of your infallible
>>> logic. See how that doesn't work out?
>>> #:foo is how you write a symbol named foo that isn't in any package.
>> Not quite.
More internal disagreements. Please stop posting about me here and get
back to me when you've finally sorted yourselves out and can present a
coherent front in this debate.
> OHH, THANKS! Finally I learn something from this thread :D it HAD to
> be worth something!
> BTW, is it just me or we're (Seamus and I) destroying Google Groups?
I certainly am not. I couldn't venture to guess whether you are.
Kaz Kylheku wrote:
> On 2009-05-22, Paul Foley <···@below.invalid> wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>> Not really. A statement separator is pretty obvious. Lisp just uses
>>> spaces as separators, so the #: prefix (not used much of anywhere
>>> else) remains mysterious.
>> It's mysterious /to you/ because you refuse to learn anything at all
This statement of Paul's is incorrect. Please don't quote it as if it
were truth.
>> #:foo is how you write a symbol named foo that isn't in any package.
>
> Not quite.
More internal disagreements. Please stop posting about me here and get
back to me when you've finally sorted yourselves out and can present a
coherent front in this debate.
> [technical stuff not relevant to Java vs. Lisp]
Paul Foley (http://public.xdi.org/=pf) wrote:
> Kaz Kylheku <········@gmail.com> writes:
>
>> ["Followup-To:" header set to comp.lang.lisp.]
>> On 2009-05-22, Paul Foley <···@below.invalid> wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>
>>>> Not really. A statement separator is pretty obvious. Lisp just uses
>>>> spaces as separators, so the #: prefix (not used much of anywhere
>>>> else) remains mysterious.
>>> It's mysterious /to you/ because you refuse to learn anything at all
This statement of yours is incorrect.
>>> #:foo is how you write a symbol named foo that isn't in any package.
>> Not quite.
More internal disagreements. Please stop posting about me here and get
back to me when you've finally sorted yourselves out and can present a
coherent front in this debate.
>> Foo is still interned in the current package, and we can refer to it without
>> qualification. What is its print syntax?
>
> But we're not talking about its PRINT syntax, we're talking about its
> READ syntax (which is different for precisely the reason you mention:
> you can get symbols that print as #:foo that are accessible from a
> package, but /reading/ #:foo will always make a fresh uninterned symbol)
What a mess!
Seamus MacRae wrote:
> Adlai wrote:
>> On May 22, 12:23 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Alessio Stalla wrote:
>>>> On May 20, 10:01 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> Alessio Stalla wrote:
>>>>>> On May 20, 7:07 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>>> Alessio Stalla wrote:
>>>>>>>> What if the package system scoped generic "names", and those
>>>>>>>> "names"
>>>>>>>> could be used to refer to verbs, nouns, pronouns, etc. etc.?
>>>>>>> That would be even worse: not only would methods and classes both
>>>>>>> have
>>>>>>> to be scoped, so thing.method() would have to have two scopes
>>>>>>> decided
>>>>>>> somehow (and the type of "thing" cannot be a factor in
>>>>>>> compile-time name
>>>>>>> resolution, since as far as the compiler is concerned it could be
>>>>>>> anything), but method names and class names could now collide
>>>>>>> with one
>>>>>>> another, and possibly with other things too!
>>>>>> They don't
>>>>> Sure they do. Either two identical names collide, or they reside in
>>>>> distinct namespaces. You just insinuated that methods and classes
>>>>> do not
>>>>> reside in distinct namespaces (quoted material, very top of this
>>>>> post).
>>>>> Therefore if one of each with the same name resides in a single one,
>>>>> they collide. It's elementary logic, Alessio.
>>>> Do a field named foo and a method named foo in the same class collide
>>>> in Java? No.
>>> Because they reside in different namespaces. Java doesn't just consider
>>> them both "symbols" and throw them together into a single namespace;
>>> instead, it creates separate ones within the class for fields and for
>>> methods.
>>
>> By saying that, you reveal your ignorance
>
> That's it. I've had enough of being insulted every time I open my mouth.
>
> Fuck you!
>
> The truly egregious thing here is that I quite clearly know a LOT more
> about Java than you do, and you even attack me for my statements about
> Java.
>
> I don't think you're here to debate Lisp anymore. You're here to flame
> people and be generally boorish in public. The only question is: why?
>
> It does not matter. I deserve to be treated with a modicum of respect.
You have made a fool out of yourself. Don't blame others for that.
> People will stop criticizing me and confine their discussions to the
> programming languages under discussion here. The subject "Seamus MacRae"
> is off-topic. Got it?
This is usenet.
You can not tell people what to do. Well you can, but it does not matter.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Adlai wrote:[snip]
How is anything that I have said in response to Adlai any of your concern?
>> It does not matter. I deserve to be treated with a modicum of respect.
>
> You have made a fool out of yourself.
That is not treating me with respect. That is launching another insipid,
pointless, and irrelevant personal attack into this Java versus Lisp
debate. Not only that, you couldn't even be arsed to be original.
>> People will stop criticizing me and confine their discussions to the
>> programming languages under discussion here. The subject "Seamus
>> MacRae" is off-topic. Got it?
>
> This is usenet.
Irrelevant.
On May 22, 11:23 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Sure they do. Either two identical names collide, or they reside in
> >> distinct namespaces. You just insinuated that methods and classes do not
> >> reside in distinct namespaces (quoted material, very top of this post).
> >> Therefore if one of each with the same name resides in a single one,
> >> they collide. It's elementary logic, Alessio.
>
> > Do a field named foo and a method named foo in the same class collide
> > in Java? No.
>
> Because they reside in different namespaces. Java doesn't just consider
> them both "symbols" and throw them together into a single namespace;
> instead, it creates separate ones within the class for fields and for
> methods.
>
> However, an earlier poster said that Common Lisp just considers method
> names and the like to be "symbols" and throws them all together into a
> single namespace per package.
That was me.
> If that earlier poster was incorrect, take it up with him. Attacking me
> for simply quoting him is pointless, rude, and should make you feel
> guilty now that you realize the attack was aimed at the wrong target and
> you just smacked an innocent bystander for someone else's offense.
The earlier post WAS correct.
(symbol-package my-package:my-symbol) ==> #<package "MY-PACKAGE">
;my-symbol is in my-package
(boundp 'my-package:my-symbol) ==> T
;my-package:my-symbol names a variable
(fboundp 'my-package:my-symbol) ==> T
;my-package:my-symbol names a function (it's "fbound")
(find-class 'my-package:my-symbol) ==> #<standard-class MY-PACKAGE:MY-
SYMBOL>
;my-package:my-symbol names a class
And, no clashes!!
(let ((my-package:my-symbol ;variable
(make-instance 'my-package:my-symbol))) ;class
(my-package:my-symbol 42)) ;function
The meaning of a symbol is apparent from the context. Yet there is a
single namespace, the package. Actually the mapping is:
string --> symbol --> denoted object
string --> symbol lookup is done using a package (single namespace)
symbol --> denoted object lookup is done implicitly by the Lisp
implementation, or explicitly by the programmer using certain
functions or special operators (e.g. find-class above); if you like to
think like that, there are multiple namespaces here (one for
variables, one for classes, one for functions and macros, ...)
> >>>>> the method MY:frobnodicate(YOUR:quux) which is different from
> >>>>> the method YOUR:frobnodicate(MY:quux) which is different from
> >>>>> the method YOUR:frobnodicate(YOUR:quux)
> >>>> The methods, yes. It's the little bit of code containing the dispatch
> >>>> table that concerns me.
> >>>> Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobdicate, for example.
> >>> Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which may
> >>> or may not make sense depending on what MY:frobnobdicate and YOUR:quux
> >>> mean.
> >> In your example, though, this combination was used, along with all three
> >> other combinations of whose frobnobdicate and whose quux.
>
> > My example was meant to show all the possible combinations, not
> > suggest they usually are all used.
>
> Well, I was simply considering the possibility that they ARE all used,
> and it seems that using two of them causes problems.
I don't think it can cause any problem whatsoever. If you think
otherwise, make an example showing how it causes problems.
> >>> it probably does not make much sense to do
> >>> (defmethod db-library:open-transaction ((transaction-manager picture-
> >>> library:jpeg-picture)) ...whatever...)
> >> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>
> > See the parameter name - it's transaction-manager.
>
> What parameter name? All I see is a list of arguments. A
> transaction-manager and a picture-library might conceivably both be
> arguments to the same call.
Others have explained it to you already. Still, I said it's a
parameter name, and I know Lisp better than you - why do you doubt of
every single thing people say to you?
> >>> Which, due to the generality of symbols,
> >>> automatically can make private/public anything - classes, functions,
> >>> variables, anything that can be named by a symbol.
> >> But only at the granularity of whole packages. Not single classes or
> >> smaller scales, aside from what Series elsewhere described as the
> >> "natural encapsulation" of functions whereby ordinarily changes to the
> >> function's body that don't change its signature or semantics don't break
> >> code elsewhere in the program.
>
> > The "natural encapsulation" is only natural in Java, C++ and languages
> > with a similar kind of OO. It's not the only possibility. In Lisp, the
> > natural encapsulation is at the package level
>
> My point was that Lisp's encapsulation granularity is much fucking
> coarser!! Are you fucking dense?
If I use the "private" symbol P::X, this means that anything named
P::X is private: the CLASS P::X, the VARIABLE P::X, the FUNCTION P::X.
If I use the "public" symbol P:X, this means that anything named P:X
is public: the CLASS P:X, the VARIABLE P:X, the FUNCTION P:X.
How is this "much ****ing coarser" than Java? Sure, I can't have
function X private and class X public. In practice this has never been
a problem for me, since classes tend to have different names than
functions.
Besides that, what can you express in Java that you cannot in Common
Lisp?? (apart from the fact CL has no "protected")?
public class, public method --> class name and generic function name
are exported symbols
public class, private method --> class name exported symbol, gf name
unexported symbol
public class, private field --> class name exported symbol, slot name
unexported symbol
private class, public method --> class name unexported symbol, gf name
exported symbol
etc...
> >>>>> In Lisp you have
> >>>>> package.symbol
> >>>>> and stop. This means there's no difference between
> >>>>> package.className and
> >>>>> package.genericFunctionName
> >>>> That's when you're referring to just one of those. I'm discussing the
> >>>> commonplace situation when you're referring to one of each. Then you
> >>>> need to specify 2 packages. Somehow.
> >>> You *need* to specify 2 packages only if you have imported *neither*
> >>> symbol in your package, which is quite unusual. Else, you can use
> >>> symbols unqualified, and this is the general case.
> >> Verb collisions are the issue. So many things will have close methods,
> >> for example. If you use several of them in one area, you'll only be able
> >> to import one and you'll have to FQ the others. Unless of course the
> >> library designer did as someone else recently suggested here and cracked
> >> open his thesaurus. (Yuk.)
>
> > Sure, this is a possible problem.
>
> Thank you for admitting the truth at last.
>
> > I know you probably won't believe me, but it does not happen frequently
>
> Ridiculous.
Why?
> > no more than it happens in Java with two classes of the same name.
>
> There are only a few class collisions in Java's standard library. I've
> mentioned javax.sql.Date and java.util.Date before.
There are no symbol collisions in CL's standard. There are maybe a few
in CL libraries, but I can't recall any (except in those libraries
that provide a replacement for some standard operator, but in that
case the "clash" is desired).
> If methods could collide, there'd be 17,392 collisions of them (counting
> N of the same name as N^2 collisions; if N-1, it's "only" a couple
> thousand; in neither case counting polymorphic overrides as colliding
> with the overridden version(s)). The names "close", "dispose", "next",
> "readResolve", and "writeExternal" are particular culprits.
You can't avoid to think in Java, can't you? Sure, if suddenly in Java
we removed the namespaces created by classes, and put all methods in a
single namespace, then there would be a lot of collisions. But CL IS
NOT JAVA and IT WORKS DIFFERENTLY. Namespaces in CL ARE NOT TIED TO
CLASSES. So the generic function "close" HAS THE SAME NAME (no
conflict!) FOR ANY CLASS FOR WHICH IT IS APPLICABLE.
close(file), close(socket), close(string-output-stream) BELONG ALL TO
THE SAME GENERIC FUNCTION and HAVE THE SAME NAME, so THERE IS NO
COLLISION WHATSOEVER. Is that clear? Sorry for "shouting", but I
really don't know how to explain it to you, yet it seems simple to me.
> Stick THAT in your pipe and smoke it.
>
> >>> Guess what? It has, it's the class named T.
> >> They have a problem with code readability or something? That reads like
> >> true, a temporary, or, worst, a generic type parameter, not a class name.
>
> > T is the canonical way to represent true. Historically it has also
> > been used to designate the root of the type hierarchy - the type of
> > all objects - and naturally it has been used to designate the root of
> > the class hierarchy, too. Don't ask me why. Surely it does no harm :)
>
> This is what lack of a REAL type system gets you: one object doing
> triple, quadruple, even quintuple duty. Jack of all trades, master of
> none. (This last can also be a criticism of emacs.)
T is one NAME with multiple meanings.
> >>> Nobody mentioned method combinations, and I won't now - already too
> >>> many things being discussed - but that's another of the big strengths
> >>> of CLOS.
> >> I'll interpret this as "another of the big headaches of CLOS". It sounds
> >> like one of the biggest headaches of Lisp is the sheer amount of stuff,
> >> special forms, &c. that you'd have to learn to be able to read other
> >> peoples' code written in the stuff. OK, perl is much worse, but still.
>
> > No comment.
>
> As damning as when the same line is spoken on TV by a politician. :)
>
> > Heh, Graphics2D is really an example of what I was saying :) it has
> > drawPolygon, drawOval, drawText, and a few other drawSomething. What
> > if I wanted it to draw the cool chart generated by my favourite
> > library?
>
> The chart would be an instance of some class, say Chart, implementing
> the other interface, the one with a drawOn(Graphics2D) method specified.
> The drawOn() method would call the Graphics2D methods. Code that wanted
> to draw a chart on a Graphics2D would call the chart's drawOn() method
> with the appropriate parameter. Different chart instances would produce
> different drawings.
So while I can drawRect() and drawCircle(), I can't drawChart() but I
have to use a workaround, Chart.drawOn(graphics). And if I want drawOn
(graphics) be the common way of doing drawing, I need ALL objects that
can be drawed implement the Drawable interface. Unfortunately it's
unlikely I'll ever have control on ALL classes that can be drawed...
So I end up having "primitive" drawXXX on Graphics,
com.mypackage.Drawable.drawOn(Graphics),
com.yourpackage.DrawableObject.draw(Graphics), and so on. Instead in
Lisp I can have
(draw object graphics) and stop - if I want to draw a new kind of
object, I'll write the appropriate method for the draw generic
function.
> >>>>> But if you confuse your personal preference with objective
> >>>>> truth, and write that "truth" in public, I - we - feel the need to
> >>>>> correct your claims.
> >>>> That statement makes several insulting and false insinuations about me.
> >>> I'm sorry, but I genuinely think [repeats insults]
> >> Think what you want, but please restrain the urge to blurt out uncivil
> >> things in public. Weren't you taught any manners as a child?
>
> > I don't think
>
> That needs rectifying right away, then.
>
> >>>> Since there aren't separate "base" and "derived" generic functions in
> >>>> Lisp, however, the above does not apply there, and the "base itself" IS
> >>>> changed.
> >>>> Uh-oh.
> >>> *in this context*, the following analogy more or less holds:
> >>> generic function --> abstract class
> >>> method --> concrete class
> >>> more specific method --> concrete subclass
> >> Except when you subclass a class, you're making an altered copy in
> >> essence; when you add to a generic method, you're fiddling with the
> >> original, not a copy, and maybe it wasn't "yours".
>
> >> See above re: MY:frobnobdicate with YOUR:quux.
>
> > If I write MY:frobnobdicate specialized on YOUR:quux, I'm not altering
> > the behavior of MY:frobnobdicate specialized on other objects.
>
> Cop-out. Are you or are you not altering MY:frobnobdicate?
>
> > I'm adding a possibility, not changing behavior.
>
> You are changing behavior. Suppose I had code that passed a quux
> superclass object around, gotten from somewhere, and called
> MY:frobnobdicate on it? Add the quux class and pass one to my code, and
> its behavior changes. Not because you subclassed my class to make quux
> and put a polymorphic method in YOUR:quux but because you subclassed by
> class to make quux and put a polymorphic method in MY:frobnobdicate!
>
> See the difference? In Java you put the method in your own class. In
> Lisp you put it in MY generic function. Mine, I tell you, mine!
In Java I really put MY method in the dispatch table of YOUR
superclass. This is the analogy I'm making. If this is not modifying
the class, then it is not modifying the generic function.
To be clearer: object.method(...args...) in Java is like (generic-
function object ...args...) in Lisp (not considering single/multiple
dispatch). Adding a subclass in Java that overrides the method IS
EXACTLY LIKE adding a method in Lisp specialized on the subclass. It's
the very same thing.
> This seems a minor wart. Until you have experience working in a large
> development effort with many many people involved, and this inability to
> fence off parts of things goes from wart to colossal headache.
>
> > In pseudo-Java:
>
> [snip]
>
> Poor analogy. Once again, you are subclassing under a new name instead
> of changing the original. Because that's what Java does. It supports
> exactly the kind of modularization and localization of code changes that
> Lisp doesn't.
>
> >>> The generic function is not changed any more than the abstract class
> >>> is.
> >> Sure it is. The abstract class still contains exactly the same methods.
> >> The generic function contains new ones. Viewing both as lists, one grew
> >> and one didn't.
>
> > Viewing one as a list and the other as a tree (class hierarchy)
>
> A simple strategy: when an apples-to-apples comparison makes your side
> look bad, rebut by comparing apples to oranges instead!
imho my comparison is more correct than yours.
> >>> That's subjective, and I won't debate it here. I prefer the there's-
> >>> more-than-one-way-to-do-it philosophy, but it's just personal
> >>> preference.
> >> It's a preference that suggests you tend to work alone or on a small
> >> team. Working on a large team results in there's-too-many-ways-to-do-it
> >> being a very real possibility, with everyone doing the same "it"
> >> differently and everyone having to know every single language feature,
> >> however obscure.
>
> > there's-only-one-way-and-it-is-not-optimal is a real possibility, too.
>
> That's why it's better to find a happy middle:
>
> too few ways too many ways
> BASIC FORTRAN Pascal Java C++ Lisp perl
>
> >> Without the javadocs Java's standard library might plausibly have caused
> >> some trouble of a similar nature by its sheer size. It helps though that
> >> there's generally only one or a few clearly-near-optimum use patterns
> >> for a given job, and that everything (mostly) has descriptive names too.
> >> ListIterator and MessageDigest are names that convey quite a bit about
> >> what they do; defgeneric and #:cl #:foo somewhat less so. :)
>
> > defgeneric DEFines a GENERIC function.
> > cl is shorthand for common-lisp, and foo... well, it's foo :)
>
> I know this. The point is, the names are less SELF-explanatory. (And you
> omitted to state what the #: bit is for the latter.)
#: is read syntax that makes the symbol not being interned in any
package.
> >>>>>>> Well, we think that there is a fundamental difference between different
> >>>>>>> sorts of close and prefer to make sure they have different names.
> >>>>>> So instead of everything you can "close" having a "close" method, you
> >>>>>> end up "close"ing one type, "shut"ting another, "slam"ming a third,
> >>>>>> "plug"ging a fourth, and onward to increasingly unintuitive and
> >>>>>> unguessable names? Wow, that must REALLY help code readability.
> >>>>> No.
>
> I had been being sarcastic about code readability.
>
> [quite a lot of untrimmed-but-unused quoted material now trimmed]
>
> >> I actually don't think most people here disagree with my main thesis,
> >> which is that Java and Lisp have relative tradeoffs, with neither
> >> invariably superior to the other. The sticking points all seem to
> >> involve specific things claimed to make Lisp superior at one time or
> >> another by only a handful of the most extreme pro-Lisp partisans, and
> >> why these features don't *actually* do so.
>
> > Mind you, I usually refrain from saying something is absolutely
> > "superior" because there are really many dimensions to be considered
>
> Good good.
>
> > but
>
> Ah, there's always a "but", isn't there?
>
> > I do think [subjective opinions and stuff]
>
> Which I'm sure are absolutely fascinating, but which prove nothing in
> this debate.
Ok, that's fair.
> > I also think Java has a lot of nice features which probably many
> > lispers don't know about. Built-in serialization is one of those, for
> > example, as is the nice integration of URLs into the language, the
> > collections framework, ...
>
> The URLs leave a thing or two to be desired. For one thing they're not
> integrated, there's just a standard library class for 'em, and OOTB it
> only works with HTTP and one or two other things, one their own
> Java-specific jar: protocol.
Can't your register custom protocol handlers? If you can't, then Java
really sucks! :D
> I don't think they should be integrated more than that, mind you, but
> there's some warts, like MalformedURLException's handling (and more
> generally, illegal argument exceptions should not be checked
> exceptions!) and some awkwardness with certain patterns of use. Just
> constructing a URL triggers some behavior beyond mere construction,
> unlike a File abstract pathname object, which I disagree with.
> Constructors that do more than construct are evil.
>
> > Maybe that's the reason I'm using, and sometimes contributing to, a
> > Lisp implementation running on the JVM... :)
>
> Clojure?
No, ABCL.
Alessio Stalla wrote:
> On May 22, 11:23 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Sure they do. Either two identical names collide, or they reside in
>>>> distinct namespaces. You just insinuated that methods and classes do not
>>>> reside in distinct namespaces (quoted material, very top of this post).
>>>> Therefore if one of each with the same name resides in a single one,
>>>> they collide. It's elementary logic, Alessio.
>>> Do a field named foo and a method named foo in the same class collide
>>> in Java? No.
>> Because they reside in different namespaces. Java doesn't just consider
>> them both "symbols" and throw them together into a single namespace;
>> instead, it creates separate ones within the class for fields and for
>> methods.
>>
>> However, an earlier poster said that Common Lisp just considers method
>> names and the like to be "symbols" and throws them all together into a
>> single namespace per package.
>
> That was me.
So now you're disagreeing with *yourself*? Well, I guess you might
sometimes change your mind about one of these things, but still, the
timing in this case was atrocious!
>> If that earlier poster was incorrect, take it up with him. Attacking me
>> for simply quoting him is pointless, rude, and should make you feel
>> guilty now that you realize the attack was aimed at the wrong target and
>> you just smacked an innocent bystander for someone else's offense.
>
> The earlier post WAS correct.
But it wasn't. Or else the later one wasn't correct. You can't have it
both ways! Either they all go into one name-resolution pool or they
don't; they can't both do so and not do so at the same time.
> And, no clashes!!
So, the earlier post WAS incorrect.
> The meaning of a symbol is apparent from the context. Yet there is a
> single namespace, the package.
Not consistent. Either the former or the latter is false. I think you
have package and namespace confused, and the package actually has a
separate namespace in it for each of several kinds of thing. In other
words, it doesn't just have symbols, it has methods separate from
variables separate from classes etc.; it has some notion of which of
these is which and keeps them tidy.
> there are multiple namespaces here (one for
> variables, one for classes, one for functions and macros, ...)
An admission of the truth at last?
>>>>>>> the method MY:frobnodicate(YOUR:quux) which is different from
>>>>>>> the method YOUR:frobnodicate(MY:quux) which is different from
>>>>>>> the method YOUR:frobnodicate(YOUR:quux)
>>>>>> The methods, yes. It's the little bit of code containing the dispatch
>>>>>> table that concerns me.
>>>>>> Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobdicate, for example.
>>>>> Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which may
>>>>> or may not make sense depending on what MY:frobnobdicate and YOUR:quux
>>>>> mean.
>>>> In your example, though, this combination was used, along with all three
>>>> other combinations of whose frobnobdicate and whose quux.
>>> My example was meant to show all the possible combinations, not
>>> suggest they usually are all used.
>> Well, I was simply considering the possibility that they ARE all used,
>> and it seems that using two of them causes problems.
>
> I don't think it can cause any problem whatsoever.
By "problems" in this instance I meant scoping headaches for the
programmer, rather than actual failures of the code.
>>>>> it probably does not make much sense to do
>>>>> (defmethod db-library:open-transaction ((transaction-manager picture-
>>>>> library:jpeg-picture)) ...whatever...)
>>>> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>>> See the parameter name - it's transaction-manager.
>> What parameter name? All I see is a list of arguments. A
>> transaction-manager and a picture-library might conceivably both be
>> arguments to the same call.
>
> Others have explained it to you already. [more condescension in this vein]
How rude.
>>> The "natural encapsulation" is only natural in Java, C++ and languages
>>> with a similar kind of OO. It's not the only possibility. In Lisp, the
>>> natural encapsulation is at the package level
>> My point was that Lisp's encapsulation granularity is much fucking
>> coarser!! Are you fucking dense?
>
> If I use the "private" symbol P::X, this means that anything named
> P::X is private: the CLASS P::X, the VARIABLE P::X, the FUNCTION P::X.
Oh God, it just gets worse and worse! Now you say your system's bollixed
up enough that you can't even have, say, a private variable named foo
and a public method named foo in the same place? Who thought this up?
Why would you make private apply to everything of the same NAME,
regardless of whether that name was overloaded? Why?
Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
end of the matter. There's really little point in continuing this.
> How is this "much ****ing coarser" than Java?
It's spelled "fuck". With an F.
> Sure, I can't have function X private and class X public.
Let's tick things off shall we? One. More. Time.
1. Your module size is like in C, a few per program (plus libraries'),
rather than like Java or even C++, one per class.
Imagine C++ only with "private" visible to everything in the same
.cc file, or all pairs of classes in a single source file implicitly
mutual "friends".
2. The encapsulation is extremely weak even so. Not only can you
circumvent it by adding a single colon to a scope operator somewhere,
a) it's right next to another colon, so an easy typo to make simply
by bouncing a key; b) you can presumably automate even the one lousy
extra colon using a macro; and c) it will look enough like normal to
be easily overlooked and mistaken for innocent code, unlike, say,
Java reflection and setAccessible(true) calls. Heck you can even get
your Java IDE to find all setAccessible calls on reflection API
objects without false positives and throughout the code base, if your
IDE is decent enough. Meanwhile :: is a search that will have false
positives I guarantee it. All two-or-less-character searches do.
> Besides that, what can you express in Java that you cannot in Common
> Lisp?? (apart from the fact CL has no "protected")?
Technically nothing since they're both Turing complete. But much that is
decent and good in Java would require implementing a Java emulator in CL
to get in CL. (The JVM spec is readily available, so this should be
trivial right?)
Class-granular "private" comes to mind in particular.
>>> I know you probably won't believe me, but it does not happen frequently
>> Ridiculous.
>
> Why?
Should be obvious to most people. Can't be bothered to try to explain
it, given that.
>>> no more than it happens in Java with two classes of the same name.
>> There are only a few class collisions in Java's standard library. I've
>> mentioned javax.sql.Date and java.util.Date before.
>
> There are no symbol collisions in CL's standard. There are maybe a few
Always the one-upmanship with you, isn't it?
>> If methods could collide, there'd be 17,392 collisions of them (counting
>> N of the same name as N^2 collisions; if N-1, it's "only" a couple
>> thousand; in neither case counting polymorphic overrides as colliding
>> with the overridden version(s)). The names "close", "dispose", "next",
>> "readResolve", and "writeExternal" are particular culprits.
>
> You can't avoid to think
This isn't about me, it's about the code. Please leave your personal
criticisms of me at the door and focus on the actual topic here. Thank you.
> CL IS NOT JAVA and IT WORKS DIFFERENTLY.
Exactly my point. It works differently, and in this case, differently =
worse. Now every unrelated pair of "close" methods collides, unless you
start being creative with your thesaurus, and then code gets less
readable and there's more and harder memorization to learn to use the
darn thing.
> close(file), close(socket), close(string-output-stream) BELONG ALL TO
> THE SAME GENERIC FUNCTION
The one for iostreams.
What about closing windows? Oops, no windows, forgot. :P Well, I'll
think of *something*...
> Sorry for "shouting"
No you're not, not one damn bit.
> I really don't know how to explain it to you, yet it seems simple to
> me.
I'm sure the guys down at Bellevue that think they're Napoleon think the
same thing when they try to get people to believe them.
>>>>> Guess what? It has, it's the class named T.
>>>> They have a problem with code readability or something? That reads like
>>>> true, a temporary, or, worst, a generic type parameter, not a class name.
>>> T is the canonical way to represent true. Historically it has also
>>> been used to designate the root of the type hierarchy - the type of
>>> all objects - and naturally it has been used to designate the root of
>>> the class hierarchy, too. Don't ask me why. Surely it does no harm :)
>> This is what lack of a REAL type system gets you: one object doing
>> triple, quadruple, even quintuple duty. Jack of all trades, master of
>> none. (This last can also be a criticism of emacs.)
And we can always use more criticism of emacs. Right, guys?
>>> Heh, Graphics2D is really an example of what I was saying :) it has
>>> drawPolygon, drawOval, drawText, and a few other drawSomething. What
>>> if I wanted it to draw the cool chart generated by my favourite
>>> library?
>> The chart would be an instance of some class, say Chart, implementing
>> the other interface, the one with a drawOn(Graphics2D) method specified.
>> The drawOn() method would call the Graphics2D methods. Code that wanted
>> to draw a chart on a Graphics2D would call the chart's drawOn() method
>> with the appropriate parameter. Different chart instances would produce
>> different drawings.
>
> So while I can drawRect() and drawCircle(), I can't drawChart() but I
> have to use a workaround, Chart.drawOn(graphics).
That's not a workaround. We can also have Circle.drawOn, Rect.drawOn,
etc. if we want to be able to do them all consistently. Or we can add a
generic draw() to Graphics2D that takes a Drawable and just calls
argument.drawOn(this). (Assuming we control Graphics2D.) Then you can
happily do graphics.draw(chart).
> I need ALL objects that can be drawed implement the Drawable
> interface. Unfortunately it's unlikely I'll ever have control on ALL
> classes that can be drawed...
Why? You're the one designing the system, hypothetically.
> So I end up having "primitive" drawXXX on Graphics,
> com.mypackage.Drawable.drawOn(Graphics),
> com.yourpackage.DrawableObject.draw(Graphics), and so on.
Why? The system's designed would make Drawable public, and an interface
so any class could implement it regardless of constraints on its superclass.
> Instead in
> Lisp I can have
> (draw object graphics) and stop - if I want to draw a new kind of
> object, I'll write the appropriate method for the draw generic
> function.
The cost of having this is that you can change someone else's code, and
even are encouraged to. If they didn't make their class Drawable, why,
you'll just do it for them!
If someone did that to one of my Java classes, it would annoy me. Hello,
compatibility headaches, now there's more than one incompatible version
out there.
[some quoted material dropped that wasn't replied to -- please trim
more, your posts are very long and slow to load]
>>> I'm adding a possibility, not changing behavior.
>> You are changing behavior. Suppose I had code that passed a quux
>> superclass object around, gotten from somewhere, and called
>> MY:frobnobdicate on it? Add the quux class and pass one to my code, and
>> its behavior changes. Not because you subclassed my class to make quux
>> and put a polymorphic method in YOUR:quux but because you subclassed by
>> class to make quux and put a polymorphic method in MY:frobnobdicate!
>>
>> See the difference? In Java you put the method in your own class. In
>> Lisp you put it in MY generic function. Mine, I tell you, mine!
>
> In Java I really put MY method in the dispatch table of YOUR
> superclass.
Not explicitly! And not really at all; the classloader builds up a
dispatch table at runtime.
> This is the analogy I'm making.
And I'm telling you, it doesn't quite work.
> Adding a subclass in Java that overrides the method IS
> EXACTLY LIKE adding a method in Lisp specialized on the subclass. It's
> the very same thing.
NO, IT ISN'T! If you still don't understand why I'm afraid you never
will. It's time to drop this line of debate.
>>>>> The generic function is not changed any more than the abstract class
>>>>> is.
>>>> Sure it is. The abstract class still contains exactly the same methods.
>>>> The generic function contains new ones. Viewing both as lists, one grew
>>>> and one didn't.
>>> Viewing one as a list and the other as a tree (class hierarchy)
>> A simple strategy: when an apples-to-apples comparison makes your side
>> look bad, rebut by comparing apples to oranges instead!
>
> imho my comparison is more correct than yours.
I once knew a guy who was of the opinion that the earth was flat.
>>>> Without the javadocs Java's standard library might plausibly have caused
>>>> some trouble of a similar nature by its sheer size. It helps though that
>>>> there's generally only one or a few clearly-near-optimum use patterns
>>>> for a given job, and that everything (mostly) has descriptive names too.
>>>> ListIterator and MessageDigest are names that convey quite a bit about
>>>> what they do; defgeneric and #:cl #:foo somewhat less so. :)
>>> defgeneric DEFines a GENERIC function.
>>> cl is shorthand for common-lisp, and foo... well, it's foo :)
>> I know this. The point is, the names are less SELF-explanatory. (And you
>> omitted to state what the #: bit is for the latter.)
>
> #: is read syntax that makes the symbol not being interned in any
> package.
"Read syntax"?
>>> I also think Java has a lot of nice features which probably many
>>> lispers don't know about. Built-in serialization is one of those, for
>>> example, as is the nice integration of URLs into the language, the
>>> collections framework, ...
>> The URLs leave a thing or two to be desired. For one thing they're not
>> integrated, there's just a standard library class for 'em, and OOTB it
>> only works with HTTP and one or two other things, one their own
>> Java-specific jar: protocol.
>
> Can't your register custom protocol handlers? If you can't, then Java
> really sucks! :D
Of course you can, but since they don't come with the standard library,
you need to either reinvent them or dredge one up somewhere. And then
the licensing fun begins. Even with open source, there's various
sometimes-incompatible licenses. There are even pairs of licenses in the
FSF's own GPL family of licenses that can't be used together. Sometimes
there are attribution clauses, and those create scaling problems.
(Consider that work is typically built on previous work. Suppose a work
always built on three earlier works, except for first-generation works,
and acknowledgement was required. First generaton works have 0
attributions. Second tend to have 3. Third, 3x3 + 3 = 12. Fourth, 12x3 +
3 = 39. Fourth, 120. Fifth, 363. Sixth, 1095. Whoa, over a thousand
already! The credits list is gonna be as long as at the end of Revenge
of the Sith on those sixth-generation works... The exact numbers don't
matter, just that whatever they are they'll increase exponentially.)
>>> Maybe that's the reason I'm using, and sometimes contributing to, a
>>> Lisp implementation running on the JVM... :)
>> Clojure?
>
> [calls me a liar]
Oh, nice. :P
On May 22, 9:02 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
> end of the matter. There's really little point in continuing this.
I doubt it. You don't have the discipline not to continue it.
> Let's tick things off shall we? One. More. Time.
Again, I doubt the "One. More. Time." aspect. It's been pretty
obvious for a long time that you don't know Lisp, and you yourself
have stated that you don't care about learning it. This thread has
not been about Lisp or Java for a very long time. Instead, it's been
about control, and your attempt to control a conversation. But the
joke's on you; the control belongs to the others who answer your
posts. Here's why: everyone has a choice to answer or not answer your
posts. Many choose not to answer. A few do answer. However, you
have no choice; you are compelled to answer every post that you feel
is an insult to you. If you did have a choice, you would choose to
not answer some of these posts, but you can't do it. Therefore, it is
the others who control your behavior, and not the other way around.
Duane
·····@franz.com wrote:
> On May 22, 9:02 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
>> Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
>> end of the matter. There's really little point in continuing this.
>
> I doubt it.
Doubt the truth all you want; it won't change just to satisfy you.
> You don't have the discipline
I grow weary of being constantly insulted. If you have something to say
on the topic of Java vs. Lisp, then say it. If not, then kindly go away.
>> Let's tick things off shall we? One. More. Time.
>
> Again, I doubt the "One. More. Time." aspect.
Are you calling me a liar?
> It's been pretty obvious for a long time that you don't know
This has nothing to do with Java vs. Lisp.
> Instead, it's been about control, and your attempt to control
So, you are admitting that your real purpose in posting all of this
stuff is to have the last word? How childish of you.
> you would choose to not answer some of these posts
But doing so would be at the cost of leaving an incorrect negative
statement about me unchallenged as part of the public record. Surely you
can see how that might be a problem.
On May 22, 8:29 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> ·····@franz.com wrote:
> > On May 22, 9:02 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> >> Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
> >> end of the matter. There's really little point in continuing this.
>
> > I doubt it.
>
> Doubt the truth all you want; it won't change just to satisfy you.
It doesn't matter to me. It's not "truth" anyway, since you're
continuing to demonstrate that you have no discipline to bite the
bullet and not answer. You're being controlled by your need to appear
correct, and because of that, the rest of the responders on this
thread control you.
> > You don't have the discipline
>
> I grow weary of being constantly insulted. If you have something to say
> on the topic of Java vs. Lisp, then say it. If not, then kindly go away.
There it is again. You have no control over yourself in having to
answer me, and you have no control over your insistence that everyone
act the way you want them to act. This is clearly foolish, because
you can't enforce that. Putting the "kindly" in there doesn't make it
a kind request.
> >> Let's tick things off shall we? One. More. Time.
>
> > Again, I doubt the "One. More. Time." aspect.
>
> Are you calling me a liar?
Of course not. Just foolish in the belief that you will only say a
thing once here. I think you truly believe that you will only have to
say something once (or at most one more time). But I also doubt that
it's true, because that's not how you work. You're not the first
person we've seen here that is not in control of himself, and it's
simply not the way such people react. It's also not a hard concept to
understand, because many people on the internet have had to deal with
the question of whether to continue responding or not. And you simply
haven't yet learned how to bite the bullet and not respond, even
though you might believe that misinformation is getting out because of
it. You're becoming frustrated with everyone else for spouting
misinformation, and you haven't learned that the best way to remove
the misinformation is to remove yourself from the conversation. It's
hard, but everyone must learn to do it at one time or another.
> > It's been pretty obvious for a long time that you don't know
>
> This has nothing to do with Java vs. Lisp.
Of course it does. Lisp is all about the meta-level, and this is a
meta-conversation, i.e. a conversation about the conversation. We
Lispers always love to talk meta.
But as I've said before, you've refused to learn Lisp, so you've never
really been talking about Lisp in the first place (and thus it has
never been a Java vs Lisp conversation).
> > Instead, it's been about control, and your attempt to control
>
> So, you are admitting that your real purpose in posting all of this
> stuff is to have the last word? How childish of you.
This doesn't follow. I'm only trying to help you. And I won't do it
for long. But even if it did follow, let's assume that I'm being
childish. Now, since you're so concerned about appearances, how does
it feel to know that you're being bested by a child?
> > you would choose to not answer some of these posts
>
> But doing so would be at the cost of leaving an incorrect negative
> statement about me unchallenged as part of the public record. Surely you
> can see how that might be a problem.
Of course I can see it, grasshopper. You must learn for yourself that
it is only in the giving up of control that you gain the control
again.
Duane
·····@franz.com wrote:
> On May 22, 8:29 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> ·····@franz.com wrote:
>>> On May 22, 9:02 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
>>>> end of the matter. There's really little point in continuing this.
>>> I doubt it.
>> Doubt the truth all you want; it won't change just to satisfy you.
>
> It doesn't matter to me.
Then why work so hard at it, posting here constantly to needle me and
say nothing constructive about either Java or Lisp?
> It's not "truth" anyway, since you're continuing to demonstrate that
> you have no discipline to bite the bullet and not answer.
I'm demonstrating nothing of the sort. Why should I wish to bite a
bullet? Firearm ammunition is not edible.
> You're being controlled by your need to appear correct
You are being controlled by your need to make others appear incorrect.
>>> You don't have the discipline
>> I grow weary of being constantly insulted. If you have something to say
>> on the topic of Java vs. Lisp, then say it. If not, then kindly go away.
>
> There it is again.
There what is? I made a polite request that you not continue to clutter
up two newsgroups with off-topic posts. Hardly unreasonable.
> your insistence that everyone act the way you want them to act.
My request that people abide by the charters of two newsgroups hardly
constitutes insistence on anything. It is simply a reminder of basic
netiquette, something you clearly lack experience of.
>>>> Let's tick things off shall we? One. More. Time.
>>> Again, I doubt the "One. More. Time." aspect.
>> Are you calling me a liar?
>
> Of course not. Just foolish in the belief that you will only say a
> thing once here.
Neither. At no time did I say that I would only say it once more. I said
that I would say it at least once more.
> I think you truly believe that you will only have to say something once
No, that I SHOULD only have to say something once. There really is no
point in one of you repeating something over and over again ad nauseam.
Once you have said it, you have said it.
> [a very long and dense paragraph of insulting and condescending
> material, none of which is remotely about Lisp OR Java, deleted]
You are wasting your time and our bandwidth, and, in particular, you are
not advancing your position with respect to Lisp's putative superiority
over Java.
You are fruitlessly spinning your wheels.
> You're becoming frustrated with everyone else for spouting
> misinformation, and you haven't learned that the best way to remove
> the misinformation is to remove yourself from the conversation.
This quite clearly cannot be correct. The only way to remove the
misinformation would be to destroy Google's servers, and their backup
tapes. It follows from the illegal, vandalous, and infeasible nature of
such a task that in practice one cannot remove it at all, and must
instead combat it in some other way, perhaps by spreading an equal and
opposite message, in some sense of the phrase "equal and opposite".
Removing myself from the conversation would only result in it continuing
"behind my back", as it were, hardly a desirable state of affairs from
my point of view.
> It's hard, but everyone must learn to do it at one time or another.
That is not your decision to make. It is an arrogant presumption of
yours to profess to have both the wisdom and the authority to dictate to
me what I "must" do, particularly when the evidence suggests instead
that you possess neither.
>>> It's been pretty obvious for a long time that you don't know
>> This has nothing to do with Java vs. Lisp.
>
> Of course it does.
No, it does not. Your recent posts have exclusively been about this
"controlling people" obsession of yours, which is a completely unrelated
topic. I shall add that that obsession seems unhealthy. Perhaps you'd be
more comfortable in a Communist country? I can recommend China as well
as North Korea, if people controlling people is what turns you on.
> We Lispers always love to talk meta.
Not everybody shares your fascination. Furthermore, even if this
justifies your posting of large volumes of off-topic material to
comp.lang.lisp, you shall have to search elsewhere for a justification
for posting it to comp.lang.java.programmer, and I suspect that your
search will be long and fruitless.
> But as I've said before, you've refused to learn Lisp
I've done nothing of the sort. I have in fact used Lisp in the past,
though not recently. Furthermore, I may well learn more about it and use
it again in the future. I have no particular intentions like that now,
but that is hardly a refusal of any kind, merely a possibly-temporary
lack of interest.
> it has never been a Java vs Lisp conversation
Google's archive of this thread should suffice to prove that statement
incorrect.
>>> Instead, it's been about control, and your attempt to control
>> So, you are admitting that your real purpose in posting all of this
>> stuff is to have the last word? How childish of you.
>
> This doesn't follow.
It certainly does. Your concern is clear: almost your every word part of
an attempt to convince me to stop posting. There are only three likely
goals of yours that a successful such attempt would aid you in
accomplishing:
1. To spread disinformation about me unopposed.
2. To have the last word.
3. To reduce the amount of off-topic material in comp.lang.lisp.
However, it is clear that posting to tell me, very elaborately, to shut
up is failing to achieve all three goals. Furthermore, you could make
greater progress with goal three by ceasing to reply to my posts than
you will by continuing to do so. If your goal were solely number three,
your strategy would therefore be different. It follows that your goals
include at least one of the first two items. If it includes item two,
we're done. If it includes item one, however, a closer examination of
the strategy is in order.
That goal, to spread disinformation about me unopposed, can be furthered
in two ways: one, by posting more disinformation, and two, by
obstructing efforts at opposition. Posting anything, including just
endless repetitions of "Seamus is an idiot", would suffice to apply
method one. Attempting to coax or coerce me into remaining silent falls
clearly within method two.
Success via method two takes the form of your posting something
disingenuous about me and my failing to reply to correct the inaccurate
portrayal. In other words, it takes the form of your getting the last
word. In other words, even if your primary aim is goal number one on
that list up there, goal number two is a secondary objective in
furtherance of goal number one.
From the above reasoning it is concluded that your goals include,
though perhaps are not limited to, having the last word.
> I'm only trying to help you.
Since your behavior is antagonistic and its effects upon me deleterious,
you'll pardon me if I don't believe you.
> Now, since you're so concerned about appearances, how does
> it feel to know that you're being bested by a child?
But I am not. If your aim is to have the last world, and you are a
child, then I would have been bested by a child only if you had
succeeded in having the last word. Thus far, nothing of the sort has
occurred and there is no indication at this time that it ever will.
Furthermore, you conflated the notion of your being childish with the
notion of your being a child. The two are not, however, identical.
>>> you would choose to not answer some of these posts
>> But doing so would be at the cost of leaving an incorrect negative
>> statement about me unchallenged as part of the public record. Surely you
>> can see how that might be a problem.
>
> Of course I can see it, grasshopper.
I am a vertebrate. Please be more careful in the future when making wild
guesses about an organism's phylogenetic status.
> You must learn for yourself that it is only in the giving up of
> control that you gain the control again.
This statement is illogical. I can only assume it stems from a system of
religious faith, or some similar world-view, given its clearly
irrational character and its resemblance to the tenets of the numerous
submission-oriented belief systems that were originally promulgated in
early agricultural civilizations and reached their peak during the
feudal period because they aided in the preservation of the power
structures of societies with those forms of organization, in which a
small number of despots maintained control over a large number of farm
laborers. Clearly such a society is rendered more stable by convincing
the laborers that they are better off submitting than attempting to
stage a revolution, particularly as they outnumber the overlords and
wield sharp objects in their day-to-day work. Thus the beliefs enabled
the societies that carried them to outcompete those that did not, and
those societies in turn propagated the beliefs further, a relationship
not unlike a host and symbiote in biology.
More egalitarian societies have no use for such belief systems, however,
and they are detrimental to human dignity, freedom from oppression,
egalitarian values, technological advancement, and industrial
productivity. As a result, they are themselves now being outcompeted.
I suggest, therefore, that you abandon yours as obsolete.
[I only have a couple of points I choose to answer here]
On May 22, 11:49 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> ·····@franz.com wrote:
...
> > You're becoming frustrated with everyone else for spouting
> > misinformation, and you haven't learned that the best way to remove
> > the misinformation is to remove yourself from the conversation.
>
> This quite clearly cannot be correct. The only way to remove the
> misinformation would be to destroy Google's servers, and their backup
> tapes. It follows from the illegal, vandalous, and infeasible nature of
> such a task that in practice one cannot remove it at all, and must
> instead combat it in some other way, perhaps by spreading an equal and
> opposite message, in some sense of the phrase "equal and opposite".
Yes, I must correct myself here; I was speaking as if to someone who
hadn't posted hundreds of messages to a newsgroup, and so I admit that
I am wrong about what can fix your reputation. It's the "equal and
opposite" part that is doing your reputation in. The sheer volume and
tenacity of your posts has soiled your reputation beyond repair, and I
retract my advice; there really isn't anything you can do to fix your
reputation. I would say "do whatever you wish", but you're going to
do that anyway.
...
> Removing myself from the conversation would only result in it continuing
> "behind my back", as it were, hardly a desirable state of affairs from
> my point of view.
Yes, I'm starting to see how paranoid you are.
...
> >>> you would choose to not answer some of these posts
> >> But doing so would be at the cost of leaving an incorrect negative
> >> statement about me unchallenged as part of the public record. Surely you
> >> can see how that might be a problem.
>
> > Of course I can see it, grasshopper.
>
> I am a vertebrate. Please be more careful in the future when making wild
> guesses about an organism's phylogenetic status.
Apparently, you are not old enough or well-connected enough to
remember the "Kung Fu" TV series. The term was endearing, in the same
way you have quoted such endearing phrases from Yoda in Star Wars.
Oh, well. I guess I misjudged your savvy.
Have a nice day.
Duane
·····@franz.com wrote:
[further attributions were mangled]
>>> You're becoming frustrated with everyone else for spouting
>>> misinformation, and you haven't learned that the best way to remove
>>> the misinformation is to remove yourself from the conversation.
>> This quite clearly cannot be correct. The only way to remove the
>> misinformation would be to destroy Google's servers, and their backup
>> tapes. It follows from the illegal, vandalous, and infeasible nature of
>> such a task that in practice one cannot remove it at all, and must
>> instead combat it in some other way, perhaps by spreading an equal and
>> opposite message, in some sense of the phrase "equal and opposite".
>
> Yes, I must correct myself here; I was speaking as if to someone who
> hadn't posted hundreds of messages to a newsgroup, and so I admit that
> I am wrong
You are indeed, but it is not my messages that are at issue here; it is
yours, and others. The ones that misrepresent me that I was referring to
further above. My messages, by and large, are calm and rational and
attempt to be the voice of reason so I have no problem with their
remaining archived.
> It's the "equal and opposite" part that is doing your reputation in.
> The sheer volume and tenacity of your posts has soiled your reputation
> beyond repair, and I retract my advice; there really isn't anything you
> can do to fix your reputation.
Or so you claim. However, it is clear by now that your motives are
suspect, so nothing that you say in the way of "advice" can be taken at
face value. The content of my posts is above reproach. Their quantity is
irrelevant. What of the quantity and tenacity of your posts, and the
others that have attacked me? What's good for the goose is good for the
gander, so if, as you imply, posting a lot means you're a bad person*,
then you are all equally guilty and it's as much on record as in my case.
* I do not, however, actually agree with this assertion at all.
>> Removing myself from the conversation would only result in it continuing
>> "behind my back", as it were, hardly a desirable state of affairs from
>> my point of view.
>
> Yes, I'm starting to see how paranoid you are.
This is a pointless and irrelevant personal attack. This post contains
several pairs of posts, neither from me, where the second post insults
me, so it is apparent that there are individuals present in this thread
that are willing to attack me in their replies to one another, and not
solely in their replies to me. My ceasing to post would not alter that.
So what you call "paranoid" is merely a logical extrapolation from what
has already been observed.
>>>>> you would choose to not answer some of these posts
>>>> But doing so would be at the cost of leaving an incorrect negative
>>>> statement about me unchallenged as part of the public record. Surely you
>>>> can see how that might be a problem.
>>> Of course I can see it, grasshopper.
>> I am a vertebrate. Please be more careful in the future when making wild
>> guesses about an organism's phylogenetic status.
>
> Apparently, you are not old enough or well-connected enough to
[rest deleted]
Once again you respond to logic by lashing out with a personal attack.
This does not advance your case one iota. I suggest you read about the
fallacy of ad hominem arguments before continuing to post here.
> Oh, well. I guess I misjudged your savvy.
You have apparently misjudged me completely. I have never initiated any
hostilities nor desired any antagonistic relationship.
On May 22, 6:02 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 22, 11:23 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Sure they do. Either two identical names collide, or they reside in
> >>>> distinct namespaces. You just insinuated that methods and classes do not
> >>>> reside in distinct namespaces (quoted material, very top of this post).
> >>>> Therefore if one of each with the same name resides in a single one,
> >>>> they collide. It's elementary logic, Alessio.
> >>> Do a field named foo and a method named foo in the same class collide
> >>> in Java? No.
> >> Because they reside in different namespaces. Java doesn't just consider
> >> them both "symbols" and throw them together into a single namespace;
> >> instead, it creates separate ones within the class for fields and for
> >> methods.
>
> >> However, an earlier poster said that Common Lisp just considers method
> >> names and the like to be "symbols" and throws them all together into a
> >> single namespace per package.
>
> > That was me.
>
> So now you're disagreeing with *yourself*? Well, I guess you might
> sometimes change your mind about one of these things, but still, the
> timing in this case was atrocious!
>
> >> If that earlier poster was incorrect, take it up with him. Attacking me
> >> for simply quoting him is pointless, rude, and should make you feel
> >> guilty now that you realize the attack was aimed at the wrong target and
> >> you just smacked an innocent bystander for someone else's offense.
>
> > The earlier post WAS correct.
>
> But it wasn't. Or else the later one wasn't correct. You can't have it
> both ways! Either they all go into one name-resolution pool or they
> don't; they can't both do so and not do so at the same time.
>
> > And, no clashes!!
>
> So, the earlier post WAS incorrect.
>
> > The meaning of a symbol is apparent from the context. Yet there is a
> > single namespace, the package.
>
> Not consistent. Either the former or the latter is false. I think you
> have package and namespace confused, and the package actually has a
> separate namespace in it for each of several kinds of thing. In other
> words, it doesn't just have symbols, it has methods separate from
> variables separate from classes etc.; it has some notion of which of
> these is which and keeps them tidy.
No, I don't. Packages in Lisp are name-spaces: spaces of names, sets
of names. They contain - names. Just names, nothing else. Really.
Names can refer to many things. They can have many meanings attached.
But those meanings are not attached using packages.
The same is true in Java, somehow, too: if you use a Class as a
namespace (classes are indeed namespaces in Java, though not the only
kind of namespace).
class.getField("foo") returns a field, class.getMethod("foo") returns
a method, yet the name is always "foo". See? Lisp works like this.
When in Lisp you use the symbol foo where a variable is expected, the
compiler uses foo as a variable name; when you use foo where a
function name is expected, the compiler uses foo as a function name;
and so on. But foo is always the same symbol, the very same object.
Java on the other hand has "packages" which are namespaces, but also
are a sort of "logical directories" that contain resources (typically
classes). Lisp is not like that at all.
> > there are multiple namespaces here (one for
> > variables, one for classes, one for functions and macros, ...)
>
> An admission of the truth at last?
I'm using "namespace" improperly here, in hope to make things clearer
to you. Probably it's more correct to say there are more symbol-to-
object mappings.
> >>>>>>> the method MY:frobnodicate(YOUR:quux) which is different from
> >>>>>>> the method YOUR:frobnodicate(MY:quux) which is different from
> >>>>>>> the method YOUR:frobnodicate(YOUR:quux)
> >>>>>> The methods, yes. It's the little bit of code containing the dispatch
> >>>>>> table that concerns me.
> >>>>>> Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobdicate, for example.
> >>>>> Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which may
> >>>>> or may not make sense depending on what MY:frobnobdicate and YOUR:quux
> >>>>> mean.
> >>>> In your example, though, this combination was used, along with all three
> >>>> other combinations of whose frobnobdicate and whose quux.
> >>> My example was meant to show all the possible combinations, not
> >>> suggest they usually are all used.
> >> Well, I was simply considering the possibility that they ARE all used,
> >> and it seems that using two of them causes problems.
>
> > I don't think it can cause any problem whatsoever.
>
> By "problems" in this instance I meant scoping headaches for the
> programmer, rather than actual failures of the code.
Ok, but this case is like if you had, in Java,
a.X.method(a.Y thing)
a.X.method(b.Y thing)
b.X.method(a.Y thing)
b.X.method(b.Y thing)
used in the same file; not very probable (and exactly as problematic
in Java as in Lisp).
[snip]
>
> >>> The "natural encapsulation" is only natural in Java, C++ and languages
> >>> with a similar kind of OO. It's not the only possibility. In Lisp, the
> >>> natural encapsulation is at the package level
> >> My point was that Lisp's encapsulation granularity is much fucking
> >> coarser!! Are you fucking dense?
>
> > If I use the "private" symbol P::X, this means that anything named
> > P::X is private: the CLASS P::X, the VARIABLE P::X, the FUNCTION P::X.
>
> Oh God, it just gets worse and worse! Now you say your system's bollixed
> up enough that you can't even have, say, a private variable named foo
> and a public method named foo in the same place? Who thought this up?
> Why would you make private apply to everything of the same NAME,
> regardless of whether that name was overloaded? Why?
It's the price you have to pay for having a general naming mechanism
like packages. It's not really a big price, since I've never come up
with a case where it actually gave problems. Naming conventions help,
of course (e.g. variables are usually named *variable-name* with
asterisks).
> Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
> end of the matter. There's really little point in continuing this.
If you think so.
> > How is this "much ****ing coarser" than Java?
>
> It's spelled "fuck". With an F.
>
> > Sure, I can't have function X private and class X public.
>
> Let's tick things off shall we? One. More. Time.
>
> 1. Your module size is like in C, a few per program (plus libraries'),
> rather than like Java or even C++, one per class.
> Imagine C++ only with "private" visible to everything in the same
> .cc file, or all pairs of classes in a single source file implicitly
> mutual "friends".
C does not have namespaces IIRC. If it had, then yes, CL would be
similar to C (but with the huge benefit that symbols are first-class
and you can manipulate them at runtime).
> 2. The encapsulation is extremely weak even so. Not only can you
> circumvent it by adding a single colon to a scope operator somewhere,
>
> a) it's right next to another colon, so an easy typo to make simply
> by bouncing a key;
No, since you have to type the symbol name, so you have to add a colon
AND mistype the symbol name so that accidentally you hit an existing
private symbol - quite unlikely.
b) you can presumably automate even the one lousy extra colon using a
macro;
No, you can't, since symbol resolution is done at read-time, before
macros are expanded.
> and c) it will look enough like normal to
> be easily overlooked and mistaken for innocent code, unlike, say,
> Java reflection and setAccessible(true) calls. Heck you can even get
> your Java IDE to find all setAccessible calls on reflection API
> objects without false positives and throughout the code base, if your
> IDE is decent enough. Meanwhile :: is a search that will have false
> positives I guarantee it. All two-or-less-character searches do.
Yet it never gave me problems. Because it's not easy to make a mistake
(see above).
> > Besides that, what can you express in Java that you cannot in Common
> > Lisp?? (apart from the fact CL has no "protected")?
>
> Technically nothing since they're both Turing complete. But much that is
> decent and good in Java would require implementing a Java emulator in CL
> to get in CL. (The JVM spec is readily available, so this should be
> trivial right?)
Ok, turing-equivalence apart, I meant with current Java and CL, and
I've shown you, too.
> Class-granular "private" comes to mind in particular.
You have it. Just make the slot name private.
> > CL IS NOT JAVA and IT WORKS DIFFERENTLY.
>
> Exactly my point. It works differently, and in this case, differently =
> worse. Now every unrelated pair of "close" methods collides, unless you
> start being creative with your thesaurus, and then code gets less
> readable and there's more and harder memorization to learn to use the
> darn thing.
>
> > close(file), close(socket), close(string-output-stream) BELONG ALL TO
> > THE SAME GENERIC FUNCTION
>
> The one for iostreams.
>
> What about closing windows? Oops, no windows, forgot. :P Well, I'll
> think of *something*...
Those about closing windows are different verbs, yes. There are not
many cases like this. How many more totally unrelated things can you
close?
> > Sorry for "shouting"
>
> No you're not, not one damn bit.
I meant WRITING IN ALL CAPS.
> > I really don't know how to explain it to you, yet it seems simple to
> > me.
>
> I'm sure the guys down at Bellevue that think they're Napoleon think the
> same thing when they try to get people to believe them.
yeah, right...
> >>> Heh, Graphics2D is really an example of what I was saying :) it has
> >>> drawPolygon, drawOval, drawText, and a few other drawSomething. What
> >>> if I wanted it to draw the cool chart generated by my favourite
> >>> library?
> >> The chart would be an instance of some class, say Chart, implementing
> >> the other interface, the one with a drawOn(Graphics2D) method specified.
> >> The drawOn() method would call the Graphics2D methods. Code that wanted
> >> to draw a chart on a Graphics2D would call the chart's drawOn() method
> >> with the appropriate parameter. Different chart instances would produce
> >> different drawings.
>
> > So while I can drawRect() and drawCircle(), I can't drawChart() but I
> > have to use a workaround, Chart.drawOn(graphics).
>
> That's not a workaround. We can also have Circle.drawOn, Rect.drawOn,
> etc. if we want to be able to do them all consistently. Or we can add a
> generic draw() to Graphics2D that takes a Drawable and just calls
> argument.drawOn(this). (Assuming we control Graphics2D.) Then you can
> happily do graphics.draw(chart).
>
> > I need ALL objects that can be drawed implement the Drawable
> > interface. Unfortunately it's unlikely I'll ever have control on ALL
> > classes that can be drawed...
>
> Why? You're the one designing the system, hypothetically.
>
> > So I end up having "primitive" drawXXX on Graphics,
> > com.mypackage.Drawable.drawOn(Graphics),
> > com.yourpackage.DrawableObject.draw(Graphics), and so on.
>
> Why? The system's designed would make Drawable public, and an interface
> so any class could implement it regardless of constraints on its superclass.
What if I want to draw something I didn't wrote, and whose author
didn't know about my Drawable interface?
> > Instead in
> > Lisp I can have
> > (draw object graphics) and stop - if I want to draw a new kind of
> > object, I'll write the appropriate method for the draw generic
> > function.
>
> The cost of having this is that you can change someone else's code, and
> even are encouraged to. If they didn't make their class Drawable, why,
> you'll just do it for them!
Sure, and what's the problem? I don't change their code, I write new
code which happens to use their class.
[snip]
> > In Java I really put MY method in the dispatch table of YOUR
> > superclass.
>
> Not explicitly! And not really at all; the classloader builds up a
> dispatch table at runtime.
The classloader does it for you then. The effect is the same.
> > This is the analogy I'm making.
>
> And I'm telling you, it doesn't quite work.
>
> > Adding a subclass in Java that overrides the method IS
> > EXACTLY LIKE adding a method in Lisp specialized on the subclass. It's
> > the very same thing.
>
> NO, IT ISN'T! If you still don't understand why I'm afraid you never
> will. It's time to drop this line of debate.
For the last time:
--- Lisp ---
(defgeneric f (x))
(defclass c () ())
(defmethod f ((x c)) 'default-value)
BEFORE adding a method for class d:
(f (make-instance 'c)) ==> DEFAULT-VALUE
AFTER
(defclass d (c) ())
(defmethod f ((x d)) 'ok)
(f (make-instance 'd)) ==> OK
(note that the class name D can be in MY package while the name of the
generic function F is in YOURS)
--- Java ---
BEFORE
class C {
String f() {
return "DefaultValue";
}
}
C c = new C();
System.out.println(c.f()); //Prints "DefaultValue"
AFTER
class D extends C {
String f() {
return "OK!!!";
}
}
C c = new D();
System.out.println(c.f()); //Prints "OK!!!"
--------------
The only differences are that, in Lisp,
1. you can define the new method after the class and not necessarily
together with it,
2. you have multiple dispatch, but in this example it is indifferent
since the argument is only one.
> >>>>> The generic function is not changed any more than the abstract class
> >>>>> is.
> >>>> Sure it is. The abstract class still contains exactly the same methods.
> >>>> The generic function contains new ones. Viewing both as lists, one grew
> >>>> and one didn't.
> >>> Viewing one as a list and the other as a tree (class hierarchy)
> >> A simple strategy: when an apples-to-apples comparison makes your side
> >> look bad, rebut by comparing apples to oranges instead!
>
> > imho my comparison is more correct than yours.
Don't be confused by the name "method", which means a different thing
in CL than in Java. A lisp method is a particular specialization of a
generic function: a generic function having one more method in Lisp is
like a method having one more override in Java.
> I once knew a guy who was of the opinion that the earth was flat.
LOL.
>
> > #: is read syntax that makes the symbol not being interned in any
> > package.
>
> "Read syntax"?
Yep. An instruction for the Lisp reader.
>
> > Can't your register custom protocol handlers? If you can't, then Java
> > really sucks! :D
>
> Of course you can,
Ok, that's good.
[snipped some tangential rant about things not in Java's standard
library]
> >>> Maybe that's the reason I'm using, and sometimes contributing to, a
> >>> Lisp implementation running on the JVM... :)
> >> Clojure?
>
> > [calls me a liar]
HAHAHAHAHA! How is the sentence "No, ABCL" calling you a liar?!? We're
going into total madness here, boy! I'm a really stubborn guy, as the
poor people reading our posts have noticed (well, those who haven't
still put us in their killfile), but even I am getting tired!
Alessio Stalla wrote:
> On May 22, 6:02 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> The meaning of a symbol is apparent from the context. Yet there is a
>>> single namespace, the package.
>> Not consistent. Either the former or the latter is false. I think you
>> have package and namespace confused, and the package actually has a
>> separate namespace in it for each of several kinds of thing. In other
>> words, it doesn't just have symbols, it has methods separate from
>> variables separate from classes etc.; it has some notion of which of
>> these is which and keeps them tidy.
>
> No, I don't. Packages in Lisp are name-spaces: spaces of names, sets
> of names. They contain - names. Just names, nothing else. Really.
Then function and variable names in the same package with the same names
would collide. Which contradicts your earlier testimony here.
Wikipedia's article on Common Lisp may resolve this internal dispute of
yours, however:
> The namespace for function names is separate from the namespace for
> data variables.
Apparently the one-namespace version is wrong and there are at least two.
> Names can refer to many things. They can have many meanings attached.
> But those meanings are not attached using packages.
Did I say that? No. What I said was that the packages keep track of
those meanings in order to disambiguate some same-named things, which
seems consistent with what Wikipedia says.
> The same is true in Java, somehow, too: if you use a Class as a
> namespace (classes are indeed namespaces in Java, though not the only
> kind of namespace).
> class.getField("foo") returns a field, class.getMethod("foo") returns
> a method, yet the name is always "foo". See?
Because the class actually contains multiple, separate namespaces and
fields and methods are in distinct ones.
> Java on the other hand has "packages" which are namespaces, but also
> are a sort of "logical directories" that contain resources (typically
> classes).
They correspond to directories on the filesystem in most
implementations, and those directories may contain other resources, but
to consider the packages and the directories to be one and the same
would be erroneous.
Java packages, in terms of the language core semantics, are namespaces
for classes, interfaces, and enums (and are single namespaces; no two of
those can have the same name).
>>> there are multiple namespaces here (one for
>>> variables, one for classes, one for functions and macros, ...)
>> An admission of the truth at last?
>
> I'm using "namespace" improperly here, in hope to make things clearer
> to you.
If by "improperly" you mean "the way that computer scientists and
Wikipedia use the term" then yes.
You can ditch the vaguely condescending tone, by the way. It does not
help you further your cause.
>>>>>>>>> the method MY:frobnodicate(YOUR:quux) which is different from
>>>>>>>>> the method YOUR:frobnodicate(MY:quux) which is different from
>>>>>>>>> the method YOUR:frobnodicate(YOUR:quux)
>>>>>>>> The methods, yes. It's the little bit of code containing the dispatch
>>>>>>>> table that concerns me.
>>>>>>>> Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobdicate, for example.
>>>>>>> Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which may
>>>>>>> or may not make sense depending on what MY:frobnobdicate and YOUR:quux
>>>>>>> mean.
>>>>>> In your example, though, this combination was used, along with all three
>>>>>> other combinations of whose frobnobdicate and whose quux.
>>>>> My example was meant to show all the possible combinations, not
>>>>> suggest they usually are all used.
>>>> Well, I was simply considering the possibility that they ARE all used,
>>>> and it seems that using two of them causes problems.
>>> I don't think it can cause any problem whatsoever.
>> By "problems" in this instance I meant scoping headaches for the
>> programmer, rather than actual failures of the code.
>
> Ok
Well, then.
>>>>> The "natural encapsulation" is only natural in Java, C++ and languages
>>>>> with a similar kind of OO. It's not the only possibility. In Lisp, the
>>>>> natural encapsulation is at the package level
>>>> My point was that Lisp's encapsulation granularity is much fucking
>>>> coarser!! Are you fucking dense?
>>> If I use the "private" symbol P::X, this means that anything named
>>> P::X is private: the CLASS P::X, the VARIABLE P::X, the FUNCTION P::X.
>> Oh God, it just gets worse and worse! Now you say your system's bollixed
>> up enough that you can't even have, say, a private variable named foo
>> and a public method named foo in the same place? Who thought this up?
>> Why would you make private apply to everything of the same NAME,
>> regardless of whether that name was overloaded? Why?
>
> It's the price you have to pay for having a general naming mechanism
> like packages.
That's funny, because Java has packages and lacks this restriction.
> It's not really a big price, since I've never come up
> with a case where it actually gave problems. Naming conventions help,
> of course (e.g. variables are usually named *variable-name* with
> asterisks).
Won't that be confused with multiplication, or emphasis, or something?
(Leaving aside the more general problems with allowing arbitrary
punctuation in identifiers.)
Java naming conventions would help, in that one ordinarily uses getFoo()
for a getter for a field named foo ... but a lot of languages lack such
a notion, and indeed many languages (Ruby, Python, Eiffel, and even C#)
have "attributes" support, fields made visible and possibly assignable
where this actually goes through getter and setter methods, sometimes
defined explicitly (to add extra behavior) and sometimes not. These tend
to involve naming patterns like
X foo (variable with some type X)
X foo() (method with return type X)
void foo(X value) (method with argument type X)
which Lisp apparently wouldn't allow without making the variable public.
Then people could bypass the getter and setter, and then what's the
point of having them?
>>> Sure, I can't have function X private and class X public.
>> Let's tick things off shall we? One. More. Time.
>>
>> 1. Your module size is like in C, a few per program (plus libraries'),
>> rather than like Java or even C++, one per class.
>> Imagine C++ only with "private" visible to everything in the same
>> .cc file, or all pairs of classes in a single source file implicitly
>> mutual "friends".
>
> C does not have namespaces IIRC.
It effectively has them through the mechanism of "external linkage" and
the ability to declare a symbol non-exported by not declaring it
"extern". A non-exported symbol is used by the compiler in compiling the
one C file, and that's it. The linker never sees it. As a result, the
same name can be used in multiple C files, if none exports it.
If a name is exported by a C file, say a.c, and b.c uses that name
internally for something else, then b.c can't use that name from a.c.
This is doable: suppose the name is foo. The header a.h will have a
declaration of extern int foo; or some such. The file b.c can simply not
include a.h and then when the compiler sees it the only foo it knows of
is the internal one in b. This gets resolved entirely internally, so the
linker never knows that b.o once had a foo in it. Everything works. If
b.c needs to use other symbols from a.c, it can use declarations like
those in a.h, excluding that for foo, to access them.
It's coarse-grained and clunky, of course. Names with "extern" linkage
are visible everywhere so cannot collide; the linker will give an error.
Names with internal linkage can't be exported directly, but for
functions you can make a "trampoline" function of a different name that
you export. More commonly, you might "namespace" the extern'd symbols by
using prefixes to indicate what part of the codebase they belong to.
But it is not as bad as you suggest, with all symbols pooled together in
one undifferentiated lump.
The Common Lisp situation seems slightly better: you can put symbols in
namespaces and still refer to them from elsewhere via a scope operator.
This is closer to C++'s namespaces, excluding the internal ones within
C++ classes. C++ however adds classes-as-namespaces and thus much finer
granularity than CL seems to provide. Java likewise has
classes-as-namespaces and a way to import from namespaces (including
from classes, via "import static").
> yes, CL would be similar to C (but with the huge benefit that symbols
> are first-class and you can manipulate them at runtime).
Java has reflection, too.
(Other similarities with C: CL's age (even older if anything); CL's
standard isn't freely available; CL's is an ANSI standard; Lisp more
generally has a bevy of somewhat different and incompatible legacy
variants from before CL standardization. Smalltalk has it worse
standardization-wise, I think, though if Squeak takes over the world
that will change.)
>> 2. The encapsulation is extremely weak even so. Not only can you
>> circumvent it by adding a single colon to a scope operator somewhere,
>>
>> a) it's right next to another colon, so an easy typo to make simply
>> by bouncing a key;
>
> No
Yes. (The key in question is the key marked with ":" and ";", in case
you were confused.)
>> b) you can presumably automate even the one lousy extra colon using a
>> macro;
>
> No, you can't
Yes, you can.
> since symbol resolution is done at read-time, before macros are expanded.
Perhaps you already forgot your earlier mention of a "read-macro"? I
have a photographic memory. Anything you say can and will be used
against you in a court of law.
>> and c) it will look enough like normal to
>> be easily overlooked and mistaken for innocent code, unlike, say,
>> Java reflection and setAccessible(true) calls. Heck you can even get
>> your Java IDE to find all setAccessible calls on reflection API
>> objects without false positives and throughout the code base, if your
>> IDE is decent enough. Meanwhile :: is a search that will have false
>> positives I guarantee it. All two-or-less-character searches do.
>
> Yet it never gave me problems.
It will if you ever have to work on a large project that has numerous
developers, chooses CL as its implementation language, and ends up with
a loose cannon that is prone to using other peoples' private members and
generally eschewing what little scope for encapsulation remained after
the implementation-language choice was made. Tracking down the misuses
of private members sprinkled liberally throughout their commits will be
a colossal pain, compared to the Java case, where such behavior is also
less likely in the first place since everything in the language design
heavily discourages it.
>> Class-granular "private" comes to mind in particular.
>
> You have it. Just make the slot name private.
I thought you said the class didn't constitute a namespace of its own.
This will make every slot of the same name "private" in every class in
the same package. OK, making your instance variables all private is
probably actually a good thing, except that you really only made them
"private" thanks to the colon-colon loophole.
>>> CL IS NOT JAVA and IT WORKS DIFFERENTLY.
>> Exactly my point. It works differently, and in this case, differently =
>> worse. Now every unrelated pair of "close" methods collides, unless you
>> start being creative with your thesaurus, and then code gets less
>> readable and there's more and harder memorization to learn to use the
>> darn thing.
>>
>>> close(file), close(socket), close(string-output-stream) BELONG ALL TO
>>> THE SAME GENERIC FUNCTION
>> The one for iostreams.
>>
>> What about closing windows? Oops, no windows, forgot. :P Well, I'll
>> think of *something*...
>
> Those about closing windows are different verbs, yes.
Acknowledged.
> There are not many cases like this. How many more totally unrelated
> things can you close?
According to Google, dozens:
> Results 1 - 10 of about 189 from java.sun.com for "void close" "Java
> Platform SE 6".
This says 189 but counts related uses, like I/O streams. The first page
of hits has streams, writers and readers (character-encoding stream
wrappers, arguably related), connections (arguably related), scanners
(arguably related), sockets, and splash screens. The second adds
statements, progress monitors, handlers, and result sets; the third, XML
encoders and interruptible channels. That's twelve so far.
Need I go on? :)
I'd say "dozens" is not an unreasonable estimate.
(And that's not counting any occurrences of "int close" or others that
for whatever reason have some kind of a result to return.)
>>> Sorry for "shouting"
>> No you're not, not one damn bit.
>
> I meant WRITING IN ALL CAPS.
And I meant you're not sorry.
>>> So I end up having "primitive" drawXXX on Graphics,
>>> com.mypackage.Drawable.drawOn(Graphics),
>>> com.yourpackage.DrawableObject.draw(Graphics), and so on.
>> Why? The system's designer would make Drawable public, and an interface
>> so any class could implement it regardless of constraints on its superclass.
>
> What if I want to draw something I didn't wrote, and whose author
> didn't know about my Drawable interface?
Then, hypothetically speaking, you're probably also the author of the
companion Graphics one, and can add the drawing code there.
>>> Instead in
>>> Lisp I can have
>>> (draw object graphics) and stop - if I want to draw a new kind of
>>> object, I'll write the appropriate method for the draw generic
>>> function.
>> The cost of having this is that you can change someone else's code, and
>> even are encouraged to. If they didn't make their class Drawable, why,
>> you'll just do it for them!
>
> Sure, and what's the problem? I don't change their code
Except for the little bit that goes (defgeneric ... (foo foo) (bar bar) ...)
But they won't mind, surely?
>>> In Java I really put MY method in the dispatch table of YOUR
>>> superclass.
>> Not explicitly! And not really at all; the classloader builds up a
>> dispatch table at runtime.
>
> The classloader does it for you then. The effect is the same.
The effect is NOT the same because it happens at run time, which means
it can't possibly mess up the system's source code.
>>> Adding a subclass in Java that overrides the method IS
>>> EXACTLY LIKE adding a method in Lisp specialized on the subclass. It's
>>> the very same thing.
>> NO, IT ISN'T! If you still don't understand why I'm afraid you never
>> will. It's time to drop this line of debate.
>
> For the last time:
[snip!]
> The only differences are that, in Lisp,
>
> 1. you can define the new method after the class and not necessarily
> together with it,
> 2. you have multiple dispatch, but in this example it is indifferent
> since the argument is only one.
You're leaving out the really important bit:
In Java, you're subclassing my class and adding a method to your subclass.
In Lisp, you're subclassing my class and adding a method to my generic
function.
>>>>>>> The generic function is not changed any more than the abstract class
>>>>>>> is.
>>>>>> Sure it is. The abstract class still contains exactly the same methods.
>>>>>> The generic function contains new ones. Viewing both as lists, one grew
>>>>>> and one didn't.
>>>>> Viewing one as a list and the other as a tree (class hierarchy)
>>>> A simple strategy: when an apples-to-apples comparison makes your side
>>>> look bad, rebut by comparing apples to oranges instead!
>>> imho my comparison is more correct than yours.
> Don't be confused
Please don't be rude.
>> I once knew a guy who was of the opinion that the earth was flat.
>
> LOL.
>
>>> #: is read syntax that makes the symbol not being interned in any
>>> package.
>> "Read syntax"?
>
> Yep. An instruction for the Lisp reader.
You mean, the sort of thing you claimed didn't exist earlier, when you
wrote:
>> b) you can presumably automate even the one lousy extra colon using a
>> macro;
>
> No, you can't, since symbol resolution is done at read-time, before
> macros are expanded.
?
>>> Can't your register custom protocol handlers? If you can't, then Java
>>> really sucks! :D
>> Of course you can,
>
> Ok, that's good.
>
> [snipped some tangential rant about things not in Java's standard
> library]
Which also served to demonstrate that I'm not an uncritical flag-waving
jingoistic Java jihadist with delusions of Java being perfect.
>>>>> Maybe that's the reason I'm using, and sometimes contributing to, a
>>>>> Lisp implementation running on the JVM... :)
>>>> Clojure?
>>> [calls me a liar]
>
> HAHAHAHAHA!
Such a thing should cause you feelings of shame, not amusement.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>>>>> it probably does not make much sense to do
>>>>> (defmethod db-library:open-transaction ((transaction-manager picture-
>>>>> library:jpeg-picture)) ...whatever...)
>>>> I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.
>>> See the parameter name - it's transaction-manager.
>> What parameter name? All I see is a list of arguments. A
>> transaction-manager and a picture-library might conceivably both be
>> arguments to the same call.
>
> I know you're the world's greatest expert on Lisp and all
That would be incorrect.
> but: [condescension deleted]
>
>> My point was that Lisp's encapsulation granularity is much fucking
>> coarser!! Are you fucking dense?
>
> Please stop these vicious personal attacks.
Frustration. And I think I can be excused after the large number of
similar attacks I have weather from you AND from each of your compatriots.
For a pack that can't even agree with one another on whether macroexpand
changes the source code in the editor or not, whether you can get at
symbols not in any package with #: or not, and various other things, you
sure seem to have no trouble mutually agreeing that I'm the enemy and
opening up with both barrels.
>>>> Verb collisions are the issue. So many things will have close methods,
>>>> for example. If you use several of them in one area, you'll only be able
>>>> to import one and you'll have to FQ the others.
>
> Yes, that would be terrible!
I'm glad you're beginning to see reason.
> It would make our code look like Java,
> where /every/ method has to be qualified...
>
> foo.bar()
> ^^^
> hey, look!
That hardly counts. (bar foo) is exactly the same number of characters.
You still have to specify the "foo" to pass one of the arguments. Java
also uses the leftmost argument to scope method name lookup. In other
words it gets a package specification of sorts FOR FREE. You Lispers
gotta pay for it in extra keystrokes.
Only in the case of static method calls versus function calls do you
maybe have a slight point. And it's outweighed by all the cases where
Java saves on some typing and Lisp doesn't -- all those "close" methods,
for instance.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>>> The error in this analysis is conflating the notion of a namespace
>>> with
>>> that of a class or function/method.
>> I did no such thing. I only assumed that classes and/or
>> functions/methods live IN namespaces.
>
> "Big mistake"
Incorrect. You yourselves have repeatedly indicated that Lisp has a
package system and that all definitions within Lisp are in packages
within that system, and that the sole purpose of the package system is
namespacing.
My own assumption is derived from your statements. If my assumption is
in error it can only be because one of your own was in error.
>> I assumed that there were three possible ways to resolve names:
>>
>> package.class.method (perhaps with inheritance) (Java uses this)
>> package.method.class
>> package1.class.package2.method
>>
>> that is, either packages namespace classes which namespace methods
>> (Java model), packages namespace methods which namespace classes
>> (don't know what uses this), or packages namespace both methods and
>> classes.
>>
>> You seem to be saying that Lisp does the last of the three.
>
> None of the above.
You are once again contradicting earlier posts by your own side in this
conflict.
I am aware that Lisp's syntax is not identical with the above, but
syntax was not at issue here, and multiple languages' behaviors were, so
I chose a syntax resembling Java's for convenience.
Regardless, it remains the case that either methods belong to classes
belong to packages, classes belong to methods belong to packages, or
classes and methods each separately belong directly to packages, unless
one or both are not subjected to namespacing at all, in which case their
names collide easily and this will cause a tremendous amount of trouble.
Several of you have stated repeatedly and in no uncertain terms that all
constructs in Lisp ARE subjected to namespacing, however, which is what
eliminates that last possibility and leaves only the three outlined
previously.
Seamus MacRae <··········@live.ca.nospam> wrote in news:gv12kd$8g1$1
@news.eternal-september.org:
> You are once again contradicting earlier posts by your own side in this
> conflict.
Just because different people argue in favor of Common Lisp doesn't mean
they're on the same side. They each have their own point of view. Some
of them are Lisp novices and don't really understand their own arguments
very well.
When you learn CL, you learn new concepts, not just the details of
language features. The stuff you learn works together with a lot of
synergy. So you aren't likely to actually learn much of anything useful
by engaging in this kind of argument. You would be much better off
spending your time downloading Practical Common Lisp and a CL system, and
spending the time with those that you would have spent arguing here.
Even if you never use CL for real-world work, what you learn from it can
make you a much better programmer.
Programmers who don't think they need to improve are near the start of
their learning curve.
On Thu, 21 May 2009 12:33:44 +0000, eric-and-jane-smith wrote:
> Even if you never use CL for real-world work, what you learn from it can
> make you a much better programmer.
I have heard it said often, but I am still wondering about this.
Maybe CL has made me a better programmer in other languages, but
mostly I just miss the features of CL and hate programming in the
other language. After CL, it is like swimming in tar.
The other day I was doing something in R, for teaching. It took
about an hour, but it was enough for missing the following:
- symbols (R uses strings, ugly)
- convenience macros like with-open-file already in the standard
- simple macros in libraries, eg iterate
- SBCL's compiler, which checks my code pretty thoroughly and warns me
about typos and think-os
- the speed of compiled code.
And R is a pretty decent language. If I were programming in Fortran,
I would be going crazy after Lisp. And in the list above, I didn't
even include CLOS, fancier DSLs, etc.
Tamas
From: Kenneth Tilton
Subject: Fortran and Lisp: Separated At Birth? [was Re: macros]
Date:
Message-ID: <4a15859b$0$5384$607ed4bc@cv.net>
Stefan Ram wrote:
> Tamas K Papp <······@gmail.com> writes:
>> If I were programming in Fortran,
>> I would be going crazy after Lisp.
>
> LISP started out as a subroutine package
> for list processing /in FORTRAN/.
>
I tried to get McCarthy to apologize for the name Lisp during the Q&A
after an ILC talk. He said he wanted to call it FLPL. Or something like
that. Hey, it's haiku time again in c.l.l!
McCarthy
---------
Some BDFL:
Did not dictate the syntax
Or even the name.
kt
eric-and-jane-smith wrote:
> Seamus MacRae <··········@live.ca.nospam> wrote in news:gv12kd$8g1$1
> @news.eternal-september.org:
>
>> You are once again contradicting earlier posts by your own side in this
>> conflict.
>
> Just because different people argue in favor of Common Lisp doesn't mean
> they're on the same side.
Sure it does, almost by definition. The sides in this case are "prefers
Java" and "prefers Lisp". If two people argue in favor of Common Lisp,
clearly neither of them belongs to the "prefers Java" camp. This is
really very elementary logic. You should not be having so much trouble
with it.
> Some of them are Lisp novices and don't really understand their own
> arguments very well.
Then perhaps they are not in a position to be claiming it's better than
Java. They need to know more before they can have enough information to
decide such a thing, and their going around asserting it in public with
weak arguments laced with ad hominem attacks seems especially foolish.
> When you learn CL, you learn new concepts, not just the details of
> language features. The stuff you learn works together with a lot of
> synergy. So you aren't likely to actually learn much of anything useful
> by engaging in this kind of argument.
I'm sure you find this stuff very fascinating, but it's also totally
irrelevant, since my goal here is not to learn CL, but to respond to the
attacks upon Java that were made earlier, and now to the attacks on my
own person. To do the latter, though, I keep having to reiterate the
points I raised about Java and Lisp, since people keep attacking them
and in so doing indirectly attacking me. And often, directly attacking
me also.
> You would be much better off spending your time downloading Practical
> Common Lisp and a CL system, and spending the time with those that you
> would have spent arguing here.
If my goal were to learn CL, rather than to prevail in this debate, then
you would be correct.
(Here, "prevail" means "the debate ends with a neutral or pro-Java
outcome, and the personal attacks cease". So that allows a draw, rather
than requiring a loss for your side.)
> Even if you never use CL for real-world work, what you learn from it can
> make you a much better programmer.
Maybe someday when I have more time I will learn more of it. Right now,
I'm too busy trying to catch up on fucking Usenet. So if you'll excuse
me ...
> Programmers who don't think they need to improve are near the start of
> their learning curve.
Is this intended as yet another personal attack? I have made no
assertion of not needing to improve. It's simply not relevant to the
matter at hand.
Seamus MacRae wrote:
> eric-and-jane-smith wrote:
>> You would be much better off spending your time downloading Practical
>> Common Lisp and a CL system, and spending the time with those that you
>> would have spent arguing here.
>
> If my goal were to learn CL, rather than to prevail in this debate, then
> you would be correct.
You don't think it is rather pointless to debate the merits of a
language that you don't master????
>> Even if you never use CL for real-world work, what you learn from it
>> can make you a much better programmer.
>
> Maybe someday when I have more time I will learn more of it. Right now,
> I'm too busy trying to catch up on fucking Usenet. So if you'll excuse
> me ...
Too busy discussing Lisp to actually learn Lisp.
I think that speaks for itself.
>> Programmers who don't think they need to improve are near the start of
>> their learning curve.
>
> Is this intended as yet another personal attack? I have made no
> assertion of not needing to improve. It's simply not relevant to the
> matter at hand.
It is very relevant.
If you don't know Lisp and want to discuss Lisp, then you should learn
about Lisp.
Arne
Arne Vajh�j wrote:
[snip]
Why are you suddenly posting a whole lot? So far as I am aware you don't
have any horses in this particular race.
> Seamus MacRae wrote:
>> eric-and-jane-smith wrote:
>>> You would be much better off spending your time downloading Practical
>>> Common Lisp and a CL system, and spending the time with those that you
>>> would have spent arguing here.
>>
>> If my goal were to learn CL, rather than to prevail in this debate,
>> then you would be correct.
>
> You don't think it is rather pointless to debate the merits of a
> language that you don't master????
Who has ever truly mastered any language? Is there nothing that you have
yet to learn about Java?
If absolute mastery was the requirement before being allowed by the
Almighty Arne to discuss a programming language, then nobody could
discuss programming languages.
Well, except for one teensy weensy little thing: the fact that the
Almighty Arne has absolutely no authority whatsoever to impose such a
requirement anyway. The Almighty Arne is, in fact, a yapping terrier
that thinks it's a big bad mastiff but is not even a threat to the seat
of anyone's pants.
And, if it ever did become a threat, would get dragged to the pound by
the dogcatcher and euthanized.
>>> Even if you never use CL for real-world work, what you learn from it
>>> can make you a much better programmer.
>>
>> Maybe someday when I have more time I will learn more of it. Right
>> now, I'm too busy trying to catch up on fucking Usenet. So if you'll
>> excuse me ...
>
> Too busy discussing Lisp
Oh, is that what we were doing? That's funny, because it seemed to me
that we were discussing *me* now, rather than Lisp.
>>> Programmers who don't think they need to improve are near the start
>>> of their learning curve.
>>
>> Is this intended as yet another personal attack? I have made no
>> assertion of not needing to improve. It's simply not relevant to the
>> matter at hand.
>
> It is very relevant.
No, it is not.
> If you don't know Lisp and want to discuss Lisp, then you should learn
> about Lisp.
I know some things about Lisp. Your statement otherwise was a lie.
eric-and-jane-smith wrote:
> When you learn CL, you learn new concepts, not just the details of
> language features. The stuff you learn works together with a lot of
> synergy. So you aren't likely to actually learn much of anything useful
> by engaging in this kind of argument. You would be much better off
> spending your time downloading Practical Common Lisp and a CL system, and
> spending the time with those that you would have spent arguing here.
>
> Even if you never use CL for real-world work, what you learn from it can
> make you a much better programmer.
That applies to most/all programming languages.
Arne
On May 15, 5:50 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
>
> >> The CL package system will solve the name collision with no harm done.
>
> > I just explained why the package system won't. Adding new classes in
> > their own packages? No problem, the package system can distinguish
> > foo.String from bar.String. Adding new methods to an existing class,
> > say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
> > foo.String.doIt()?
>
> I guess that's one of the downsides of an inside-out object
> system.
Inside-out?
> > So, basically, you're saying that the way you avoid the name clash is
> > to make baz's String.doIt() and quux's String.doIt() private. Of
> > course, this now means that anyone who wants their own code to call a
> > String.doIt() has to roll their own and can't get a canned one from a
> > library. Because if they do, and there's multiple incompatible
> > libraries that provide this, then we're back to square one and name
> > clashes.
>
> No, he's saying that support methods that don't make up a library's API
> won't be exported from packages
Er, that's basically what I meant by "make them private". Duh.
MY point, which remains unaddressed, is that there are three ways to
deal with a commonly-desired support method:
1. The vendor puts it in the system class. No problemo.
2. Everyone rolls their own. Ugh.
3. A third party library puts it in the system class.
Whereas the vendor would create an automatic standard,
absent this, most likely multiple third party libraries
would develop to do the job, and would each do it a bit
differently. Code using one and code using another one
could not typically be combined without problems.
> so there's no hazard of name clashes
> between them when one chooses to import all symbols from a package. That
> leaves a smaller number of potential name clashes to resolve manually.
And leaves everyone who wants to add the same utility method to the
same class to each do it separately. Ugh.
> >> If anyone want to use the two of them together, and it has some
> >> symbol clashes (probably just a few of them), this person can
> >> explicitly tell how the clashes should be handled.
>
> > Ah, I love the smell of boilerplate code in the morning!
>
> Not boilerplate. Just resolving a couple of conflicts if they arise.
Everywhere the symbols were used there'd need to be some preamble code
to "explicitly tell how the clashes should be handled". Repeated over
enough usage-sites, that adds up to boilerplate.
On May 16, 6:59 am, Series Expansion <·······@gmail.com> wrote:
> > >> If anyone want to use the two of them together, and it has some
> > >> symbol clashes (probably just a few of them), this person can
> > >> explicitly tell how the clashes should be handled.
>
> > > Ah, I love the smell of boilerplate code in the morning!
>
> > Not boilerplate. Just resolving a couple of conflicts if they arise.
>
> Everywhere the symbols were used there'd need to be some preamble code
> to "explicitly tell how the clashes should be handled". Repeated over
> enough usage-sites, that adds up to boilerplate.
You have to remember though, that there's not really such a thing as
boilerplate Lisp code. If you need to use some code once, you write it
there and that's it. If you need to use it more than once -- or if you
can conceive of situations in other projects, where you'd need to do
the same thing again -- you whip up a macro, and bye bye boilerplate.
The beautiful thing about macros is that it's not "machine-generated
code". You actually get complete control over the code into which a
macro call expands. You can use nitty gritty low-level special forms,
or build your new syntax on top of existing high-level forms. Once
you've written a macro, using it is like hitting Ctrl+V to paste some
code you used earlier, except the code reads your mind and customizes
itself to the situation. Unless you're writing wizard macro-defining
macros[1], debugging macro code is fairly straightforward with the
assistance of macroexpansion tools available in modern IDEs such as
Emacs + SLIME, and a working macro that you'll reuse in the future is
a huge asset.
- Adlai
[1] For example, Peter Seibel's once-only macro from PCL.
http://www.gigamonkeys.com/book/macros-defining-your-own.html
On May 16, 12:18 am, Adlai <·········@gmail.com> wrote:
> On May 16, 6:59 am, Series Expansion <·······@gmail.com> wrote:
> > Everywhere the symbols were used there'd need to be some preamble code
> > to "explicitly tell how the clashes should be handled". Repeated over
> > enough usage-sites, that adds up to boilerplate.
>
> You have to remember though, that there's not really such a thing as
> boilerplate Lisp code. If you need to use some code once, you write it
> there and that's it. If you need to use it more than once -- or if you
> can conceive of situations in other projects, where you'd need to do
> the same thing again -- you whip up a macro, and bye bye boilerplate.
Oh, God. Macros that generate imports and affect namespacing. If
*that's* not playing with fire, I don't know what is.
> The beautiful thing about macros is that it's not "machine-generated
> code".
You mean, the Lisp machine actually contains little elves that write
the expanded code? I thought that was just a myth!
> Unless you're writing wizard macro-defining macros[1], debugging macro
> code is fairly straightforward
OH RLY?
> with the assistance of macroexpansion tools available in modern IDEs
> such as Emacs + SLIME, and a working macro that you'll reuse in the
> future is a huge asset.
You know, most people find it hard to take anything seriously that has
"modern IDEs such as Emacs" as a dependent clause. :)
On May 16, 8:53 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 12:18 am, Adlai <·········@gmail.com> wrote:
>
> > On May 16, 6:59 am, Series Expansion <·······@gmail.com> wrote:
> > > Everywhere the symbols were used there'd need to be some preamble code
> > > to "explicitly tell how the clashes should be handled". Repeated over
> > > enough usage-sites, that adds up to boilerplate.
>
> > You have to remember though, that there's not really such a thing as
> > boilerplate Lisp code. If you need to use some code once, you write it
> > there and that's it. If you need to use it more than once -- or if you
> > can conceive of situations in other projects, where you'd need to do
> > the same thing again -- you whip up a macro, and bye bye boilerplate.
>
> Oh, God. Macros that generate imports and affect namespacing. If
> *that's* not playing with fire, I don't know what is.
>
> > The beautiful thing about macros is that it's not "machine-generated
> > code".
>
> You mean, the Lisp machine actually contains little elves that write
> the expanded code? I thought that was just a myth!
>
> > Unless you're writing wizard macro-defining macros[1], debugging macro
> > code is fairly straightforward
>
> OH RLY?
>
> > with the assistance of macroexpansion tools available in modern IDEs
> > such as Emacs + SLIME, and a working macro that you'll reuse in the
> > future is a huge asset.
>
> You know, most people find it hard to take anything seriously that has
> "modern IDEs such as Emacs" as a dependent clause. :)
I'm sorry, I was assuming that you could read entire sentences. I'll
try and restate my point in sentence fragments:
SLIME adding power!
... to old (not) useless Emacs!
Read my post describing SLIME please.
Also, understand that macro code is code that you write. You control
every detail of the code in the macroexpansion. Please check out the
link that Spirol Bousbouras posted to Peter Seibel's chapter on
writing macros, and just glance over it.
That way, you'll be able to discuss this issue and have us respect you
as somebody who tries to fix their knowledge gaps, rather than pity
you as a casualty of groupthink.
- Adlai
I meant to say "Spiros", not "Spirol".
And I'm sorry about the derogatory tone of my message. However, please
understand, Mr Expansion (?), that it's quite exhasperating trying to
offer new information to somebody who just parrots back the same trite
replies. I've heard that there's no use to arguing on the internet...
well, I'm hoping that's wrong. Please consider some of the information
that we (mainly Pascal and Spiros) have put forth in past postings.
- Adlai
On May 16, 2:16 am, Adlai <·········@gmail.com> wrote:
> I meant to say "Spiros", not "Spirol".
>
> And I'm sorry about the derogatory tone of my message. However, please
> understand, Mr Expansion (?), that it's quite exhasperating trying to
> offer new information to somebody who...
What new information? You're mostly repeating yourself now, and yet
you're surprised when I do likewise?
On May 16, 2:00 am, Adlai <·········@gmail.com> wrote:
> On May 16, 8:53 am, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 12:18 am, Adlai <·········@gmail.com> wrote:
> > > with the assistance of macroexpansion tools available in modern IDEs
> > > such as Emacs + SLIME, and a working macro that you'll reuse in the
> > > future is a huge asset.
>
> > You know, most people find it hard to take anything seriously that has
> > "modern IDEs such as Emacs" as a dependent clause. :)
>
> I'm sorry, I was assuming that you could read
I probably shouldn't even dignify this post with a response, after
that jab, but what the hey.
> SLIME adding power!
>
> ... to old (not) useless Emacs!
Allah akbar!
Hallowed are the Ori!
Long live the king!
For ever and ever, amen!
Emotional expressions of faith, solidarity, patriotism, loyalty, or
piety are all well and good but they do not constitute rational
arguments.
> Also, understand that macro code is code that you write. You control
> every detail of the code...
Please understand that in the real world of software development, the
lone programmer doing an entire job by himself is no longer at all
commonplace.
> That way, you'll be able to discuss this issue and have us respect you
> as somebody who tries to fix their knowledge gaps, rather than pity
> you as a casualty of groupthink.
Hey! I've been prospecting on Usenet and I think I've just struck a
rich vein of irony! This one guy, see, he makes all these expressions
of his faith, ignoring reason, and then he accuses his opponent of
being a "casualty of groupthink"!
Series Expansion <·······@gmail.com> wrote in news:2d76760f-0b00-4590-
·················@x6g2000vbg.googlegroups.com:
> Please understand that in the real world of software development, the
> lone programmer doing an entire job by himself is no longer at all
> commonplace.
What's an entire job? If the Lisp programmer implements and maintains
the DSL's for a big project, and 1000 other programmers use those DSL's
as the foundation of that project, do you consider the DSL's an entire
job?
When a huge team of programmers works so closely together that they
interfere with each other, the result is usually not worth a tiny
fraction of the cost. Is that the "commonplace" you're thinking of?
That's the reality of a lot of big projects.
They should be separated into specialized groups, and when the work of
one group affects the work of another, it should make that work easier
and more effective, and not interfere with it. That's one thing DSL's
do.
Well, people, I am out of here. All Java and Lisp programmers here (at
least the ones that know how to have normal conversations), I am sorry
for all the noise that I provoked by putting wood on the fire. And I
don't intend to ever get into a flame war like this again. It is just
pointless and plain stupid, because, if people are flaming, it means
they are so religiously attached to their beliefs that they won't take
any of your arguments seriously and they will conveniently ignore all
good explanations you give.
And, yes Series, I've just shut up, and, if this makes you happy, even
better. If you want to respond to this and say that this last post
proves that I have no more arguments against your arguments, that I
can't disprove your theories, that the only arguments that I had was
to personally attack you and the Java language with not reason at all,
then I beg you, PLEASE do this, take this opportunity to say to
everyone that you were right all the time and that I was wrong.
Seriously. I will NOT try to convince anyone otherwise.
On May 17, 6:04 pm, gugamilare <··········@gmail.com> wrote:
> Well, people, I am out of here. All Java and Lisp programmers here (at
> least the ones that know how to have normal conversations), I am sorry
> for all the noise that I provoked by putting wood on the fire. And I
> don't intend to ever get into a flame war like this again. It is just
> pointless and plain stupid, because, if people are flaming, it means
> they are so religiously attached to their beliefs that they won't take
> any of your arguments seriously and they will conveniently ignore all
> good explanations you give.
That explains your own earlier instances of flaming, then. However I
don't believe it explains "Lew"s.
> And, yes Series, I've just shut up, and, if this makes you happy, even
> better. If you want to respond to this and say that this last post
> proves that I have no more arguments against your arguments, that I
> can't disprove your theories, that the only arguments that I had was
> to personally attack you and the Java language with not reason at all,
> then I beg you, PLEASE do this, take this opportunity to say to
> everyone that you were right all the time and that I was wrong.
> Seriously. I will NOT try to convince anyone otherwise.
Curious, since I suspect that you don't believe that to be the case.
Regardless, your stopping arguing does not prove Lisp inferior; it
merely means you are no longer actively trying to *dis*prove that.
Perhaps you should take some time to formulate some truly cogent
arguments, ones that address some of the key points I have made, and
return eventually, rather than quit. I see two possible avenues of
attack:
1. attempting to directly address the reasoning about how certain
tradeoffs directly follow from the code-substitution behavior of
macros and their arguments; or
2. attempting to argue that despite the pitfalls that I noted, macros
provide rewards that more than offset the costs and risks imposed
by those pitfalls.
I'd wager that option 2 offers a far greater likelihood of success,
since the arguments you'd be attacking in option 1 appear to be just
about ironclad.
Option 2 amounts to satisfactorily answering: "What really useful
things can macros do that functions that take one or more closures as
arguments cannot do?"
On May 20, 5:42 pm, Series Expansion <·······@gmail.com> wrote:
> Option 2 amounts to satisfactorily answering: "What really useful
> things can macros do that functions that take one or more closures as
> arguments cannot do?"
- Running some code in a dynamic context established by the macro
(e.g. some variables locally bound, some local functions defined, ...)
- Introducing new syntax (for example for DSLs).
- Moving some computation at compile time.
- Changing argument evaluation rules.
- Transforming user code (e.g. to Continuation Passing Style).
and there are many others. I encourage the Lisp Gods to add other
examples here :)
Alessio
On May 20, 1:11 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 20, 5:42 pm, Series Expansion <·······@gmail.com> wrote:
>
> > Option 2 amounts to satisfactorily answering: "What really useful
> > things can macros do that functions that take one or more closures as
> > arguments cannot do?"
>
> - Running some code in a dynamic context established by the macro
> (e.g. some variables locally bound, some local functions defined, ...)
A function that takes closure arguments could also, of course, define
local functions and contain local variables.
> - Introducing new syntax (for example for DSLs).
Smalltalk appears to support DSLs fairly well using closures. Most of
its control structures are implemented within Smalltalk using
closures.
> - Moving some computation at compile time.
Calc.exe and copy-and-paste can accomplish that.
> - Changing argument evaluation rules.
Is this useful though?
> - Transforming user code (e.g. to Continuation Passing Style).
Functions that acted on Lisp code as data could accomplish this,
reading Lisp code in one style and outputting the transformed code to
a disk file. This would be safer than an in-place transformation, too,
since it would preserve the original.
On May 23, 2:21 pm, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> > Functions that acted on Lisp code as data could accomplish this,
> > reading Lisp code in one style and outputting the transformed code
>
> Congratulations! You've just invented the macro!
Although, what makes macros different from normal functions is that
they don't evaluate their arguments. In this sense, you could actually
think of something like:
public boolean prime (int x) { blablabla }
as a macro that generates JVM bytecode from the single string argument
that is the entire call -- from public, to the closing }.
- Adlai
On May 23, 7:21 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> > Functions that acted on Lisp code as data could accomplish this,
> > reading Lisp code in one style and outputting the transformed code
>
> Congratulations! You've just invented the macro!
You misunderstand me. I meant a function that would be called once,
with an entire source file as argument, and output an entire new
source file, something distinct from macros, which preprocess a source
file to a temporary file or within main memory prior to its
compilation.
On May 24, 7:04 am, Series Expansion <·······@gmail.com> wrote:
> On May 23, 7:21 am, Paul Foley <····@below.invalid> (http://
>
> public.xdi.org/=pf) wrote:
> > Series Expansion <·······@gmail.com> writes:
> > > Functions that acted on Lisp code as data could accomplish this,
> > > reading Lisp code in one style and outputting the transformed code
>
> > Congratulations! You've just invented the macro!
Yeah, congrats! :)
> You misunderstand me. I meant a function that would be called once,
> with an entire source file as argument, and output an entire new
> source file, something distinct from macros, which preprocess a source
> file to a temporary file or within main memory prior to its
> compilation.
Macros don't process files! They process Lisp code, and Lisp code IS
NOT text in any way, it's a tree-like structure made of Lisp objects
(symbols, lists, numbers, strings, ...).
On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> On May 24, 7:04 am, Series Expansion <·······@gmail.com> wrote:
> > On May 23, 7:21 am, Paul Foley <····@below.invalid> (http://
> > public.xdi.org/=pf) wrote:
> > > Series Expansion <·······@gmail.com> writes:
> > > > Functions that acted on Lisp code as data could accomplish this,
> > > > reading Lisp code in one style and outputting the transformed code
> > > Congratulations! You've just invented the macro!
>
> > You misunderstand me. I meant a function that would be called once,
> > with an entire source file as argument, and output an entire new
> > source file, something distinct from macros, which preprocess a source
> > file to a temporary file or within main memory prior to its
> > compilation.
>
> Macros don't process files! They process Lisp code,
which resides in files, if you know what's good for you and don't want
to have to type in the whole program again every time the power fails,
Windows crashes, or Microsoft releases another update.
> Lisp code IS NOT text in any way, it's a tree-like structure made of
> Lisp objects (symbols, lists, numbers, strings, ...).
Even were this true, it would still need to resolve in files to
survive across sessions. Furthermore, if that were true, there would
be a serious violation of a fundamental standard of language design,
that program source code be susceptible of manipulation as text using
text-oriented tools that lack any particular awareness of the language
in question. This is elaborated upon in another recent post of mine.
On May 24, 7:34 pm, Series Expansion <·······@gmail.com> wrote:
> On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> > Macros don't process files! They process Lisp code,
>
> which resides in files,
No, its printed representation resides in files. Actual Lisp code is
not textual, and it usually resides in memory (though of course it
could be dumped to files, but it probably wouldn't be readable by
humans). Lisp code can be thought as an abstract syntax tree closely
mirroring its printed representation.
> if you know what's good for you and don't want
> to have to type in the whole program again every time the power fails,
> Windows crashes, or Microsoft releases another update.
>
> > Lisp code IS NOT text in any way, it's a tree-like structure made of
> > Lisp objects (symbols, lists, numbers, strings, ...).
>
> Even were this true,
as it is,
> it would still need to resolve in files to
> survive across sessions.
No, you just need a way to automatically recreate the code across
sessions. The most common way is that the programmer edits text
representing Lisp code, and then feeds this text to the Lisp
implementation, that "reads" (parses) it and produces the actual code.
The text itself of course gets saved in files.
> Furthermore, if that were true, there would
> be a serious violation of a fundamental standard of language design,
> that program source code be susceptible of manipulation as text using
> text-oriented tools that lack any particular awareness of the language
> in question. This is elaborated upon in another recent post of mine.
Lisp source code instead is meant to be easily manipulated by a
programmer using Lisp itself. This is the basis for macros. The fact
humans deal to the code in its printed form is only a convenience for
them. You could edit Lisp code without ever modifying text, for
example by using a GUI application that shows the code as a tree.
However, since text is much more versatile, I believe such a GUI will
never be the preferred way of writing Lisp code.
On May 24, 3:11 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 24, 7:34 pm, Series Expansion <·······@gmail.com> wrote:
>
> > On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> > > Macros don't process files! They process Lisp code,
>
> > which resides in files,
>
> No
Yes, source code resides in files. Of course, at the time the macro
processes it, it's working on an image in RAM, but the long-term
storage for source code is in disk files. This is something every
computer programmer should know.
> Actual Lisp code is not textual, and it usually resides in memory
> (though of course it could be dumped to files, but it probably
> wouldn't be readable by humans).
You are describing object code of some sort. I am discussing source
code. Please try to stick to the topic.
> > > Lisp code IS NOT text in any way, it's a tree-like structure made of
> > > Lisp objects (symbols, lists, numbers, strings, ...).
>
> > Even were this true, it would still need to resolve in files to
> survive across sessions.
>
> No
Yes.
> The most common way is that the programmer edits text
> representing Lisp code, and then feeds this text to the Lisp
> implementation, that "reads" (parses) it and produces the actual code.
> The text itself of course gets saved in files.
This is called editing source code, feeding it to the compiler which
produces object code, and the source code gets saved in files.
I'm well aware of how source code, object code, and compilers
interrelate. This is a completely pointless and somewhat condescending
diversion from the original topic, modulo your somewhat odd
terminology. (Is there some reason for avoiding the industry-standard
terms "source code" and "object code"?)
> Lisp source code instead is meant to be easily manipulated by a
> programmer using Lisp itself. This is the basis for macros.
Which confirms that macros act on source code, not (as you seemed to
be implying at one point) object code.
> You could edit Lisp code without ever modifying text, for
> example by using a GUI application that shows the code as a tree.
Directly hacking object code? Not a very good idea, unless you don't
have the source code for whatever reason.
> However, since text is much more versatile, I believe such a GUI will
> never be the preferred way of writing Lisp code.
This doesn't follow -- a GUI can improve the usability of a text
editor, even though it is possible to implement a feasible-to-use (if
clumsy-to-use) text editor without one, whereas you couldn't, say,
implement Photoshop or something similar without a GUI.
On May 26, 8:21 am, Series Expansion <·······@gmail.com> wrote:
> On May 24, 3:11 pm, Alessio Stalla <·············@gmail.com> wrote:
>
> > On May 24, 7:34 pm, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> > > > Macros don't process files! They process Lisp code,
>
> > > which resides in files,
>
> > No
>
> Yes, source code resides in files. Of course, at the time the macro
> processes it, it's working on an image in RAM, but the long-term
> storage for source code is in disk files. This is something every
> computer programmer should know.
Yes.
>
> > Actual Lisp code is not textual, and it usually resides in memory
> > (though of course it could be dumped to files, but it probably
> > wouldn't be readable by humans).
>
> You are describing object code of some sort. I am discussing source
> code. Please try to stick to the topic.
>
> > > > Lisp code IS NOT text in any way, it's a tree-like structure made of
> > > > Lisp objects (symbols, lists, numbers, strings, ...).
>
> > > Even were this true, it would still need to resolve in files to
> > survive across sessions.
>
> > No
>
> Yes.
Yes and no. You can compile a Common Lisp file into an "object
code". But the macroexpansion does without any temporary file being
written out to disk. Unlike the C preprocessor and its descendants.
Plus, Lisp (and Scheme) macro processors have the full equivalent of
the AST in memory to manipulate and eventually the CL compiler takes a
sequence of such representations in order to produce the resulting
object file (or not).
> > The most common way is that the programmer edits text
> > representing Lisp code, and then feeds this text to the Lisp
> > implementation, that "reads" (parses) it and produces the actual code.
> > The text itself of course gets saved in files.
>
> This is called editing source code, feeding it to the compiler which
> produces object code, and the source code gets saved in files.
... but not the result in the intermediate step of macroexpansion.
> I'm well aware of how source code, object code, and compilers
> interrelate. This is a completely pointless and somewhat condescending
> diversion from the original topic, modulo your somewhat odd
> terminology. (Is there some reason for avoiding the industry-standard
> terms "source code" and "object code"?)
What odd terminology?
> > Lisp source code instead is meant to be easily manipulated by a
> > programmer using Lisp itself. This is the basis for macros.
>
> Which confirms that macros act on source code, not (as you seemed to
> be implying at one point) object code.
Nope. Macros act on the equivalent of the AST of other programming
language; which in Lisp it happens to be a first class data type,
hence giving the language its power.
> > You could edit Lisp code without ever modifying text, for
> > example by using a GUI application that shows the code as a tree.
>
> Directly hacking object code? Not a very good idea, unless you don't
> have the source code for whatever reason.
Since there is a 1-1 (mostly) correspondence between code and data in
Lisp, that is possible. Maybe not desirable, but possible for sure.
Nothing forbids you to save the results as source code.
> > However, since text is much more versatile, I believe such a GUI will
> > never be the preferred way of writing Lisp code.
>
> This doesn't follow -- a GUI can improve the usability of a text
> editor, even though it is possible to implement a feasible-to-use (if
> clumsy-to-use) text editor without one, whereas you couldn't, say,
> implement Photoshop or something similar without a GUI.
Of course a GUI can improve the usability of a program. The point is
that a GUI that allows you to directly edit the AST of any program
instead of text may not be really useful. The fact that writing such
a GUI in Lisp is somewhat easier does not mean that it is something
that should be done.
Cheers
--
Marco
On May 26, 4:35 am, Marco Antoniotti <·······@gmail.com> wrote:
> On May 26, 8:21 am, Series Expansion <·······@gmail.com> wrote:
> > On May 24, 3:11 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > On May 24, 7:34 pm, Series Expansion <·······@gmail.com> wrote:
> > > > On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> > > > > Lisp code IS NOT text in any way, it's a tree-like structure made of
> > > > > Lisp objects (symbols, lists, numbers, strings, ...).
>
> > > > Even were this true, it would still need to reside in files to
> > > > survive across sessions.
>
> > > No
>
> > Yes.
>
> Yes and no.
Yes and yes.
Data kept solely in volatile storage will not survive power-down of
the hardware. Every computer programmer should know this.
> You can compile a Common Lisp file into an "object code". But the
> macroexpansion does without any temporary file being written out to
> disk.
This is true for some C implementations as well. It does not confer
magical, otherwise-impossible powers upon the implementation, however,
merely a boost in performance at the expense of memory consumption.
(Some C implementations do somewhat the reverse: create "compiled
header" files from common header files.)
> Plus, Lisp (and Scheme) macro processors have the full equivalent of
> the AST in memory
That Lisp's macro processor is syntactically aware, unlike C's, is
also not a source of magical powers. It does, however, prevent macros
from as easily generating syntactically incorrect output, a danger
which I chose to ignore in this debate as it is a minor one whose
consequences are generally readily identifiable.
> > > The most common way is that the programmer edits text
> > > representing Lisp code, and then feeds this text to the Lisp
> > > implementation, that "reads" (parses) it and produces the actual code.
> > > The text itself of course gets saved in files.
>
> > This is called editing source code, feeding it to the compiler which
> > produces object code, and the source code gets saved in files.
>
> ... but not the result in the intermediate step of macroexpansion.
As I stated before, keeping the preprocessed source code in memory
instead of writing it to disk may grant a performance improvement but
does not grant magical powers.
> > I'm well aware of how source code, object code, and compilers
> > interrelate. This is a completely pointless and somewhat condescending
> > diversion from the original topic, modulo your somewhat odd
> > terminology. (Is there some reason for avoiding the industry-standard
> > terms "source code" and "object code"?)
>
> What odd terminology?
Alessio was, for some reason, using "text representing Lisp code" to
refer to what would normally be called "source code", and "actual
code" to refer to what would normally be called "object code".
> > > Lisp source code instead is meant to be easily manipulated by a
> > > programmer using Lisp itself. This is the basis for macros.
>
> > Which confirms that macros act on source code, not (as you seemed to
> > be implying at one point) object code.
>
> Nope.
Yep.
> Macros act on the equivalent of the AST of other programming
> language; which in Lisp it happens to be a first class data type,
> hence giving the language its power.
That they are syntax-aware is not in dispute. That this grants them
magical powers with respect to naming variables is in dispute.
The C preprocessor does a straight lexical substitution. The Lisp
macro operates on the parse tree of the source code and applies an
arbitrary function to it to compute its invocation's replacement in
the source code. This is, in some ways, more powerful, but the output
source code, whether it is saved to disk or not before being compiled,
does not gain magical powers that hand-written source code would have
lacked. To claim otherwise is illogical.
> > > You could edit Lisp code without ever modifying text, for
> > > example by using a GUI application that shows the code as a tree.
>
> > Directly hacking object code? Not a very good idea, unless you don't
> > have the source code for whatever reason.
>
> Since there is a 1-1 (mostly) correspondence between code and data in
> Lisp, that is possible.
It is possible to directly hack any object code.
> Maybe not desirable, but possible for sure. Nothing forbids you to
> save the results as source code.
I thought we were discussing object code. Or do you mean decompile the
results and save them as source code?
> > > However, since text is much more versatile, I believe such a GUI will
> > > never be the preferred way of writing Lisp code.
>
> > This doesn't follow -- a GUI can improve the usability of a text
> > editor, even though it is possible to implement a feasible-to-use (if
> > clumsy-to-use) text editor without one, whereas you couldn't, say,
> > implement Photoshop or something similar without a GUI.
>
> Of course a GUI can improve the usability of a program.
Well, I guess that's settled, then.
On May 27, 4:28 am, Series Expansion <·······@gmail.com> wrote:
> On May 26, 4:35 am, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On May 26, 8:21 am, Series Expansion <·······@gmail.com> wrote:
> > > On May 24, 3:11 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > > On May 24, 7:34 pm, Series Expansion <·······@gmail.com> wrote:
> > > > > On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> > > > > > Lisp code IS NOT text in any way, it's a tree-like structure made of
> > > > > > Lisp objects (symbols, lists, numbers, strings, ...).
>
> > > > > Even were this true, it would still need to reside in files to
> > > > > survive across sessions.
>
> > > > No
>
> > > Yes.
>
> > Yes and no.
>
> Yes and yes.
>
> Data kept solely in volatile storage will not survive power-down of
> the hardware. Every computer programmer should know this.
Yes. That is why we print CDs and kill trees.
> > You can compile a Common Lisp file into an "object code". But the
> > macroexpansion does without any temporary file being written out to
> > disk.
>
> This is true for some C implementations as well. It does not confer
> magical, otherwise-impossible powers upon the implementation, however,
> merely a boost in performance at the expense of memory consumption.
It adds expressivity and easiness of extensibility to the language.
Not magical, but useful nevertheless. And this is not a feature of
Lisp, it is the raison d'etre of "macro processors", like the OCaml
one. Common Lisp and Scheme are a tad better because they are better
integrated with the language, to the extent that many standard
constructs are indeed macros.
> (Some C implementations do somewhat the reverse: create "compiled
> header" files from common header files.)
>
> > Plus, Lisp (and Scheme) macro processors have the full equivalent of
> > the AST in memory
>
> That Lisp's macro processor is syntactically aware, unlike C's, is
> also not a source of magical powers. It does, however, prevent macros
> from as easily generating syntactically incorrect output, a danger
> which I chose to ignore in this debate as it is a minor one whose
> consequences are generally readily identifiable.
Choose your terminology as you wish. Lisp and Scheme (and Dylan and
few other ones) have macro systems better integrated in the language
than any other one. This integration does give you more power.
Whichever it is its nature - magical or not - is something really not
worth discussing.
>
> > > > The most common way is that the programmer edits text
> > > > representing Lisp code, and then feeds this text to the Lisp
> > > > implementation, that "reads" (parses) it and produces the actual code.
> > > > The text itself of course gets saved in files.
>
> > > This is called editing source code, feeding it to the compiler which
> > > produces object code, and the source code gets saved in files.
>
> > ... but not the result in the intermediate step of macroexpansion.
>
> As I stated before, keeping the preprocessed source code in memory
> instead of writing it to disk may grant a performance improvement but
> does not grant magical powers.
But that is not the point. A compiler creates an AST and then it does
something to it. In Lisp and in other systems (with varying levels of
integration) this AST manipulation is exposed to the programmer. You
do not have much control over the Java or C++ AST unless you are a -
say - gcc hacker.
>
> > > I'm well aware of how source code, object code, and compilers
> > > interrelate. This is a completely pointless and somewhat condescending
> > > diversion from the original topic, modulo your somewhat odd
> > > terminology. (Is there some reason for avoiding the industry-standard
> > > terms "source code" and "object code"?)
>
> > What odd terminology?
>
> Alessio was, for some reason, using "text representing Lisp code" to
> refer to what would normally be called "source code", and "actual
> code" to refer to what would normally be called "object code".
Fine. We are all grown up and can tell the difference.
> > > > Lisp source code instead is meant to be easily manipulated by a
> > > > programmer using Lisp itself. This is the basis for macros.
>
> > > Which confirms that macros act on source code, not (as you seemed to
> > > be implying at one point) object code.
>
> > Nope.
>
> Yep.
I said no. You should explain why I am wrong.
> > Macros act on the equivalent of the AST of other programming
> > language; which in Lisp it happens to be a first class data type,
> > hence giving the language its power.
>
> That they are syntax-aware is not in dispute. That this grants them
> magical powers with respect to naming variables is in dispute.
>
> The C preprocessor does a straight lexical substitution. The Lisp
> macro operates on the parse tree of the source code and applies an
> arbitrary function to it to compute its invocation's replacement in
> the source code. This is, in some ways, more powerful, but the output
> source code, whether it is saved to disk or not before being compiled,
> does not gain magical powers that hand-written source code would have
> lacked. To claim otherwise is illogical.
Then why don't you read exclusively the files produced by gcc -E?
They are as "raw source code" as they get. Or maybe we should just
program everything in raw assembly. Macros give you expressive
power. In Lisp (etc etc) they are better integrated in the language
than in standard Java or C or C++. Again, whether this is magical, I
don't care. But I like that power.
>
> > > > You could edit Lisp code without ever modifying text, for
> > > > example by using a GUI application that shows the code as a tree.
>
> > > Directly hacking object code? Not a very good idea, unless you don't
> > > have the source code for whatever reason.
>
> > Since there is a 1-1 (mostly) correspondence between code and data in
> > Lisp, that is possible.
>
> It is possible to directly hack any object code.
Yes... and this is the Turing equivalence argument. In principle it
is possible to program the Linux kernel (or the Lisp Machine firmware,
for the record) on a Turing Machine.
> > Maybe not desirable, but possible for sure. Nothing forbids you to
> > save the results as source code.
>
> I thought we were discussing object code. Or do you mean decompile the
> results and save them as source code?
You just griped about macros generating "source code" at the end.
Suit yourself.
> > > > However, since text is much more versatile, I believe such a GUI will
> > > > never be the preferred way of writing Lisp code.
>
> > > This doesn't follow -- a GUI can improve the usability of a text
> > > editor, even though it is possible to implement a feasible-to-use (if
> > > clumsy-to-use) text editor without one, whereas you couldn't, say,
> > > implement Photoshop or something similar without a GUI.
>
> > Of course a GUI can improve the usability of a program.
>
> Well, I guess that's settled, then.
Yes. But the point is that macros - especially when well integrated
in a programming language - improve the overall language usability.
Cheers
--
Marco
Marco Antoniotti <·······@gmail.com> writes:
>> It is possible to directly hack any object code.
>
> Yes... and this is the Turing equivalence argument. In principle it
> is possible to program the Linux kernel (or the Lisp Machine firmware,
> for the record) on a Turing Machine.
Even better: in principle it's possible to program strong AI directly
on a Turing Machine. Good luck! :-)
--
__Pascal Bourguignon__
On May 27, 3:02 am, Marco Antoniotti <·······@gmail.com> wrote:
> On May 27, 4:28 am, Series Expansion <·······@gmail.com> wrote:
> > On May 26, 4:35 am, Marco Antoniotti <·······@gmail.com> wrote:
> > > On May 26, 8:21 am, Series Expansion <·······@gmail.com> wrote:
> > > > On May 24, 3:11 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > > > On May 24, 7:34 pm, Series Expansion <·······@gmail.com> wrote:
> > > > > > On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> > > > > > > Lisp code IS NOT text in any way, it's a tree-like structure made of
> > > > > > > Lisp objects (symbols, lists, numbers, strings, ...).
> > > > > > Even were this true, it would still need to reside in files to
> > > > > > survive across sessions.
> > > > > No
> > > > Yes.
> > > Yes and no.
> > Yes and yes.
>
> > Data kept solely in volatile storage will not survive power-down of
> > the hardware. Every computer programmer should know this.
>
> Yes.
It is gratifying that that point has now been settled.
> > > You can compile a Common Lisp file into an "object code". But the
> > > macroexpansion does without any temporary file being written out to
> > > disk.
>
> > This is true for some C implementations as well. It does not confer
> > magical, otherwise-impossible powers upon the implementation, however,
> > merely a boost in performance at the expense of memory consumption.
>
> It adds expressivity and easiness of extensibility to the language.
> Not magical, but useful nevertheless.
Useful, perhaps, but, as I stated, not magical.
> > > Plus, Lisp (and Scheme) macro processors have the full equivalent of
> > > the AST in memory
>
> > That Lisp's macro processor is syntactically aware, unlike C's, is
> > also not a source of magical powers. It does, however, prevent macros
> > from as easily generating syntactically incorrect output, a danger
> > which I chose to ignore in this debate as it is a minor one whose
> > consequences are generally readily identifiable.
>
> Choose your terminology as you wish. Lisp and Scheme (and Dylan and
> few other ones) have macro systems better integrated in the language
> than any other one. This integration does give you more power.
Yet it does not grant some of the magical capabilities that have been
attributed to it previously in this thread.
> > > > > The most common way is that the programmer edits text
> > > > > representing Lisp code, and then feeds this text to the Lisp
> > > > > implementation, that "reads" (parses) it and produces the actual code.
> > > > > The text itself of course gets saved in files.
>
> > > > This is called editing source code, feeding it to the compiler which
> > > > produces object code, and the source code gets saved in files.
>
> > > ... but not the result in the intermediate step of macroexpansion.
>
> > As I stated before, keeping the preprocessed source code in memory
> > instead of writing it to disk may grant a performance improvement but
> > does not grant magical powers.
>
> But that is not the point.
But that is exactly the point. Source code is source code. Where it
physically resides is irrelevant, except to the matter of its
preservation across sessions, for which reason unpreprocessed source
code should exist on disk.
However, its preservation across sessions was not the original issue
here, until you brought it up apparently as a diversionary tactic.
> > > > I'm well aware of how source code, object code, and compilers
> > > > interrelate. This is a completely pointless and somewhat condescending
> > > > diversion from the original topic, modulo your somewhat odd
> > > > terminology. (Is there some reason for avoiding the industry-standard
> > > > terms "source code" and "object code"?)
>
> > > What odd terminology?
>
> > Alessio was, for some reason, using "text representing Lisp code" to
> > refer to what would normally be called "source code", and "actual
> > code" to refer to what would normally be called "object code".
>
> Fine. We are all grown up and can tell the difference.
If this is meant to imply a personal attack, I should alert you to the
fact that such attacks do not constitute logical arguments in favor of
either Lisp or Java. However, the tendency of Lispers to frequently
make such remarks might itself be regarded as circumstantial evidence
favoring Java; Lisp may be tarnished in the estimation of some readers
by the company it keeps.
> > > > > Lisp source code instead is meant to be easily manipulated by a
> > > > > programmer using Lisp itself. This is the basis for macros.
>
> > > > Which confirms that macros act on source code, not (as you seemed to
> > > > be implying at one point) object code.
>
> > > Nope.
>
> > Yep.
>
> I said no. You should explain why I am wrong.
You are contradicting this earlier claim, posted by your own side:
> > > > > Lisp source code instead is meant to be easily manipulated by a
> > > > > programmer using Lisp itself. This is the basis for macros.
If you and Alessio disagree as to which macros operate upon, source
code or object code, then perhaps you should work that out between the
two of you before either of you continues to press your attack upon
Java. Otherwise, we on the Java side can logically be expected to
seize upon such internal inconsistencies in your position and exploit
them to destroy your side's credibility, thus inexorably swaying the
audience in favor of Java. You are therefore in danger of losing the
debate. United you may prevail; divided you court defeat.
> > > Macros act on the equivalent of the AST of other programming
> > > language; which in Lisp it happens to be a first class data type,
> > > hence giving the language its power.
>
> > That they are syntax-aware is not in dispute. That this grants them
> > magical powers with respect to naming variables is in dispute.
>
> > The C preprocessor does a straight lexical substitution. The Lisp
> > macro operates on the parse tree of the source code and applies an
> > arbitrary function to it to compute its invocation's replacement in
> > the source code. This is, in some ways, more powerful, but the output
> > source code, whether it is saved to disk or not before being compiled,
> > does not gain magical powers that hand-written source code would have
> > lacked. To claim otherwise is illogical.
>
> Then why don't you read exclusively the files produced by gcc -E?
> They are as "raw source code" as they get.
That is an issue of readability.
> Or maybe we should just program everything in raw assembly.
That is an apples-to-oranges comparison; the translation from C to
assembly is a matter of compilation, not just preprocessing the
compiler's input.
> Macros give you expressive power.
That is not in dispute, but it is also irrelevant to the current point
of contention.
> > > > > You could edit Lisp code without ever modifying text, for
> > > > > example by using a GUI application that shows the code as a tree.
>
> > > > Directly hacking object code? Not a very good idea, unless you don't
> > > > have the source code for whatever reason.
>
> > > Since there is a 1-1 (mostly) correspondence between code and data in
> > > Lisp, that is possible.
>
> > It is possible to directly hack any object code.
>
> Yes
Noted.
> > > Maybe not desirable, but possible for sure. Nothing forbids you to
> > > save the results as source code.
>
> > I thought we were discussing object code. Or do you mean decompile the
> > results and save them as source code?
>
> You just griped about macros generating "source code" at the end.
You seem to be confused.
> > > > > However, since text is much more versatile, I believe such a GUI will
> > > > > never be the preferred way of writing Lisp code.
>
> > > > This doesn't follow -- a GUI can improve the usability of a text
> > > > editor, even though it is possible to implement a feasible-to-use (if
> > > > clumsy-to-use) text editor without one, whereas you couldn't, say,
> > > > implement Photoshop or something similar without a GUI.
>
> > > Of course a GUI can improve the usability of a program.
>
> > Well, I guess that's settled, then.
>
> Yes. But the point is that macros - especially when well integrated
> in a programming language - improve the overall language usability.
What they are not, in the vernacular, is a "silver bullet", contrary
to claims fronted here earlier.
And while we are on the subject of Java's superiority to Lisp, when I
did a bit of digging I turned up an arguably even larger skeleton in
Common Lisp's closet: catch and throw. While these may share the names
of well-behaved constructs in the Java programming language, a cursory
examination of their definition clearly establishes that they are
anything but. Indeed, it seems they can be used to implement the worst
spaghettifying feature ever to disgrace the BASIC programming
language: a computed "goto".
I rest my case, though I will continue to provide rebuttal evidence
and testimony at need.
First of all apologies for the cross posting. Follow ups to
comp.lang.lisp
On May 28, 7:37 am, Series Expansion <·······@gmail.com> wrote:
> On May 27, 3:02 am, Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
> > On May 27, 4:28 am, Series Expansion <·······@gmail.com> wrote:
> > > On May 26, 4:35 am, Marco Antoniotti <·······@gmail.com> wrote:
> > > > On May 26, 8:21 am, Series Expansion <·······@gmail.com> wrote:
> > > > > On May 24, 3:11 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > > > > On May 24, 7:34 pm, Series Expansion <·······@gmail.com> wrote:
> > > > > > > On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> > > > > > > > Lisp code IS NOT text in any way, it's a tree-like structure made of
> > > > > > > > Lisp objects (symbols, lists, numbers, strings, ...).
> > > > > > > Even were this true, it would still need to reside in files to
> > > > > > > survive across sessions.
> > > > > > No
> > > > > Yes.
> > > > Yes and no.
> > > Yes and yes.
>
> > > Data kept solely in volatile storage will not survive power-down of
> > > the hardware. Every computer programmer should know this.
>
> > Yes.
>
> It is gratifying that that point has now been settled.
>
> > > > You can compile a Common Lisp file into an "object code". But the
> > > > macroexpansion does without any temporary file being written out to
> > > > disk.
>
> > > This is true for some C implementations as well. It does not confer
> > > magical, otherwise-impossible powers upon the implementation, however,
> > > merely a boost in performance at the expense of memory consumption.
>
> > It adds expressivity and easiness of extensibility to the language.
> > Not magical, but useful nevertheless.
>
> Useful, perhaps, but, as I stated, not magical.
Never said magical. Powerful yes.
>
> > > > Plus, Lisp (and Scheme) macro processors have the full equivalent of
> > > > the AST in memory
>
> > > That Lisp's macro processor is syntactically aware, unlike C's, is
> > > also not a source of magical powers. It does, however, prevent macros
> > > from as easily generating syntactically incorrect output, a danger
> > > which I chose to ignore in this debate as it is a minor one whose
> > > consequences are generally readily identifiable.
>
> > Choose your terminology as you wish. Lisp and Scheme (and Dylan and
> > few other ones) have macro systems better integrated in the language
> > than any other one. This integration does give you more power.
>
> Yet it does not grant some of the magical capabilities that have been
> attributed to it previously in this thread.
I don't know anything about magic. I know about Java (at least as
much as you) and Common Lisp.
>
> > > > > > The most common way is that the programmer edits text
> > > > > > representing Lisp code, and then feeds this text to the Lisp
> > > > > > implementation, that "reads" (parses) it and produces the actual code.
> > > > > > The text itself of course gets saved in files.
>
> > > > > This is called editing source code, feeding it to the compiler which
> > > > > produces object code, and the source code gets saved in files.
>
> > > > ... but not the result in the intermediate step of macroexpansion.
>
> > > As I stated before, keeping the preprocessed source code in memory
> > > instead of writing it to disk may grant a performance improvement but
> > > does not grant magical powers.
>
> > But that is not the point.
>
> But that is exactly the point. Source code is source code. Where it
> physically resides is irrelevant, except to the matter of its
> preservation across sessions, for which reason unpreprocessed source
> code should exist on disk.
>
> However, its preservation across sessions was not the original issue
> here, until you brought it up apparently as a diversionary tactic.
I was under the impression that you did not understand how Lisp macros
work. I am still under that impression. I tried to help.
>
> > > > > I'm well aware of how source code, object code, and compilers
> > > > > interrelate. This is a completely pointless and somewhat condescending
> > > > > diversion from the original topic, modulo your somewhat odd
> > > > > terminology. (Is there some reason for avoiding the industry-standard
> > > > > terms "source code" and "object code"?)
>
> > > > What odd terminology?
>
> > > Alessio was, for some reason, using "text representing Lisp code" to
> > > refer to what would normally be called "source code", and "actual
> > > code" to refer to what would normally be called "object code".
>
> > Fine. We are all grown up and can tell the difference.
>
> If this is meant to imply a personal attack, I should alert you to the
> fact that such attacks do not constitute logical arguments in favor of
> either Lisp or Java. However, the tendency of Lispers to frequently
> make such remarks might itself be regarded as circumstantial evidence
> favoring Java; Lisp may be tarnished in the estimation of some readers
> by the company it keeps.
I restate... we should all (meaning: all) be able to tell the
difference.
>
> > > > > > Lisp source code instead is meant to be easily manipulated by a
> > > > > > programmer using Lisp itself. This is the basis for macros.
>
> > > > > Which confirms that macros act on source code, not (as you seemed to
> > > > > be implying at one point) object code.
>
> > > > Nope.
>
> > > Yep.
>
> > I said no. You should explain why I am wrong.
>
> You are contradicting this earlier claim, posted by your own side:
>
> > > > > > Lisp source code instead is meant to be easily manipulated by a
> > > > > > programmer using Lisp itself. This is the basis for macros.
>
> If you and Alessio disagree as to which macros operate upon, source
> code or object code, then perhaps you should work that out between the
> two of you before either of you continues to press your attack upon
> Java. Otherwise, we on the Java side can logically be expected to
> seize upon such internal inconsistencies in your position and exploit
> them to destroy your side's credibility, thus inexorably swaying the
> audience in favor of Java. You are therefore in danger of losing the
> debate. United you may prevail; divided you court defeat.
Lisp macros, and Alessio, who is sitting right now in the same room,
agrees with me and with many people who actually know Java, operate on
the equivalent of the AST of the program. In Java you do not have
anything similar.
>
>
>
> > > > Macros act on the equivalent of the AST of other programming
> > > > language; which in Lisp it happens to be a first class data type,
> > > > hence giving the language its power.
>
> > > That they are syntax-aware is not in dispute. That this grants them
> > > magical powers with respect to naming variables is in dispute.
>
> > > The C preprocessor does a straight lexical substitution. The Lisp
> > > macro operates on the parse tree of the source code and applies an
> > > arbitrary function to it to compute its invocation's replacement in
> > > the source code. This is, in some ways, more powerful, but the output
> > > source code, whether it is saved to disk or not before being compiled,
> > > does not gain magical powers that hand-written source code would have
> > > lacked. To claim otherwise is illogical.
>
> > Then why don't you read exclusively the files produced by gcc -E?
> > They are as "raw source code" as they get.
>
> That is an issue of readability.
Yes. And that is the reason why Lisp macros give you power you do not
have in Java.
>
> > Or maybe we should just program everything in raw assembly.
>
> That is an apples-to-oranges comparison; the translation from C to
> assembly is a matter of compilation, not just preprocessing the
> compiler's input.
Yes. And Lisp macros are on par. They can do (almost) arbitrary
source-to-source transformations. As such they are more powerful than
the C preprocessor and derivatives and something that simply is not
there in Java.
>
> > Macros give you expressive power.
>
> That is not in dispute, but it is also irrelevant to the current point
> of contention.
>
> > > > > > You could edit Lisp code without ever modifying text, for
> > > > > > example by using a GUI application that shows the code as a tree.
>
> > > > > Directly hacking object code? Not a very good idea, unless you don't
> > > > > have the source code for whatever reason.
>
> > > > Since there is a 1-1 (mostly) correspondence between code and data in
> > > > Lisp, that is possible.
>
> > > It is possible to directly hack any object code.
>
> > Yes
>
> Noted.
>
> > > > Maybe not desirable, but possible for sure. Nothing forbids you to
> > > > save the results as source code.
>
> > > I thought we were discussing object code. Or do you mean decompile the
> > > results and save them as source code?
>
> > You just griped about macros generating "source code" at the end.
>
> You seem to be confused.
Of course I am. I have few ideas but confused.
>
> > > > > > However, since text is much more versatile, I believe such a GUI will
> > > > > > never be the preferred way of writing Lisp code.
>
> > > > > This doesn't follow -- a GUI can improve the usability of a text
> > > > > editor, even though it is possible to implement a feasible-to-use (if
> > > > > clumsy-to-use) text editor without one, whereas you couldn't, say,
> > > > > implement Photoshop or something similar without a GUI.
>
> > > > Of course a GUI can improve the usability of a program.
>
> > > Well, I guess that's settled, then.
>
> > Yes. But the point is that macros - especially when well integrated
> > in a programming language - improve the overall language usability.
>
> What they are not, in the vernacular, is a "silver bullet", contrary
> to claims fronted here earlier.
They are a "very good thing"TM which give the programmer power.
Again, in Java there is nothing similar.
>
> And while we are on the subject of Java's superiority to Lisp, when I
> did a bit of digging I turned up an arguably even larger skeleton in
> Common Lisp's closet: catch and throw. While these may share the names
> of well-behaved constructs in the Java programming language, a cursory
> examination of their definition clearly establishes that they are
> anything but. Indeed, it seems they can be used to implement the worst
> spaghettifying feature ever to disgrace the BASIC programming
> language: a computed "goto".
If you took the time to get your level of knowledge of Common Lisp
near the level of competence I or Alessio or many other people here
(in comp.lang.lisp) have with Java, you would have dug out prog,
tagbody and go, not to speak of other cockraches in CL (every
cockroach is beautiful to his mother). What you completely missed are
handler-bind, handler-case, restart-bind etc etc and in general the
whole exception handling machinery which inspired C++ and - you
guessed it - Java. You also missed with-open-file, which (1) is a
macro and (2) it clearly states the intent of the programmer, and (3)
it is far better than theBufferedReader x ... try { x = new
BufferedReader(...); } finally { ... x.close(); ... } idiom.
>
> I rest my case, though I will continue to provide rebuttal evidence
> and testimony at need.
Suit yourself. We'll be waiting for you to get up to speed on CL.
Remember - and I am not apologizing for sounding patronizing; I am
patronizing - I know at least as much Java as you do and I know that
many lispers are in the same situation. The opposite, with you and CL
does not seem to be true.
Cheers
--
Marco
On May 28, 11:09 am, Marco Antoniotti <·······@gmail.com> wrote:
> First of all apologies for the cross posting. Follow ups to
> comp.lang.lisp
I don't think so.
> On May 28, 7:37 am, Series Expansion <·······@gmail.com> wrote:
> > On May 27, 3:02 am, Marco Antoniotti <·······@gmail.com> wrote:
> > > On May 27, 4:28 am, Series Expansion <·······@gmail.com> wrote:
> > > > On May 26, 4:35 am, Marco Antoniotti <·······@gmail.com> wrote:
> > > > > On May 26, 8:21 am, Series Expansion <·······@gmail.com> wrote:
> > > > > > On May 24, 3:11 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > > > > > On May 24, 7:34 pm, Series Expansion <·······@gmail.com> wrote:
> > > > > > > > On May 24, 6:42 am, Alessio Stalla <·············@gmail.com> wrote:
> > > > > You can compile a Common Lisp file into an "object code". But the
> > > > > macroexpansion does without any temporary file being written out to
> > > > > disk.
>
> > > > This is true for some C implementations as well. It does not confer
> > > > magical, otherwise-impossible powers upon the implementation, however,
> > > > merely a boost in performance at the expense of memory consumption.
>
> > > It adds expressivity and easiness of extensibility to the language.
> > > Not magical, but useful nevertheless.
>
> > Useful, perhaps, but, as I stated, not magical.
>
> Never said magical. Powerful yes.
Maybe you didn't, but some people certainly did impute effectively-
magical powers to Lisp macros.
> > > > > Plus, Lisp (and Scheme) macro processors have the full equivalent of
> > > > > the AST in memory
>
> > > > That Lisp's macro processor is syntactically aware, unlike C's, is
> > > > also not a source of magical powers. It does, however, prevent macros
> > > > from as easily generating syntactically incorrect output, a danger
> > > > which I chose to ignore in this debate as it is a minor one whose
> > > > consequences are generally readily identifiable.
>
> > > Choose your terminology as you wish. Lisp and Scheme (and Dylan and
> > > few other ones) have macro systems better integrated in the language
> > > than any other one. This integration does give you more power.
>
> > Yet it does not grant some of the magical capabilities that have been
> > attributed to it previously in this thread.
>
> I don't know anything about magic.
Then perhaps you shouldn't continue this debate?
> > > > > > > The most common way is that the programmer edits text
> > > > > > > representing Lisp code, and then feeds this text to the Lisp
> > > > > > > implementation, that "reads" (parses) it and produces the actual code.
> > > > > > > The text itself of course gets saved in files.
>
> > > > > > This is called editing source code, feeding it to the compiler which
> > > > > > produces object code, and the source code gets saved in files.
>
> > > > > ... but not the result in the intermediate step of macroexpansion.
>
> > > > As I stated before, keeping the preprocessed source code in memory
> > > > instead of writing it to disk may grant a performance improvement but
> > > > does not grant magical powers.
>
> > > But that is not the point.
>
> > But that is exactly the point. Source code is source code. Where it
> > physically resides is irrelevant, except to the matter of its
> > preservation across sessions, for which reason unpreprocessed source
> > code should exist on disk.
>
> > However, its preservation across sessions was not the original issue
> > here, until you brought it up apparently as a diversionary tactic.
>
> I was under the impression that you did not understand how Lisp macros
> work.
Your mistake.
> > You are contradicting this earlier claim, posted by your own side:
>
> > > > > > > Lisp source code instead is meant to be easily manipulated by a
> > > > > > > programmer using Lisp itself. This is the basis for macros.
>
> > If you and Alessio disagree as to which macros operate upon, source
> > code or object code, then perhaps you should work that out between the
> > two of you before either of you continues to press your attack upon
> > Java. Otherwise, we on the Java side can logically be expected to
> > seize upon such internal inconsistencies in your position and exploit
> > them to destroy your side's credibility, thus inexorably swaying the
> > audience in favor of Java. You are therefore in danger of losing the
> > debate. United you may prevail; divided you court defeat.
>
> Lisp macros, and Alessio, who is sitting right now in the same room,
> agrees with me
He clearly does not, since he said Lisp macros operate on source code
and you said they operate on object code.
For what it's worth, his claim seems to me the more credible one.
> and with many people who actually know Java
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.
I know plenty of Java. My job involves Java. The implication made here
that I don't know Java is a particularly severe insult, and just as
irrelevant and unprovoked as all the others that are wearing on my
patience these days.
[Java lacks macros]
Irrelevant to the issue of which Lisp's operate on, source or object
code.
> > > > That they are syntax-aware is not in dispute. That this grants them
> > > > magical powers with respect to naming variables is in dispute.
>
> > > > The C preprocessor does a straight lexical substitution. The Lisp
> > > > macro operates on the parse tree of the source code and applies an
> > > > arbitrary function to it to compute its invocation's replacement in
> > > > the source code. This is, in some ways, more powerful, but the output
> > > > source code, whether it is saved to disk or not before being compiled,
> > > > does not gain magical powers that hand-written source code would have
> > > > lacked. To claim otherwise is illogical.
>
> > > Then why don't you read exclusively the files produced by gcc -E?
> > > They are as "raw source code" as they get.
>
> > That is an issue of readability.
>
> Yes. And that is the reason why Lisp macros give you power you do not
> have in Java.
Java gives you safety you do not have in Lisp. Did you have a point to
make here? Nobody claimed Lisp macros weren't powerful; I just
disputed an implication that they had powers of omniscience and
similar things that lie beyond the reach of Turing-equivalent systems.
> > > Or maybe we should just program everything in raw assembly.
>
> > That is an apples-to-oranges comparison; the translation from C to
> > assembly is a matter of compilation, not just preprocessing the
> > compiler's input.
>
> Yes.
Thank you for realizing that.
> And Lisp macros are on par.
No.
> They can do (almost) arbitrary source-to-source transformations.
Almost arbitrary. There are some that they cannot do, including any
that would require omniscience, or knowledge of the whole code-base
including all the unwritten future code the output might eventually be
linked with, or prescience, or similar powers.
> > > > > Maybe not desirable, but possible for sure. Nothing forbids you to
> > > > > save the results as source code.
>
> > > > I thought we were discussing object code. Or do you mean decompile the
> > > > results and save them as source code?
>
> > > You just griped about macros generating "source code" at the end.
>
> > You seem to be confused.
>
> Of course I am. I have few ideas but confused.
Perhaps you should stop posting until you've gotten un-confused.
> > > Yes. But the point is that macros - especially when well integrated
> > > in a programming language - improve the overall language usability.
>
> > What they are not, in the vernacular, is a "silver bullet", contrary
> > to claims fronted here earlier.
>
> They are a "very good thing"TM which give the programmer power.
> Again, in Java there is nothing similar.
And Lisp lacks things that Java has.
When you actually have a point of some sort, please be sure to let me
know.
> > And while we are on the subject of Java's superiority to Lisp, when I
> > did a bit of digging I turned up an arguably even larger skeleton in
> > Common Lisp's closet: catch and throw. While these may share the names
> > of well-behaved constructs in the Java programming language, a cursory
> > examination of their definition clearly establishes that they are
> > anything but. Indeed, it seems they can be used to implement the worst
> > spaghettifying feature ever to disgrace the BASIC programming
> > language: a computed "goto".
>
> If you took the time to get your level of knowledge of Common Lisp
> near the level of competence I or Alessio or many other people here
> (in comp.lang.lisp) have with Java
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.
> you would have dug out prog, tagbody and go, not to speak of other
> cockraches in CL (every cockroach is beautiful to his mother).
Cockroaches nest in any old enough legacy system, like they do in
older tenements. C has its share, which C++ inherited. Java is
refreshingly almost free of them ... though Vector and Hashtable might
qualify. At least they aren't prone to completely blowing things up.
> What you completely missed are handler-bind, handler-case,
> restart-bind etc etc
Oh, I missed nothing; I just didn't find those relevant to proving
that Lisp contains serious dangers that will make it difficult to
maintain large bodies of Lisp code in large teams.
> You also missed with-open-file
I don't care for the implication that I should have commented on
something I did not find relevant.
> which (1) is a macro and (2) it clearly states the intent of
> the programmer, and (3) it is far better than theBufferedReader
> x ... try { x = new BufferedReader(...); } finally { ...
> x.close(); ... } idiom.
C++ gives you something similar through RAII. Neither is relevant to
the danger posed by unfettered macro use. While with-open-file sounds
nifty, it comes at a steep price, one large team-oriented development
efforts might be ill able to afford.
> > I rest my case, though I will continue to provide rebuttal evidence
> > and testimony at need.
>
> Suit yourself. We'll be waiting for you to get up to speed on CL.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.
> Remember - and I am not apologizing for sounding patronizing; I am
> patronizing
How nasty of you.
> I know at least as much Java as you do
Assertion unsupported by evidence.
> and I know that many lispers are in the same situation.
Assertion unsupported by evidence. You don't know me. I might be the
world's foremost expert on Java for all you know, or I might just be
an average Java code jockey. You don't know which, and shouldn't
assume either.
> The opposite, with you and CL does not seem to be true.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.
Series Expansion wrote:
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, Marco.
That's because there are no rational arguments in favor of either Lisp
or Java. They both suck. Use Clojure, which combines the best of both
worlds. ;)
On May 29, 2:47 am, Lispy Loopy <········@spam.invalid> wrote:
> Series Expansion wrote:
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, Marco.
>
> That's because there are no rational arguments in favor of either Lisp
> or Java. They both suck. Use Clojure, which combines the best of both
> worlds. ;)
You're kidding.
(Even Google is apparently in on the joke: the captcha it gave me to
post this was "scala"!)
On May 17, 5:33 pm, "eric-and-jane-smith" <·······@nospam.com> wrote:
> Series Expansion <·······@gmail.com> wrote in news:2d76760f-0b00-4590-
> ·················@x6g2000vbg.googlegroups.com:
>
> > Please understand that in the real world of software development, the
> > lone programmer doing an entire job by himself is no longer at all
> > commonplace.
>
> What's an entire job? If the Lisp programmer implements and maintains
> the DSL's for a big project, and 1000 other programmers use those DSL's
> as the foundation of that project, do you consider the DSL's an entire
> job?
If the DSL is essentially a separate library, yes. If it's not, no.
> When a huge team of programmers works so closely together that they
> interfere with each other, the result is usually not worth a tiny
> fraction of the cost. Is that the "commonplace" you're thinking of?
> That's the reality of a lot of big projects.
Language support for modularizing, encapsulation, and rapid location
of bugs can make a big difference. Also for documenting things and
encouraging readable code.
As a result you see a lot more successful large Java projects than you
do perl ones, in particular.
> They should be separated into specialized groups, and when the work of
> one group affects the work of another, it should make that work easier
> and more effective, and not interfere with it. That's one thing DSL's
> do.
In principle. In practice, the absence of much encapsulation in Lisp
is going to pose problems as everyone is tempted to, and able to,
tweak things just *slightly* to ease their own task of the moment, and
eventually the tweaks become divergent or incompatible in some way.
Series Expansion <·······@gmail.com> wrote in news:610b40f7-b8b1-44fe-ac7f-
············@f16g2000vbf.googlegroups.com:
> In principle. In practice, the absence of much encapsulation in Lisp
> is going to pose problems as everyone is tempted to, and able to,
You agree in principle, but argue about practice, without any actual
practice to support such arguments. And even agreeing in principle, you
don't understand what you're agreeing with. What exactly did you think I
meant by "DSL"?
In any case, CL has far better encapsulation than any other programming
language I've ever used. And I've used a lot of them. Your "absence of
much encapsulation in Lisp" is absurd.
On May 21, 7:30 am, "eric-and-jane-smith" <·······@nospam.com> wrote:
> Series Expansion <·······@gmail.com> wrote in news:610b40f7-b8b1-44fe-ac7f-
> ············@f16g2000vbf.googlegroups.com:
>
> > In principle. In practice, the absence of much encapsulation in Lisp
> > is going to pose problems as everyone is tempted to, and able to,
>
> You agree in principle, but argue about practice, without any actual
> practice to support such arguments.
Perhaps not in Common Lisp development projects, but you assume I have
no experience with large scale development efforts at all, without
evidence that this is so. What I said about chaos resulting from lack
of encapsulation and temptation was in no way specific to Lisp.
> And even agreeing in principle, you don't understand what you're agreeing
> with. What exactly did you think I meant by "DSL"?
Domain-specific language, though it does not seem to be relevant to
the matter under debate, to whit, what happens in large programming
teams when encapsulation is absent or weak.
> In any case, CL has far better encapsulation than any other programming
> language I've ever used. And I've used a lot of them.
This statement is contradicted by your own prior testimony and other
available evidence. Anyone can get at any symbol from anywhere in the
code base, even supposedly "private" (non-exported) ones. Classes
don't encapsulate their data together with their behavior. Macros
don't encapsulate their own output from their call sites, unlike
normal function bodies. Need I go on?
> Your "absence of much encapsulation in Lisp" is absurd.
Your tiresome personal attacks do not constitute rational arguments in
favor of either Lisp or Java.
On May 16, 1:53 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 12:18 am, Adlai <·········@gmail.com> wrote:
[...]
> > Unless you're writing wizard macro-defining macros[1], debugging macro
> > code is fairly straightforward
> OH RLY?
RLY. I've done it, and I'm assuming Spiros has too.
It's strange to be told, repeatedly, that things I do routinely,
without a great deal of difficulty or aggravation, are in fact
ridiculously hard and painful. I mean, it's the kind of thing that'll
give a guy a swollen head....
Cheers,
Pillsy
[...]
On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
> On May 16, 1:53 am, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 12:18 am, Adlai <·········@gmail.com> wrote:
> [...]
> > > Unless you're writing wizard macro-defining macros[1], debugging macro
> > > code is fairly straightforward
> > OH RLY?
>
> RLY. I've done it, and I'm assuming Spiros has too.
>
> It's strange to be told, repeatedly, that things I do routinely,
> without a great deal of difficulty or aggravation, are in fact
> ridiculously hard and painful.
Real debugging or some sort of cargo-cult debugging, going through the
motions and having faith that it will have the intended effect?
(During the war years, aboriginals who saw cargo planes landing and
taking off at temporary military airfields sometimes created their own
runway-like features and cardboard planes, hoping this would attract
real planes with valuable goods to sometimes land there. Of course,
this was a lot less effort than developing their technology and
economy and operating a real airport!)
On May 16, 4:19 pm, Series Expansion <·······@gmail.com> wrote:
> On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
[...]
> > It's strange to be told, repeatedly, that things I do routinely,
> > without a great deal of difficulty or aggravation, are in fact
> > ridiculously hard and painful.
> Real debugging or some sort of cargo-cult debugging, going through the
> motions and having faith that it will have the intended effect?
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.
Cheers,
Pillsy
[...]
On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
> On May 16, 4:19 pm, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
> [...]
> > > It's strange to be told, repeatedly, that things I do routinely,
> > > without a great deal of difficulty or aggravation, are in fact
> > > ridiculously hard and painful.
> > Real debugging or some sort of cargo-cult debugging, going through the
> > motions and having faith that it will have the intended effect?
>
> 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.
On May 17, 1:30 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
[...]
> > 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.
How the heck can you "explain" something you quite clearly know
nothing about?
Cheers,
Pillsy
Pillsy wrote:
> On May 17, 1:30 am, Series Expansion <·······@gmail.com> wrote:
>> On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
> [...]
>>> 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.
>
> How the heck can you "explain" something you quite clearly know
> nothing about?
Please don't feed the troll.
--
Lew
On May 17, 12:33 pm, Lew <·····@lewscanon.com> wrote:
> Pillsy wrote:
> > On May 17, 1:30 am, Series Expansion <·······@gmail.com> wrote:
> >> 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?
>
> Please don't feed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Pillsy.
On May 17, 12:33 pm, Lew <·····@lewscanon.com> wrote:
> Pillsy wrote:
> > On May 17, 1:30 am, Series Expansion <·······@gmail.com> wrote:
> >> On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
> >>> 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.
>
> > How the heck can you "explain" something you quite clearly know
> > nothing about?
>
> Please don't feed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Pillsy.
I clearly know a great deal about macros and functions in general,
certainly enough to know of the encapsulation difference and to
explain it here.
(Reposted after original was silently redirected to hide my response
from comp.lang.java.programmer. "Lew", your perfidy knows no bounds.)
On May 17, 1:44 am, Pillsy <·········@gmail.com> wrote:
> On May 17, 1:30 am, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
> [...]
> > > 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.
>
> 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.
On May 17, 7:30 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
>
> > On May 16, 4:19 pm, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
> > [...]
> > > > It's strange to be told, repeatedly, that things I do routinely,
> > > > without a great deal of difficulty or aggravation, are in fact
> > > > ridiculously hard and painful.
> > > Real debugging or some sort of cargo-cult debugging, going through the
> > > motions and having faith that it will have the intended effect?
>
> > 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.
I don't understand this.... Would you care to explain? Debugging
macros implies debugging an AST rewriting process (something you do
not have at hand with the C preprocessor). In what way you are
"breaking the 'natural encapsulation' barrier"?
Cheers
--
Marco
On May 17, 4:20 am, Marco Antoniotti <·······@gmail.com> wrote:
> On May 17, 7:30 am, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
>
> > > On May 16, 4:19 pm, Series Expansion <·······@gmail.com> wrote:
>
> > > > On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
> > > [...]
> > > > > It's strange to be told, repeatedly, that things I do routinely,
> > > > > without a great deal of difficulty or aggravation, are in fact
> > > > > ridiculously hard and painful.
> > > > Real debugging or some sort of cargo-cult debugging, going through the
> > > > motions and having faith that it will have the intended effect?
>
> > > 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.
>
> I don't understand this.... Would you care to explain? Debugging
> macros implies debugging an AST rewriting process (something you do
> not have at hand with the C preprocessor). In what way you are
> "breaking the 'natural encapsulation' barrier"?
The behavior of function calls depends sensitively on the semantics of
the function's code, but not on its detailed implementation. One
example I'd previously used was that a function can be reimplemented
to change x + x to 2*x without altering its behavior, save possibly
for its speed of execution.
However, the same change in a macro, where x is one of its formal
parameters, causes a change in the semantics at any call site where
the corresponding actual parameter is an expression with side effects.
Furthermore, changing the names of local variables in a function, in
such a manner that the semantics of the function are unaltered, has no
effect whatsoever on its behavior when called (except for speed of
execution in the case of the most simple-minded and primitive
interpreters, where the longer the name the slower it runs). For
example, changing a variable named "foo" to "bar" throughout a
function that does not contain or use from an enclosing scope any pre-
existing variable named "bar".
The same change in a macro will cause changes in its behavior at call
sites with a pre-existing variable named "foo" or "bar" (un-capturing
the one and capturing the other). If the variable is declared inside a
nested scope, such as a { } pair in C, then the effects are subtler:
changes only occur at call sites that have such a pre-existing
variable *and use it in one of the expressions that is an argument to
the macro*. This time the effects result from the variable in the
nested scope hiding/unhiding the variable existing at the call site;
the hiding of this variable has no ill effects unless it is accessed
within the nested scope, which will only happen if it's used in one of
the macro's argument expressions.
This is what I mean by a broken encapsulation barrier: function call
sites are insulated from being affected by certain changes within
function bodies, and furthermore macro call sites are not insulated
from corresponding changes within macro bodies.
It is analogous to, though not identical with, the encapsulation
barrier familiar from OO theory, where changing implementation details
of a well-written class that don't change the semantics of its public
methods will not break code anywhere else in the project.
Unfortunately, it is quite evident that changing implementation
details of a macro, even a well-written one, will always have the
potential to break code elsewhere in the project.
On May 18, 9:35 am, Series Expansion <·······@gmail.com> wrote:
> On May 17, 4:20 am, Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
> > On May 17, 7:30 am, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
>
> > > > On May 16, 4:19 pm, Series Expansion <·······@gmail.com> wrote:
>
> > > > > On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
> > > > [...]
> > > > > > It's strange to be told, repeatedly, that things I do routinely,
> > > > > > without a great deal of difficulty or aggravation, are in fact
> > > > > > ridiculously hard and painful.
> > > > > Real debugging or some sort of cargo-cult debugging, going through the
> > > > > motions and having faith that it will have the intended effect?
>
> > > > 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.
>
> > I don't understand this.... Would you care to explain? Debugging
> > macros implies debugging an AST rewriting process (something you do
> > not have at hand with the C preprocessor). In what way you are
> > "breaking the 'natural encapsulation' barrier"?
>
> The behavior of function calls depends sensitively on the semantics of
> the function's code, but not on its detailed implementation. One
> example I'd previously used was that a function can be reimplemented
> to change x + x to 2*x without altering its behavior, save possibly
> for its speed of execution.
>
> However, the same change in a macro, where x is one of its formal
> parameters, causes a change in the semantics at any call site where
> the corresponding actual parameter is an expression with side effects.
>
> Furthermore, changing the names of local variables in a function, in
> such a manner that the semantics of the function are unaltered, has no
> effect whatsoever on its behavior when called (except for speed of
> execution in the case of the most simple-minded and primitive
> interpreters, where the longer the name the slower it runs). For
> example, changing a variable named "foo" to "bar" throughout a
> function that does not contain or use from an enclosing scope any pre-
> existing variable named "bar".
>
> The same change in a macro will cause changes in its behavior at call
> sites with a pre-existing variable named "foo" or "bar" (un-capturing
> the one and capturing the other). If the variable is declared inside a
> nested scope, such as a { } pair in C, then the effects are subtler:
> changes only occur at call sites that have such a pre-existing
> variable *and use it in one of the expressions that is an argument to
> the macro*. This time the effects result from the variable in the
> nested scope hiding/unhiding the variable existing at the call site;
> the hiding of this variable has no ill effects unless it is accessed
> within the nested scope, which will only happen if it's used in one of
> the macro's argument expressions.
>
> This is what I mean by a broken encapsulation barrier: function call
> sites are insulated from being affected by certain changes within
> function bodies, and furthermore macro call sites are not insulated
> from corresponding changes within macro bodies.
>
> It is analogous to, though not identical with, the encapsulation
> barrier familiar from OO theory, where changing implementation details
> of a well-written class that don't change the semantics of its public
> methods will not break code anywhere else in the project.
> Unfortunately, it is quite evident that changing implementation
> details of a macro, even a well-written one, will always have the
> potential to break code elsewhere in the project.
You don't have any clue about Common Lisp macros and compiler macros,
Scheme hygienic macros etc etc. Do you?
Having said that, I shut up.... :)
Cheers
--
Marco
On May 18, 4:06 am, Marco Antoniotti <·······@gmail.com> wrote:
> On May 18, 9:35 am, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 17, 4:20 am, Marco Antoniotti <·······@gmail.com> wrote:
>
> > > On May 17, 7:30 am, Series Expansion <·······@gmail.com> wrote:
>
> > > > On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
>
> > > > > On May 16, 4:19 pm, Series Expansion <·······@gmail.com> wrote:
>
> > > > > > On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
> > > > > [...]
> > > > > > > It's strange to be told, repeatedly, that things I do routinely,
> > > > > > > without a great deal of difficulty or aggravation, are in fact
> > > > > > > ridiculously hard and painful.
> > > > > > Real debugging or some sort of cargo-cult debugging, going through the
> > > > > > motions and having faith that it will have the intended effect?
>
> > > > > 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.
>
> > > I don't understand this.... Would you care to explain? Debugging
> > > macros implies debugging an AST rewriting process (something you do
> > > not have at hand with the C preprocessor). In what way you are
> > > "breaking the 'natural encapsulation' barrier"?
>
> > The behavior of function calls depends sensitively on the semantics of
> > the function's code, but not on its detailed implementation. One
> > example I'd previously used was that a function can be reimplemented
> > to change x + x to 2*x without altering its behavior, save possibly
> > for its speed of execution.
>
> > However, the same change in a macro, where x is one of its formal
> > parameters, causes a change in the semantics at any call site where
> > the corresponding actual parameter is an expression with side effects.
>
> > Furthermore, changing the names of local variables in a function, in
> > such a manner that the semantics of the function are unaltered, has no
> > effect whatsoever on its behavior when called (except for speed of
> > execution in the case of the most simple-minded and primitive
> > interpreters, where the longer the name the slower it runs). For
> > example, changing a variable named "foo" to "bar" throughout a
> > function that does not contain or use from an enclosing scope any pre-
> > existing variable named "bar".
>
> > The same change in a macro will cause changes in its behavior at call
> > sites with a pre-existing variable named "foo" or "bar" (un-capturing
> > the one and capturing the other). If the variable is declared inside a
> > nested scope, such as a { } pair in C, then the effects are subtler:
> > changes only occur at call sites that have such a pre-existing
> > variable *and use it in one of the expressions that is an argument to
> > the macro*. This time the effects result from the variable in the
> > nested scope hiding/unhiding the variable existing at the call site;
> > the hiding of this variable has no ill effects unless it is accessed
> > within the nested scope, which will only happen if it's used in one of
> > the macro's argument expressions.
>
> > This is what I mean by a broken encapsulation barrier: function call
> > sites are insulated from being affected by certain changes within
> > function bodies, and furthermore macro call sites are not insulated
> > from corresponding changes within macro bodies.
>
> > It is analogous to, though not identical with, the encapsulation
> > barrier familiar from OO theory, where changing implementation details
> > of a well-written class that don't change the semantics of its public
> > methods will not break code anywhere else in the project.
> > Unfortunately, it is quite evident that changing implementation
> > details of a macro, even a well-written one, will always have the
> > potential to break code elsewhere in the project.
>
> You don't have any clue about Common Lisp macros and compiler macros,
> Scheme hygienic macros etc etc. Do you?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.
Paul Foley (http://public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
>>> On May 16, 4:19 pm, Series Expansion <·······@gmail.com> wrote:
>>>
>>>
>>>
>>>> On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
>>> [...]
>>>>> It's strange to be told, repeatedly, that things I do routinely,
>>>>> without a great deal of difficulty or aggravation, are in fact
>>>>> ridiculously hard and painful.
>>>> Real debugging or some sort of cargo-cult debugging, going through the
>>>> motions and having faith that it will have the intended effect?
>>> 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.
>
> You're talking nonsense. Lisp macros /are/ functions!
Please don't feed the troll.
--
Lew
On May 17, 12:33 pm, Lew <·····@lewscanon.com> wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> Except that macros lack the natural encapsulation barrier that
> >> surrounds functions, as explained elsethread. With all the
> >> consequences for debugging straightforwardness that that implies.
>
> > You're talking nonsense.
>
> Please don't feed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Paul.
On May 17, 12:33 pm, Lew <·····@lewscanon.com> wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> Except that macros lack the natural encapsulation barrier that
> >> surrounds functions, as explained elsethread. With all the
> >> consequences for debugging straightforwardness that that implies.
>
> > You're talking nonsense. Lisp macros /are/ functions!
>
> Please don't feed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Paul.
(Reposted after original was silently redirected to hide my response
from comp.lang.java.programmer. "Lew", your perfidy knows no bounds.)
On May 17, 9:19 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 16, 4:27 pm, Pillsy <·········@gmail.com> wrote:
> >> On May 16, 4:19 pm, Series Expansion <·······@gmail.com> wrote:
>
> >> > On May 16, 2:13 am, Pillsy <·········@gmail.com> wrote:
> >> [...]
> >> > > It's strange to be told, repeatedly, that things I do routinely,
> >> > > without a great deal of difficulty or aggravation, are in fact
> >> > > ridiculously hard and painful.
> >> > Real debugging or some sort of cargo-cult debugging, going through the
> >> > motions and having faith that it will have the intended effect?
>
> >> 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.
>
> You're talking nonsense.
Actually, you are; personal attacks like this do not constitute
logical arguments in support of your position.
> Lisp macros /are/ functions!
They're sort of both. The function you refer to evaluates some code
into other code, which is then substituted at the call site.
The substitution at the call site, and substitution of the arguments
for the formal parameters, are the defining features of a macro, and
simultaneously are the cause of the variable-hiding, variable-capture,
and multiple-evaluation issues. All of those issues arise
automatically with macros and none of them arise with normal
functions.
So what I said about a kind of encapsulation barrier present with
normal functions and lacking with macros remains unassailed. Changes
to the innards of functions, such as renaming a local variable or
rearranging the exact way it computes something, can be made that
don't affect its computational semantics, and such changes can be made
safely without breaking things at the function's call sites. Similarly
semantically-null changes to macros can, however, break things at call
sites.
This is explained in more detail in some of my earlier posts. You have
not refuted it either by calling me names or by saying that Lisp
macros are functions.
> The only difference between a "macro" and an ordinary
> "function" is that macro-functions get executed at compile time.
And the results lexically substituted for the call. This last, which
you left out, is the most crucial point of difference.
Series Expansion wrote:
> On May 16, 12:18 am, Adlai <·········@gmail.com> wrote:
>> The beautiful thing about macros is that it's not "machine-generated
>> code".
>
> You mean, the Lisp machine actually contains little elves that write
> the expanded code? I thought that was just a myth!
ROTFL!!
Series Expansion <·······@gmail.com> writes:
> MY point, which remains unaddressed, is that there are three ways to
> deal with a commonly-desired support method:
>
> 1. The vendor puts it in the system class. No problemo.
> 2. Everyone rolls their own. Ugh.
> 3. A third party library puts it in the system class.
> Whereas the vendor would create an automatic standard,
> absent this, most likely multiple third party libraries
> would develop to do the job, and would each do it a bit
> differently. Code using one and code using another one
> could not typically be combined without problems.
It has already been addressed. There are other ways. We pointed out
that CLOS doesn't work like that.
- in CLOS, methods are not put in a class.
- in CLOS, you can add methods dispatching on your own classes to any
generic function.
- in CLOS, you can redefine methods at will, but you're a big boy and
expected to know what you're doing. So if you want to replace a
method defined in a library, you always can do so, for the better
good of your program.
Beyond that, I won't give you a CLOS lecture here, just go learn
Common Lisp, if you want to stop behaving like a fool.
--
__Pascal Bourguignon__
···@zedat.fu-berlin.de (Stefan Ram) writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>- in CLOS, you can redefine methods at will, but you're a big boy and
>>expected to know what you're doing. So if you want to replace a
>>method defined in a library, you always can do so, for the better
>>good of your program.
>
> In production environments, this might have security implications.
>
> For example, it allows to inject one's code into clients of those
> libraries.
In production environments, with any language, you can modify the
source recompile and have security implications.
Why are you objecting things that are irrelevant to the language?
But if you're particularly concerned with security problems at the
source level, you may be happy to learn that being a meta programming
language, lisp and its macros allow you to define your own domain
specific language with security in mind, and therefore easily have all
your programmers follow automatically the security rules, by using that
DSL instead of bare Lisp by writing:
(defpackage "MY-PROGRAM" (:use "SECURE-LISP"))
instead of:
(defpackage "MY-PROGRAM" (:use "CL"))
--
__Pascal Bourguignon__
···@zedat.fu-berlin.de (Stefan Ram) writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>>In production environments, this might have security implications.
>>>For example, it allows to inject one's code into clients of those
>>>libraries.
>>In production environments, with any language, you can modify the
>>source recompile and have security implications.
>
> Java allows »Applets« to be executed within a Web Browser.
> These programs have limited rights.
I'm certainly not saying you're wrong, but Java applets are a special
situation. Common Lisp (and most programming languages, so don't nobody
interpret this as a failing of Lisp) isn't used in the way Flash is, and
Java used to be. Special security considerations do apply to them, that
don't apply to normal desktop or server programs. It's silly to worry
about someone who is authorized to run arbitrary code on your machine
finding a more convoluted way to run arbitrary code on your machine.
On May 16, 10:05 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > MY point, which remains unaddressed, is that there are three ways to
> > deal with a commonly-desired support method:
>
> > 1. The vendor puts it in the system class. No problemo.
> > 2. Everyone rolls their own. Ugh.
> > 3. A third party library puts it in the system class.
> > Whereas the vendor would create an automatic standard,
> > absent this, most likely multiple third party libraries
> > would develop to do the job, and would each do it a bit
> > differently. Code using one and code using another one
> > could not typically be combined without problems.
>
> It has already been addressed.
In what quantum universe? Is the grass greener there than it is here,
too? :)
> There are other ways. We pointed out
> that CLOS doesn't work like that.
Replace "class" with "generic function" then:
1. The vendor puts it in the system generic function. No
problemo.
2. Everyone rolls their own. Ugh.
3. A third party library puts it in the system generic
function. Whereas the vendor would create an automatic
standard, absent this, most likely multiple third party
libraries would develop to do the job, and would each
do it a bit differently. Code using one and code using
another one could not typically be combined without
problems.
> - in CLOS, you can add methods dispatching on your own classes to any
> generic function.
Worse, sometimes you have to, even with generic functions from someone
else's namespace, even ones in the system package(s).
CLOS, and Lisp itself, seem designed for the "lone hacker in his
garage" model of software development. Very little modern software is
actually developed that way.
> - in CLOS, you can redefine methods at will, but you're a big boy and
> expected to know what you're doing. So if you want to replace a
> method defined in a library, you always can do so, for the better
> good of your program.
And then watch your coworkers tearing out tufts of hair, screaming,
sobbing, throwing office furniture around, and going prematurely gray.
If I were of a sadistic bent, I might like that idea.
As things stand ...
Well, I think my opinion has become quite clear.
> Beyond that, I won't give you a CLOS lecture here, just go learn
> Common Lisp, if you want to stop behaving like a fool.
And here I thought we might be settling into some semblance of a
rational discussion of the relative merits. Then you whip out this
totally gratuitous insult and sling it in a public forum. Shame on you!
Series Expansion <·······@gmail.com> writes:
> On May 16, 10:05�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > MY point, which remains unaddressed, is that there are three ways to
>> > deal with a commonly-desired support method:
>>
>> > 1. The vendor puts it in the system class. No problemo.
>> > 2. Everyone rolls their own. Ugh.
>> > 3. A third party library puts it in the system class.
>> > � �Whereas the vendor would create an automatic standard,
>> > � �absent this, most likely multiple third party libraries
>> > � �would develop to do the job, and would each do it a bit
>> > � �differently. Code using one and code using another one
>> > � �could not typically be combined without problems.
>>
>> It has already been addressed.
>
> In what quantum universe? Is the grass greener there than it is here,
> too? :)
>
>> There are other ways. �We pointed out
>> that CLOS doesn't work like that.
>
> Replace "class" with "generic function" then:
>
> 1. The vendor puts it in the system generic function. No
> problemo.
> 2. Everyone rolls their own. Ugh.
> 3. A third party library puts it in the system generic
> function. Whereas the vendor would create an automatic
> standard, absent this, most likely multiple third party
> libraries would develop to do the job, and would each
> do it a bit differently. Code using one and code using
> another one could not typically be combined without
> problems.
The language forbids to define methods of standard generic functions
on standard classes. In the same way that Java forbids you to add or
modify anything in java.lang.*
However this is not a big problem.
First there's only 40 standard generic functions, most of them are
hooks for other CL functionarity, that shouldn't be called by the
user, but designed so the user may put methods on for its own classes:
there would be no point to add a method for a standard class, because
the implementation may even not call the generic function with a
standard class instance in the first place, only for user classes.
Next if it's the name of the generic-function you're interested in,
you can always shadow it it and use your own symbol of same name in
your own package:
(defpackage "MY-PROGRAM"
(:use "CL")
(:shadow "PRINT-OBJECT"))
(in-package "MY-PROGRAM")
(defgeneric print-object (obj str))
(defmethod print-object ((a integer) (b stream))
(print `(this is an integer of value ,a) b))
so now when you write:
(print-object 42 *standard-output*)
you will get:
(THIS IS AN INTEGER OF VALUE 42)
printed.
>> - in CLOS, you can add methods dispatching on your own classes to any
>> � generic function.
>
> Worse, sometimes you have to, even with generic functions from someone
> else's namespace, even ones in the system package(s).
>
> CLOS, and Lisp itself, seem designed for the "lone hacker in his
> garage" model of software development. Very little modern software is
> actually developed that way.
But at least, with Lisp you can indeed develop big software with less
developers, smaller teams than with other programming languages.
>> - in CLOS, you can redefine methods at will, but you're a big boy and
>> � expected to know what you're doing. �So if you want to replace a
>> � method defined in a library, you always can do so, for the better
>> � good of your program.
>
> And then watch your coworkers tearing out tufts of hair, screaming,
> sobbing, throwing office furniture around, and going prematurely gray.
Therefore you don't.
> If I were of a sadistic bent, I might like that idea.
>
> As things stand ...
>
> Well, I think my opinion has become quite clear.
Lisp language designers don't think lisp programmers are dumb.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Series Expansion <·······@gmail.com> writes:
>> Well, I think my opinion has become quite clear.
>
> Lisp language designers don't think lisp programmers are dumb.
Please don't feed the troll.
--
Lew
On May 17, 12:34 pm, Lew <·····@lewscanon.com> wrote:
> Pascal J. Bourguignon wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> Well, I think my opinion has become quite clear.
>
> > Lisp language designers don't think lisp programmers are dumb.
>
> Please don't feed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Pascal.
On May 17, 12:34 pm, Lew <·····@lewscanon.com> wrote:
> Pascal J. Bourguignon wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> Well, I think my opinion has become quite clear.
>
> > Lisp language designers don't think lisp programmers are dumb.
>
> Please don't feed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Pascal.
I did not claim to think Lisp programmers were dumb. The opinion
referred to was regarding the safety of Lisp macros, or rather the
lack thereof.
(Reposted after original was silently redirected to hide my response
from comp.lang.java.programmer. "Lew", your perfidy knows no bounds.)
On May 17, 8:30 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > 1. The vendor puts it in the system generic function. No
> > problemo.
> > 2. Everyone rolls their own. Ugh.
> > 3. A third party library puts it in the system generic
> > function. Whereas the vendor would create an automatic
> > standard, absent this, most likely multiple third party
> > libraries would develop to do the job, and would each
> > do it a bit differently. Code using one and code using
> > another one could not typically be combined without
> > problems.
>
> The language forbids to define methods of standard generic functions
> on standard classes.
That does not remove the problem, only reduce it somewhat. Replace
system classes and generic functions with ones from a popular third
party library, for which further add-on libraries get developed, and
we're back to square 1.
Your statement does perplex in another way: it seems to be impossible,
given that the object system under discussion is itself a library and
not an integral part of Lisp itself. That is, whereas the syntax,
semantics, and interpretation of Java source and JVM bytecode is shot
through with class, object, method, and the like, the syntax,
semantics, and interpretation of List source and Lisp bytecode is shot
through with cons cells and very little else. This seems to preclude
the compiler or interpreter from making any assumptions about object
systems or any other structures that users might implement on top of
the bare bones of the language, where there are many possible
implementations. Even if one has become standardized upon.
Of course, tools external to the language core itself could exist that
"lint" CLOS code or similarly for certain kinds of CLOS no-nos;
perhaps you mean that one of these will complain about such code, and
thereby prevent problems developing quietly from additions to standard
generic functions?
> Next if it's the name of the generic-function you're interested in,
> you can always shadow it it and use your own symbol of same name
Variable and method hiding is a fruitful source of headaches, in my
experience.
> >> - in CLOS, you can add methods dispatching on your own classes to any
> >> generic function.
>
> > Worse, sometimes you have to, even with generic functions from someone
> > else's namespace, even ones in the system package(s).
>
> > CLOS, and Lisp itself, seem designed for the "lone hacker in his
> > garage" model of software development. Very little modern software is
> > actually developed that way.
>
> But at least, with Lisp you can indeed develop big software with less
> developers, smaller teams than with other programming languages.
If true, that is a mitigating factor, but of unknown and probably
small magnitude.
> >> - in CLOS, you can redefine methods at will, but you're a big boy and
> >> expected to know what you're doing. So if you want to replace a
> >> method defined in a library, you always can do so, for the better
> >> good of your program.
>
> > And then watch your coworkers tearing out tufts of hair, screaming,
> > sobbing, throwing office furniture around, and going prematurely gray.
>
> Therefore you don't.
Don't get me wrong. You can do some pretty evil things in Java, too.
(It lacks goto but allows global variables. Lots of fun to be had
calling polymorphic methods from constructors of non-final classes,
writing static initializers with side-effects, and things like that.)
Unfortunately, it sounds like to do many of the more powerful things
in Lisp, you are forced to do evil things, from mildly tainted
(modifying generic functions outside your fiefdom) to unavoidably
hazardous (using macros) and degrees in-between.
> > Well, I think my opinion has become quite clear.
>
> Lisp language designers don't think lisp programmers are dumb.
Unfortunately, the smartest programmer in the world cannot make a
macro that uses an argument multiple times and simultaneously avoids
all four of: multiple evaluation of that argument, variable capture,
variable hiding, and use of a global variable. In any language,
regardless of details of the macro implementation. He might as well
try to write an algorithm that answers the halting problem for any
input program. It is simply not logically possible for him to succeed.
On May 18, 10:45 am, Series Expansion <·······@gmail.com> wrote:
> Unfortunately, the smartest programmer in the world cannot make a
> macro that uses an argument multiple times and simultaneously avoids
> all four of: multiple evaluation of that argument, variable capture,
> variable hiding, and use of a global variable. In any language,
> regardless of details of the macro implementation. He might as well
> try to write an algorithm that answers the halting problem for any
> input program. It is simply not logically possible for him to succeed.
Really? Watch this:
(defmacro logically-impossible-macro (arg)
(let ((generated-variable (gensym)))
`(let ((,generated-variable ,arg))
(list "Using generated symbol: " ',generated-variable
"Multiple Evaluation?" (not (eql ,generated-
variable ,generated-variable))
"Global variable?" (boundp ',generated-variable)
"Variable hiding?" (setq ,generated-variable 42)))))
---- example usage ---
CL-USER 2 > (defvar generated-variable 0)
GENERATED-VARIABLE
CL-USER 3 > generated-variable
0
CL-USER 4 > (LOGICALLY-IMPOSSIBLE-MACRO (incf generated-variable))
("Using generated symbol: " #:G807 "Multiple Evaluation?" NIL "Global
variable?" NIL "Variable hiding?" 42)
CL-USER 5 > generated-variable
1
---------------
incf is like ++ in Java. Defvar defines and initializes a global
variable.
I have purposedly used the name "generated-variable" for my global
variable, without using the naming convention of *global-variable-
name*, to show how NO variable hiding happens: although I set the
value of generated-variable to 42 in the macro, the global variable
was not modified. The trick is using a freshly-generated symbol
guaranteed to be unique, a so-called gensym (the symbol named #:G807
in my example), for the temporary variable's name. Do you understand
now?
Alessio
Alessio Stalla wrote:
> On May 18, 10:45 am, Series Expansion <·······@gmail.com> wrote:
>> Unfortunately, the smartest programmer in the world cannot make a
>> macro that uses an argument multiple times and simultaneously avoids
>> all four of: multiple evaluation of that argument, variable capture,
>> variable hiding, and use of a global variable. In any language,
>> regardless of details of the macro implementation. He might as well
>> try to write an algorithm that answers the halting problem for any
>> input program. It is simply not logically possible for him to succeed.
>
> Really? Watch this:
[Lisp example elided] ...
Lisp is not Java.
--
Lew
On May 18, 6:06 am, Alessio Stalla <·············@gmail.com> wrote:
> On May 18, 10:45 am, Series Expansion <·······@gmail.com> wrote:
>
> > Unfortunately, the smartest programmer in the world cannot make a
> > macro that uses an argument multiple times and simultaneously avoids
> > all four of: multiple evaluation of that argument, variable capture,
> > variable hiding, and use of a global variable. In any language,
> > regardless of details of the macro implementation. He might as well
> > try to write an algorithm that answers the halting problem for any
> > input program. It is simply not logically possible for him to succeed.
>
> Really?
Yes, really, as explained previously. No clever attempt at a
workaround will fail to contain some subtle flaw, if not an overt one.
> I have purposedly used the name "generated-variable" for my global
> variable, without using the naming convention of *global-variable-
> name*
Use of global variables, of course, is the flaw in this instance. And
not a subtle one.
On May 20, 7:28 pm, Series Expansion <·······@gmail.com> wrote:
> On May 18, 6:06 am, Alessio Stalla <·············@gmail.com> wrote:
>
> > On May 18, 10:45 am, Series Expansion <·······@gmail.com> wrote:
>
> > > Unfortunately, the smartest programmer in the world cannot make a
> > > macro that uses an argument multiple times and simultaneously avoids
> > > all four of: multiple evaluation of that argument, variable capture,
> > > variable hiding, and use of a global variable. In any language,
> > > regardless of details of the macro implementation. He might as well
> > > try to write an algorithm that answers the halting problem for any
> > > input program. It is simply not logically possible for him to succeed.
>
> > Really?
>
> Yes, really, as explained previously. No clever attempt at a
> workaround will fail to contain some subtle flaw, if not an overt one.
>
> > I have purposedly used the name "generated-variable" for my global
> > variable, without using the naming convention of *global-variable-
> > name*
>
> Use of global variables, of course, is the flaw in this instance. And
> not a subtle one.
*sigh* I purposedly declared a global variable to show how my macro
DOES NOT use global variables! It's the user-supplied code - "(incf
generated-variable)" - that accesses and modifies the global variable.
The macro does not interfere at all with this!
In fact, part of the output of the macro is
"Global variable?" NIL
NIL means false. The macro is checking whether the temporary variable
it introduces is globally bound, and finds it isn't - it cannot be,
since its name is guaranteed to be unique! If you don't believe it,
this is the same macro without any global variables:
* (LOGICALLY-IMPOSSIBLE-MACRO (print 3))
3
("Using generated symbol: " #:G622 "Multiple Evaluation?" NIL
"Global variable?" NIL "Variable hiding?" 42)
As you see, user code is evaluated only once - the 3 is printed once -
no global variables are used, no variable capture can occur since the
*local* variable introduced by the macro - #:G622 in this case - is
guaranteed not to clash with any other variable. Yes, it uses a trick,
generating a unique symbol, which is probably only used in Lisp and
not widely known elsewhere, since Lisp is the only language I know of
where symbols are first-class objects. Well, there's Prolog too IIRC,
but I don't think Prolog has macros ;). Is it clear now?
Alessio
On May 20, 3:23 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 20, 7:28 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 18, 6:06 am, Alessio Stalla <·············@gmail.com> wrote:
> > > I have purposedly used the name "generated-variable" for my global
> > > variable, without using the naming convention of *global-variable-
> > > name*
>
> > Use of global variables, of course, is the flaw in this instance. And
> > not a subtle one.
>
> *sigh* I purposedly declared a global variable to show how my macro
> DOES NOT use global variables!
That statement is not logical.
> In fact, part of the output of the macro is
>
> "Global variable?" NIL
>
> NIL means false.
That the global variable's boolean value is false seems irrelevant.
> The macro is checking whether the temporary variable
> it introduces is globally bound, and finds it isn't - it cannot be,
> since its name is guaranteed to be unique!
A macro can compute only a function of its arguments. To guarantee the
name be unique would require it to compute a function of the entire
codebase of the project that contains it. For a macro local to a
particular project, this would require the entire rest of the source
code to be contained in the macro's arguments. For a macro in a
library or other reusable module, this would entail granting the macro
powers of precognition.
> As you see, user code is evaluated only once - the 3 is printed once -
> no global variables are used, no variable capture can occur since the
> *local* variable introduced by the macro - #:G622 in this case - is
> guaranteed not to clash with any other variable.
As explained above, this guarantee is not possible to make. All that
is needed is to create a variable with the name #:G622 in the calling
scope and the same macro, given the same arguments, will cause
capture, since the variable name must be the result of the macro
computing some function of its arguments and since in the case of that
particular macro with those particular arguments the name thus
computed is #:G622.
It is not even possible to fix this by making the macro
nondeterministic or by giving it state that persists between
invocations. Without special hardware it cannot be made truly
nondeterministic. Pseudo-random number generation is the best that
could be managed, and devolves to case two, giving the macro
persistent state. But that, too, is impossible. Macros run at compile
time, and therefore have no ability to make use of run-time data
structures to maintain state. Indeed, you could engineer a collision
easily regardless, by compiling one source file using the macro in
question, noting the name the macro generated when it expanded, and
then authoring a new source file never before seen by man that used
the same name and put it into a scope visible at the call site, say,
the top level of the scope hierarchy. If this second file is then
compiled and the object code from the two compilations linked, the
collision occurs long after the macro had any opportunity to avoid it.
> Is it clear now?
As mud.
On May 23, 7:46 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> >> As you see, user code is evaluated only once - the 3 is printed once -
> >> no global variables are used, no variable capture can occur since the
> >> *local* variable introduced by the macro - #:G622 in this case - is
> >> guaranteed not to clash with any other variable.
>
> > As explained above, this guarantee is not possible to make. All that
> > is needed is to create a variable with the name #:G622 in the calling
> > scope and the same macro, given the same arguments, will cause
> > capture, since the variable name must be the result of the macro
> > computing some function of its arguments and since in the case of that
> > particular macro with those particular arguments the name thus
> > computed is #:G622.
>
> This is what you get for insisting that names are the same as the
> thing they name.
I have done nothing of the sort.
> #:G622 is not interned, so another occurrence of #:G622 is a
> completely different symbol that has the same name.
That has an equally useless consequence: if the macro generates an
assignment of an argument's evaluation to #:G622, followed by a
function call using #:G622 as a parameter, the function call won't
receive the result of the argument's evaluation because its parameter
was a different #:G622.
The only way around it is to maintain some kind of pointer to the
first #:G622, but then you need someplace to store that pointer and a
name for THAT. It's an infinite regress that cannot solve the problem
posed.
> If you create a variable with the name #:G622 in the
> calling scope, that will be an entirely different variable than the
> one in the macro, so there's no problem.
There's a different problem, rather than no problem. The macro output
itself won't be able to refer to the same #:G622 twice. Except by
using some non-#:-prepended name to refer, directly or indirectly, to
it, and then that name becomes the potential source of a collision.
> > could be managed, and devolves to case two, giving the macro
> > persistent state. But that, too, is impossible.
>
> Of course it isn't. Macros can alter variables (for state in the
> current image) and read and write files (for state that outlasts the
> image), just like any other function.
It was impossible within the constraints of solving the posed problem,
which included "no global variables".
Furthermore, macros cannot alter variables at run-time, and if they
can alter files on disk, this seems useless and dangerous. Perhaps you
meant the code that is output by the macro evaluation, and which later
is compiled and run as part of the program, rather than the macro's
own body? The code generated by the macro can obviously alter run-time
state and disk files, but for the macro's various expansion-instances
to maintain shared, persistent state in this manner would violate the
no-global-variables constraint.
> > Macros run at compile
> > time, and therefore have no ability to make use of run-time data
> > structures to maintain state. Indeed, you could engineer a collision
> > easily regardless, by compiling one source file using the macro in
> > question, noting the name the macro generated when it expanded, and
> > then authoring a new source file never before seen by man that used
> > the same name and put it into a scope visible at the call site, say,
> > the top level of the scope hierarchy. If this second file is then
> > compiled and the object code from the two compilations linked, the
> > collision occurs long after the macro had any opportunity to avoid it.
>
> Except that, you know, you can't get the name of that variable.
See above. If that were completely true, the variable would be
useless, since you could not both store into it and then subsequently
retrieve from it. So there must be a way to refer to it repeatedly,
but whatever that mechanism is, it will recreate the original problem
of variable capture, since the context of the macro invocation, or one
of the macro's own arguments, could contain, by chance, a construct
that likewise refers to it.
Put more simply, if the macro's expansion can only refer to something
once, then it cannot be useful for avoiding multiple evaluation. If,
on the other hand, the macro's expansion can refer to a thing
repeatedly, there must be some particular piece of code that, within
some lexical scope, has the effect of referring to that same thing at
each place in that scope where that piece of code occurs. It follows
that that same piece of code, appearing elsewhere in the call site's
context, can end up having that same effect there, outside of the
macro's expansion, and then capture has occurred. Furthermore,
although the macro can compute that piece of code in some more complex
way than by its being a fixed, literal string in the source code, it
can only compute functions of its arguments, and therefore cannot
determine a "safe" such piece of code in full generality since it
cannot know of usages outside the macro invocation's arguments but
inside the immediately-enclosing scope.
On May 24, 3:16 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> >> > could be managed, and devolves to case two, giving the macro
> >> > persistent state. But that, too, is impossible.
>
> >> Of course it isn't. Macros can alter variables (for state in the
> >> current image) and read and write files (for state that outlasts the
> >> image), just like any other function.
>
> > It was impossible within the constraints of solving the posed problem,
> > which included "no global variables".
>
> > Furthermore, macros cannot alter variables at run-time,
>
> Of course they can.
No, they cannot. The code into which a macro invocation expanded can
do so, but that is distinct from the macro itself, which is executed
at compile time.
> > and if they
> > can alter files on disk, this seems useless and dangerous.
>
> Just as useless and dangerous as any other function being able to
> alter files on disk.
We are discussing a function that executes at compile time -- not the
same thing.
> > Perhaps you
> > meant the code that is output by the macro evaluation, and which later
> > is compiled and run as part of the program, rather than the macro's
> > own body? The code generated by the macro can obviously alter run-time
> > state and disk files, but for the macro's various expansion-instances
> > to maintain shared, persistent state in this manner would violate the
> > no-global-variables constraint.
>
> What "no-global-variables constraint"? If you /want/ the macro to
> maintain shared, persistent state, a global variable is a perfectly
> good way to do it!
The problem is that it was your proposed scheme for avoiding all four
of multiple evaluation, variable capture, variable hiding, and global
variable use that that ended up involving, perhaps in disguise, global
variables.
> > Put more simply, if the macro's expansion can only refer to something
> > once, then it cannot be useful for avoiding multiple evaluation. If,
> > on the other hand, the macro's expansion can refer to a thing
> > repeatedly, there must be some particular piece of code that, within
> > some lexical scope, has the effect of referring to that same thing at
> > each place in that scope where that piece of code occurs. It follows
> > that that same piece of code, appearing elsewhere in the call site's
> > context, can end up having that same effect there, outside of the
>
> No, that doesn't follow at all.
Yes, it does.
> Lisp code is not text.
If that is true then a) it does not alter the above, where the term
"piece of code" is used agnostically as to how precisely it is
constructed -- it could be a machine-meaningful jpeg image and what I
said above would remain true -- and meanwhile b) you are in trouble on
a whole new front, as it becomes unsafe to manipulate Lisp code in
normal text editors and with tools like sed and awk, tools that are
commonplace in software developers' tool-kits. This was elaborated
upon in a prior post of mine.
Did you just write two different replies to the same post?
Series Expansion <·······@gmail.com> writes:
> On May 15, 5:50 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
>>
>> >> The CL package system will solve the name collision with no harm done.
>>
>> > I just explained why the package system won't. Adding new classes in
>> > their own packages? No problem, the package system can distinguish
>> > foo.String from bar.String. Adding new methods to an existing class,
>> > say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
>> > foo.String.doIt()?
>>
>> I guess that's one of the downsides of an inside-out object
>> system.
>
> Inside-out?
Placing methods inside of objects. It was clever in... 1767? But it's
time to move on. In CLOS, methods, functions, and objects use the same
package system, rather than all methods applicable to an object being
mistakenly associated with a particular class. They can do this because
methods aren't considered to be inside any object, and are therefore
free to be "top-level" entities in the package system.
>> > So, basically, you're saying that the way you avoid the name clash is
>> > to make baz's String.doIt() and quux's String.doIt() private. Of
>> > course, this now means that anyone who wants their own code to call a
>> > String.doIt() has to roll their own and can't get a canned one from a
>> > library. Because if they do, and there's multiple incompatible
>> > libraries that provide this, then we're back to square one and name
>> > clashes.
>>
>> No, he's saying that support methods that don't make up a library's API
>> won't be exported from packages
>
> Er, that's basically what I meant by "make them private". Duh.
You seemed to be thinking that other methods would be made private as
well.
> Everywhere the symbols were used there'd need to be some preamble code
> to "explicitly tell how the clashes should be handled".
Far from it! You might design a system that worked like that, but I
assure you that Lisp's designers would and did not.
It would only work remotely as you imagine if you continually used a set
of awkwardly named libraries together, so every time you started a new
project you had to resolve the same conflicts. I suppose that could be
annoying, and maybe worth trying to convince one of the library authors
involved to change a name, if you thought it was a common issue.
On May 16, 7:10 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> Did you just write two different replies to the same post?
If I did, it would mean that I received two different copies of the
same post, ergo that you posted two different copies of the same post,
given that the post in question was apparently authored by you.
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 5:50 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> >> I guess that's one of the downsides of an inside-out object
> >> system.
>
> > Inside-out?
>
> Placing methods inside of objects. It was clever in... 1767? But it's
> time to move on. In CLOS, methods, functions, and objects use the same
> package system, rather than all methods applicable to an object being
> mistakenly associated with a particular class.
So, it is your opinion that object orientation is a mistake?
Fascinating.
Equally interesting is your implication that CLOS is not an object
oriented system; such systems being defined by encapsulating objects'
data *and their behavior*, i.e., among other things by placing methods
inside of objects.
> They can do this because methods aren't considered to be inside any
> object, and are therefore free to be "top-level" entities in the
> package system.
As was noted previously in this thread, this has undesirable
consequences, namely, the need to completely specify *two* namespaces
for every operation involving a method call, rather than just one.
This raises the likelihood of name collisions and the verbosity of
code in equal measure.
That this revelation comes from an avowed critic of Java's "bloat" is
especially noteworthy.
> >> > So, basically, you're saying that the way you avoid the name clash is
> >> > to make baz's String.doIt() and quux's String.doIt() private. Of
> >> > course, this now means that anyone who wants their own code to call a
> >> > String.doIt() has to roll their own and can't get a canned one from a
> >> > library. Because if they do, and there's multiple incompatible
> >> > libraries that provide this, then we're back to square one and name
> >> > clashes.
>
> >> No, he's saying that support methods that don't make up a library's API
> >> won't be exported from packages
>
> > Er, that's basically what I meant by "make them private". Duh.
>
> You seemed to be thinking that other methods would be made private as
> well.
On what basis did you infer that nonsense? As can be seen in the
quoted material above, I explicitly stated only that the two clashing
support methods would be made private, and made no reference to making
anything else private.
> > Everywhere the symbols were used there'd need to be some preamble code
> > to "explicitly tell how the clashes should be handled".
>
> Far from it!
Then you deny that the programmer has to "explicitly tell how the
clashes should be handled" near a clash site? Recall that those were
the exact words used by gugamilare in
<····································@e20g2000vbc.googlegroups.com>.
I find it difficult to have a productive debate with a group whose
members frequently contradict one another. Until your "debate team"
can present a more coherent position, you will find it difficult to
sway others towards your beliefs, as your opponents will find it easy
to exploit such contradictions to undermine your credibility.
> You might design a system that worked like that, but I
> assure you that Lisp's designers would and did not.
You and gugamilare apparently disagree as to precisely what Lisp's
designers would do or did do. It is possible that this stems from
differences among dialects of Lisp; I am aware that there are several.
Perhaps you should confine your remarks, for now, to Common Lisp and
spare both sides further confusion.
If it is your beliefs specifically about Common Lisp that are in
conflict, however, then your best strategy at this time is to
withdraw, regroup, and reformulate your position in what football
players term "the huddle" prior to the next "scrimmage".
> It would only work remotely as you imagine if you continually used a set
> of awkwardly named libraries together
It is generally the case that code that uses two external libraries
together is likely to "continually" do so, rather than do so at only
one time, or at only a single location within the codebase. Generally,
that they are used together at any point at all indicates that code
belonging to the same layer, working with the same abstractions, uses
them together, and therefore that such points of conflict will crop up
at numerous locations within that layer of the application, rather
than just the once.
One could of course reduce it to one location by wrapping one of the
libraries, with the one remaining location being inside the wrapper.
This merely replaces one headache with another: the need to create the
wrapper, probably a labor-intensive and unrewarding task and a
potential nesting ground for bugs that otherwise would not have
existed.
Series Expansion <·······@gmail.com> writes:
> On May 16, 7:10 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>> Did you just write two different replies to the same post?
>
> If I did, it would mean that I received two different copies of the
> same post, ergo that you posted two different copies of the same post,
> given that the post in question was apparently authored by you.
>
>> Series Expansion <·······@gmail.com> writes:
>> > On May 15, 5:50 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>> >> I guess that's one of the downsides of an inside-out object
>> >> system.
>>
>> > Inside-out?
>>
>> Placing methods inside of objects. It was clever in... 1767? But it's
>> time to move on. In CLOS, methods, functions, and objects use the same
>> package system, rather than all methods applicable to an object being
>> mistakenly associated with a particular class.
>
> So, it is your opinion that object orientation is a mistake?
No.
> Fascinating.
>
> Equally interesting is your implication that CLOS is not an object
> oriented system; such systems being defined by encapsulating objects'
> data *and their behavior*, i.e., among other things by placing methods
> inside of objects.
No, they aren't defined by that. There are several things that an OO
system might include, such as automatic dispatch based on type, and
inheritance: things that CLOS has. There are other things (such as
private members and methods inside objects) that are optional.
>> They can do this because methods aren't considered to be inside any
>> object, and are therefore free to be "top-level" entities in the
>> package system.
>
> As was noted previously in this thread, this has undesirable
> consequences, namely, the need to completely specify *two* namespaces
> for every operation involving a method call, rather than just one.
> This raises the likelihood of name collisions and the verbosity of
> code in equal measure.
No, it has no such consequence.
> That this revelation comes from an avowed critic of Java's "bloat" is
> especially noteworthy.
>
>> >> > So, basically, you're saying that the way you avoid the name clash is
>> >> > to make baz's String.doIt() and quux's String.doIt() private. Of
>> >> > course, this now means that anyone who wants their own code to call a
>> >> > String.doIt() has to roll their own and can't get a canned one from a
>> >> > library. Because if they do, and there's multiple incompatible
>> >> > libraries that provide this, then we're back to square one and name
>> >> > clashes.
>>
>> >> No, he's saying that support methods that don't make up a library's API
>> >> won't be exported from packages
>>
>> > Er, that's basically what I meant by "make them private". Duh.
>>
>> You seemed to be thinking that other methods would be made private as
>> well.
>
> On what basis did you infer that nonsense? As can be seen in the
> quoted material above, I explicitly stated only that the two clashing
> support methods would be made private, and made no reference to making
> anything else private.
You constantly infer nonsense. I was just taking my turn.
Yes, he was an obvious troll hundreds of posts ago. That doesn't mean
some poor c.l.j.p reader couldn't be misled.
Paul Donnelly wrote:
> Yes, he was an obvious troll hundreds of posts ago. That doesn't mean
> some poor c.l.j.p reader couldn't be misled.
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.
--
Lew
Clem: My religion prohibits proselytization, but promotes prostitution.
Jeb: Really? Where can I sign up?
Clem: I'm sorry. I'm not allowed to tell you.
Lew <·····@lewscanon.com> writes:
> Paul Donnelly wrote:
>> Yes, he was an obvious troll hundreds of posts ago. That doesn't mean
>> some poor c.l.j.p reader couldn't be misled.
>
> 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.
Paul Donnelly wrote:
> Lew <·····@lewscanon.com> writes:
>
>> Paul Donnelly wrote:
>>> Yes, he was an obvious troll hundreds of posts ago. That doesn't mean
>>> some poor c.l.j.p reader couldn't be misled.
>> 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.
Do us a favor and let it wind down off the Java group, hm?
--
Lew
On May 18, 7:44 pm, Lew <·····@lewscanon.com> wrote:
> Paul Donnelly wrote:
> > Lew <·····@lewscanon.com> writes:
>
> >> Paul Donnelly wrote:
> >>> Yes, he was an obvious troll hundreds of posts ago. That doesn't mean
> >>> some poor c.l.j.p reader couldn't be misled.
> >> 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.
>
> Do us a favor and let it wind down off the Java group, hm?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Paul.
On May 18, 2:09 am, Paul Donnelly <·············@sbcglobal.net> wrote:
> Lew <·····@lewscanon.com> writes:
> > Paul Donnelly wrote:
> >> Yes, he was an obvious troll hundreds of posts ago. That doesn't mean
> >> some poor c.l.j.p reader couldn't be misled.
>
> > No "poor c.l.j.p reader could be misled" if you'd just take this
> > thread off of c.l.j.p. Please.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Paul.
On May 17, 8:21 pm, Lew <·····@lewscanon.com> wrote:
> Paul Donnelly wrote:
> > Yes, he was an obvious troll hundreds of posts ago. That doesn't mean
> > some poor c.l.j.p reader couldn't be misled.
>
> No "poor c.l.j.p reader could be misled" if you'd just take this thread off of
> c.l.j.p. Please.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Paul.
I do not lie or mislead people. However, your frequently repeating
these false accusations against me seems to indicate that *you* do
those things.
On May 17, 7:51 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 16, 7:10 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> >> Placing methods inside of objects. It was clever in... 1767? But it's
> >> time to move on. In CLOS, methods, functions, and objects use the same
> >> package system, rather than all methods applicable to an object being
> >> mistakenly associated with a particular class.
>
> > So, it is your opinion that object orientation is a mistake?
>
> No.
But object orientation revolves around two concepts: the encapsulation
of data along with its behavior in a class, and inheritance with
subtyping and is-a relationships.
The former obviously requires that methods be associated with a
particular class.
So you have objected to the first of the two pillars of object
orientation.
The second is severely cracked by having no static types of variables,
arbitrary polymorphism without requiring subclassing, and a few other
features that basically reduce class inheritance to code reuse.
So you have objected to one pillar and cracked the other, severely
damaging it.
> > Fascinating.
>
> > Equally interesting is your implication that CLOS is not an object
> > oriented system; such systems being defined by encapsulating objects'
> > data *and their behavior*, i.e., among other things by placing methods
> > inside of objects.
>
> No, they aren't defined by that.
Yes, they are. See above.
> >> They can do this because methods aren't considered to be inside any
> >> object, and are therefore free to be "top-level" entities in the
> >> package system.
>
> > As was noted previously in this thread, this has undesirable
> > consequences, namely, the need to completely specify *two* namespaces
> > for every operation involving a method call, rather than just one.
> > This raises the likelihood of name collisions and the verbosity of
> > code in equal measure.
>
> No
Yes. And I'm starting to get tired of being called a liar to my face
every five minutes.
> > That this revelation comes from an avowed critic of Java's "bloat" is
> > especially noteworthy.
>
> >> >> > So, basically, you're saying that the way you avoid the name clash is
> >> >> > to make baz's String.doIt() and quux's String.doIt() private. Of
> >> >> > course, this now means that anyone who wants their own code to call a
> >> >> > String.doIt() has to roll their own and can't get a canned one from a
> >> >> > library. Because if they do, and there's multiple incompatible
> >> >> > libraries that provide this, then we're back to square one and name
> >> >> > clashes.
>
> >> >> No, he's saying that support methods that don't make up a library's API
> >> >> won't be exported from packages
>
> >> > Er, that's basically what I meant by "make them private". Duh.
>
> >> You seemed to be thinking that other methods would be made private as
> >> well.
>
> > On what basis did you infer that nonsense? As can be seen in the
> > quoted material above, I explicitly stated only that the two clashing
> > support methods would be made private, and made no reference to making
> > anything else private.
>
> You constantly infer nonsense.
>
> Yes, he was an obvious troll hundreds of posts ago. That doesn't mean
> some poor c.l.j.p reader couldn't be misled.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul.
That last is particularly noisome, accusing me of lying yet again and
imputing a motive of wide-scale sabotage. That is treading perilously
close to libel, Paul.
Series Expansion <·······@gmail.com> writes:
> So, it is your opinion that object orientation is a mistake?
> Fascinating.
So, it is your opinion that there is exactly one model for object
orientation? Fascinating.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> So, it is your opinion that object orientation is a mistake?
>> Fascinating.
>
> So, it is your opinion that there is exactly one model for object
> orientation? Fascinating.
It is my request that this "fascinating" (not) discussion move off the Java
newsgroup. Please.
--
Lew
On May 18, 6:27 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > So, it is your opinion that object orientation is a mistake?
> > Fascinating.
>
> So, it is your opinion that there is exactly one model for object
> orientation? Fascinating.
So, it is your opinion that putting words in your opponent's mouth is
an acceptable and valid debating strategy? Fascinating.
Series Expansion <·······@gmail.com> writes:
> On May 15, 3:35�pm, gugamilare <··········@gmail.com> wrote:
>> On 15 maio, 16:03, Series Expansion <·······@gmail.com> wrote:
>>
>>
>>
>> > On May 15, 12:34�pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>>
>> > > (BTW, this is caused by the inability to add methods to a Java class
>> > > once it is defined. �Another nice, flexible benefit of CLOS).
>>
>> > Another potential source of headaches too, I'll warrant. Imagine the
>> > chaos that would ensue if Java did allow this. Someone might add a
>> > method to the String class called "foo" to do X. Someone else adds a
>> > method to the String class called "foo" to do Y. Then someone tries to
>> > use both pieces of code together in the same project and kaboom!
>>
>> > The only way out looks like adding a whole 'nother system of package
>> > namespaces *inside* *each and every class* for its methods.
>>
>> > Even then you get dependency headaches. Code calling someString.foo()
>> > won't compile if you don't have the right non-standard String
>> > extension in your classpath somewhere. It's one thing if you have
>> > instanceOfSomeUnfamiliarClass.foo() and obviously need a library
>> > installed, but when code calls non-existent methods on standard
>> > library classes like String, who you gonna call? A google search for
>> > "SomeUnfamiliarClass" might turn up the needed library; a google
>> > search for "String" isn't likely to help much.
>>
>> You are once again flaming what you do not understand.
>
> I'm not the one doing the flaming here at all.
>
>> The CL package system will solve the name collision with no harm done.
>
> I just explained why the package system won't. Adding new classes in
> their own packages? No problem, the package system can distinguish
> foo.String from bar.String. Adding new methods to an existing class,
> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
> foo.String.doIt()? They have the same method name, are methods of
> classes with the same name, and the classes are in the same package.
Why don't you believe it when you're told you don't understand something?
Perhaps it's time you learn serriously Common Lisp.
You may start with this introduction: http://www.gigamonkeys.com/book/
In the Common Lisp Object System (CLOS), methods are not attached to a
class, but to a generic function, and generic functions, like any
other, may be named by any symbol. It could be a symbol interned in
the same package as the symbol naming the class of one of the
parameter of one of the method of the generic function or in another
package or even in no package at all.
Concerning the names, it's like if having a class foo.String, you
could define a java method foo.doIt and another java method bar.doIt.
(new foo.MyString).(foo.doIt)() would no call the same method as
(new foo.MyString).(bar.doIt)().
You could do:
(defpackage "FOO" (:use "CL") (:export "MY-STRING" "DO-IT"))
(defclass foo:my-string () ())
(defgeneric foo:do-it (a b))
(defmethod foo:do-it ((a integer) (b foo:my-string)) '(the do-it in foo))
(defpackage "BAR" (:use "CL") (:export "DO-IT"))
(defgeneric bar:do-it (a b))
(defmethod bar:do-it ((a integer) (b foo:my-string)) '(the do-it in bar))
and then:
(foo:do-it 42 (make-instance 'foo:my-string)) --> (THE DO-IT IN FOO)
(bar:do-it 42 (make-instance 'foo:my-string)) --> (THE DO-IT IN BAR)
> As far as the compiler is concerned, they are the same. The package
> system cannot distinguish them unless we add another layer of
> namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
> and foo.String.quux.doIt() instead of just foo.String.doIt() as the
> fully-qualified names. And now we're deep in migraine-headache
> territory, without oar or compass...
Right, non-lisp programming languages are migraine-headache territory.
We never said otherwise.
>> They will only make external the functions / methods that
>> provide the functionality of the lib.
>
> Java can do this too.
>
> So, basically, you're saying that the way you avoid the name clash is
> to make baz's String.doIt() and quux's String.doIt() private.
Not in CLOS.
> [...]
>
> Of course, the best way to avoid multiple incompatible libraries is to
> have commonly desired functionality built into the standard library.
> And then letting third parties create (non-private, at least) methods
> in your classes is unnecessary.
No, the best way to avoid multiple incompatible libraries is to use
the package system of Lisp.
--
__Pascal Bourguignon__
Series Expansion writes:
>> I'm not the one doing the flaming here at all.
Pascal J. Bourguignon wrote:
> Why don't you believe it when you're told you don't understand something?
He probably doesn't believe it because, a), he does understand it, and b),
telling someone off in that manner is incredibly annoying, arrogant and
common. Flame wars are introduced and fanned with comments like, "Why don't
you believe it when you're told you don't understand something?" Questions
and comments like that make the poster sound like an arrogant pr*ck.
The main difference between Lisp adherents and Java adherents is that Lisp
adherents spend their arrogance making a religion out of defending Lisp
against all comers, and Java adherents religiously criticize Java for its
shortcomings.
--
Lew
My popcorn is ready.
Lew wrote:
> Series Expansion writes:
>>> I'm not the one doing the flaming here at all.
>
> Pascal J. Bourguignon wrote:
>> Why don't you believe it when you're told you don't understand something?
>
> He probably doesn't believe it because, a), he does understand it, and
> b), telling someone off in that manner is incredibly annoying, arrogant
> and common. Flame wars are introduced and fanned with comments like,
> "Why don't you believe it when you're told you don't understand
> something?" Questions and comments like that make the poster sound like
> an arrogant pr*ck.
>
> The main difference between Lisp adherents and Java adherents is that
> Lisp adherents spend their arrogance making a religion out of defending
> Lisp against all comers, and Java adherents religiously criticize Java
> for its shortcomings.
>
Suggesting that the main difference between Lisp and Java is that Lisp
is unassailably great and Java is full of shortcomings.
I have long thought that Java might be the only language no one ever
loved, including even its creators. In case you are wondering, that is
not a good sign.
kt
ps. I thought you were going to *watch*. Won't you keep knocking over
that bowl of popcorn? kt
Lew wrote:
>> The main difference between Lisp adherents and Java adherents is that
>> Lisp adherents spend their arrogance making a religion out of
>> defending Lisp against all comers, and Java adherents religiously
>> criticize Java for its shortcomings.
Kenneth Tilton wrote:
> Suggesting that the main difference between Lisp and Java is that Lisp
> is unassailably great and Java is full of shortcomings.
Say rather that Lisp programmers drink the Kool-Aid and Java programmers are
pragmatic and thoughtful.
> I have long thought that Java might be the only language no one ever
> loved, including even its creators. In case you are wondering, that is
> not a good sign.
I was not wondering, and you have not established that goggle-eyed adoration
is superior. I think it's a good sign that Java adherents are committed to
improvement and constant examination. I also find it telling that far more
commercial projects are programmed in Java than Lisp. So it's a good and
healthy sign that competent Java programmers, of whom I'm one, continue to
examine the language.
> ps. [sic] I thought you were going to *watch*. Won't you keep knocking over
> that bowl of popcorn? kt
Interesting that you feel the need to resort to personal attack. What fun!
Perhaps Java programmers are more secure in their knowledge of the language
and see it merely as a tool, and not some cult that requires snarky remarks
and blind devotion in lieu of reasoned and dispassionate utility. Or perhaps
not. I just notice that the tone in this thread from the Lisp programmers
tends to the nasty and personal compared to those who are trying to explain
why they find Java useful.
I am suspicious of anyone who claims any programming language is the be-all
and end-all for all purposes world without end amen.
--
Lew
Lew wrote:
> Lew wrote:
>>> The main difference between Lisp adherents and Java adherents is that
>>> Lisp adherents spend their arrogance making a religion out of
>>> defending Lisp against all comers, and Java adherents religiously
>>> criticize Java for its shortcomings.
>
> Kenneth Tilton wrote:
>
>> Suggesting that the main difference between Lisp and Java is that Lisp
>> is unassailably great and Java is full of shortcomings.
>
>
> Say rather that Lisp programmers drink the Kool-Aid and Java programmers
> are pragmatic and thoughtful.
Say this: Lisp programmers have programming jobs meaning they know Java
or Python or Ruby or whatever so there is prolly not much delusion
involved. It is more of an informed comparison. Yes, the bad news is
that we are also better at those languages than you. Sorry for the comedown.
>
>> I have long thought that Java might be the only language no one ever
>> loved, including even its creators. In case you are wondering, that is
>> not a good sign.
>
> I was not wondering, and you have not established that goggle-eyed
> adoration is superior.
I took a different path, I pointed out that we Lisp Gods have Perfect
Knowledge of crud like Java, we have to to feed the kids.
> I think it's a good sign that Java adherents are
> committed to improvement and constant examination. I also find it
> telling that far more commercial projects are programmed in Java than
> Lisp.
I find it telling that Groovy got invented because the tide had left
static typing and all-OO-all-the-time and catch-every-exception high and
dry and was not coming back.
> So it's a good and healthy sign that competent Java programmers,
> of whom I'm one, continue to examine the language.
<sigh> Lisp did that in the Sixties, and with a better Pole Star ("code
is data is code") than Java ("programmers are incompetent"). I must say,
you do not seem incompetent, you seem quite bright. Shouldn't you be
using a language that respects you? Sorry for getting personal.
>
>> ps. [sic] I thought you were going to *watch*. Won't you keep knocking
>> over that bowl of popcorn? kt
>
> Interesting that you feel the need to resort to personal attack. What fun!
You made three jokes about popcorn and I made one, which did nothing
more than catch you out on a minor gaffe (claiming to sit back as you
were diving in) and you call that a personal attack? Hmmm... OK, I have
two interpretations. Either you are barking mad or you slipped up and
trotted out the "ooh that's personal" flamewar gambit without
foundation? I am guessing the latter, and blame the popcorn.
>
> Perhaps Java programmers are more secure in their knowledge of the
> language ...
Explaining why they spend all their time complaining about it? I had a
wife like that once.
> ...and see it merely as a tool, and not some cult that requires
> snarky remarks and blind devotion in lieu of reasoned and dispassionate
> utility. Or perhaps not. I just notice that the tone in this thread
> from the Lisp programmers tends to the nasty and personal compared to
> those who are trying to explain why they find Java useful.
Useful? A tool? Oh, be still my beating heart. A wise man once said that
Java was the only language no one ever loved.
>
> I am suspicious of anyone who claims any programming language is the
> be-all and end-all for all purposes world without end amen.
>
Ah, never had the pleasure of macros, have we? Glory be to the
readability and to the parsing and to the &whole parameter.
You seem like a great guy and quite bright at that. Do yourself a favor,
STFU and learn Lisp. Mr Costanza can fill you in on the rest.
hth, kt
Kenneth Tilton wrote:
> Lew wrote:
>> Lew wrote:
>>>> The main difference between Lisp adherents and Java adherents is
>>>> that Lisp adherents spend their arrogance making a religion out of
>>>> defending Lisp against all comers, and Java adherents religiously
>>>> criticize Java for its shortcomings.
>>
>> Kenneth Tilton wrote:
>>
>>> Suggesting that the main difference between Lisp and Java is that
>>> Lisp is unassailably great and Java is full of shortcomings.
>>
>>
>> Say rather that Lisp programmers drink the Kool-Aid and Java
>> programmers are pragmatic and thoughtful.
>
> Say this: Lisp programmers have programming jobs meaning they know Java
> or Python or Ruby or whatever so there is prolly not much delusion
> involved. It is more of an informed comparison. Yes, the bad news is
> that we are also better at those languages than you. Sorry for the
> comedown.
Nobody makes an arrogant statement like that on usenet without getting
his nose tweaked.
Nobody.
>>> I have long thought that Java might be the only language no one ever
>>> loved, including even its creators. In case you are wondering, that
>>> is not a good sign.
>>
>> I was not wondering, and you have not established that goggle-eyed
>> adoration is superior.
>
> I took a different path
That much is certain. (I think it might be that rather well-known one
that's paved with good intentions.)
> I pointed out that we Lisp Gods have Perfect Knowledge of crud
That is arguably correct also, though Perfect Knowledge is ordinarily
considered to be the sole preserve of God. Oh, wait, did you not also
explicitly say you *were* God? I believe you did.
There's probably a special place in Hell being warmed up for you by the
horned d00d while the bearded d00d sets you up for a brain aneurysm or
lightning-up-the-phone-line or something.
>> I think it's a good sign that Java adherents are committed to
>> improvement and constant examination. I also find it telling that far
>> more commercial projects are programmed in Java than Lisp.
>
> I find it telling that Groovy got invented because the tide had left
> static typing and all-OO-all-the-time and catch-every-exception high and
> dry and was not coming back.
Java myth #5! "Java programmers catch every exception". Actually we try
to catch only the relevant exceptions in a particular bit of code, or
even none (with try ... finally without catch), though occasionally some
code might catch everything to log it and rethrow.
Some BAD Java programmers put catch(Exception) or catch(Throwable) all
over the place.
>> So it's a good and healthy sign that competent Java programmers, of
>> whom I'm one, continue to examine the language.
>
> <sigh> Lisp did that in the Sixties
All kinds of things got did in the Sixties. Most of them are illegal now.
> Java ("programmers are incompetent").
Java myth #6! "Java programmers are incompetent".
> I must say, you do not seem incompetent, you seem quite bright.
Oh wait, it looks like Java myth #6 is starting to be questioned by the
lispers. Perhaps a harbinger of bigger changes to come?
>> Perhaps Java programmers are more secure in their knowledge of the
>> language ...
>
> Explaining why they spend all their time complaining about it?
The compiler spends all its time complaining about our code. Turnabout
is fair play. :)
More seriously, the language can use improvement, and maintenance, and
that requires criticism and a realistic outlook.
> I had a wife like that once.
What, she spent a lot of time complaining about Java?
Is she single now?
>> ...and see it merely as a tool, and not some cult that requires snarky
>> remarks and blind devotion in lieu of reasoned and dispassionate
>> utility. Or perhaps not. I just notice that the tone in this thread
>> from the Lisp programmers tends to the nasty and personal compared to
>> those who are trying to explain why they find Java useful.
>
> Useful? A tool? Oh, be still my beating heart. A wise man once said that
> Java was the only language no one ever loved.
Another wise man once said that the surest sign that the right decision
had been made was that everyone on both sides complained about it, but
they abided by it anyway.
>> I am suspicious of anyone who claims any programming language is the
>> be-all and end-all for all purposes world without end amen.
>
> Ah, never had the pleasure of macros, have we? Glory be to the
> readability and to the parsing and to the &whole parameter.
^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
Oh, the irony.
> You seem like a great guy and quite bright at that. Do yourself a favor,
> STFU
How rude!
Seamus MacRae wrote:
> Kenneth Tilton wrote (no he didn't):
>> Java ("programmers are incompetent").
That was not me, that was Gosling and Steele who designed Java around
that assumption.
>
> Java myth #6! "Java programmers are incompetent".
>
>> I must say, you do not seem incompetent, you seem quite bright.
>
> Oh wait, it looks like Java myth #6 is starting to be questioned by the
> lispers. Perhaps a harbinger of bigger changes to come?
You missed my point that Lispers know all these other languages, meaning
we are you only we have been saved by finding Lisp. COBOL, FORTRAN,
BASIC, C, C++, Java, Python, Ruby, Perl -- you name it, we know them and
have succeeded wildly with them in big serious projects. If the ALU had
not managed to erase The Road to Lisp from written history I could point
you to the stories of how Lispers found Lisp. A few were born into
Righteousness because they attended MIT or CMU in the sixties, the rest
found it because they were great programmers but knew the languages
above were holding them back, that there had to be a better way.
>
>>> Perhaps Java programmers are more secure in their knowledge of the
>>> language ...
>>
>> Explaining why they spend all their time complaining about it?
>
> The compiler spends all its time complaining about our code. Turnabout
> is fair play. :)
>
> More seriously, the language can use improvement, and maintenance, and
> that requires criticism and a realistic outlook.
>
>> I had a wife like that once.
>
> What, she spent a lot of time complaining about Java?
No, she could have used improvement and maintenance but I put up with
her for ten years before switching to a Cherry 2000.
>> You seem like a great guy and quite bright at that. Do yourself a
>> favor, STFU
>
> How rude!
I can imagine you complaining to the fireman carrying you out of the
burning building that he did not knock before coming in.
hth, kzo
Kenneth Tilton escreveu:
> Seamus MacRae wrote:
>> Kenneth Tilton wrote (no he didn't):
> You missed my point that Lispers know all these other languages, meaning
> we are you only we have been saved by finding Lisp. COBOL, FORTRAN,
> BASIC, C, C++, Java, Python, Ruby, Perl -- you name it, we know them and
> have succeeded wildly with them in big serious projects. If the ALU had
> not managed to erase The Road to Lisp from written history I could point
> you to the stories of how Lispers found Lisp. A few were born into
what?! That big Road to Lisp thingy just disappeared from Earth??! Why
didn't it remain at cliki?
I also don't believe I missed this whole big fun flamewar...
>>> I had a wife like that once.
>>
>> What, she spent a lot of time complaining about Java?
>
> No, she could have used improvement and maintenance but I put up with
> her for ten years before switching to a Cherry 2000.
another one for kenny fortunes... :D
--
a game sig: http://tinyurl.com/d3rxz9
namekuseijin wrote:
> Kenneth Tilton escreveu:
>> Seamus MacRae wrote:
>>> Kenneth Tilton wrote (no he didn't):
>> You missed my point that Lispers know all these other languages,
>> meaning we are you only we have been saved by finding Lisp. COBOL,
>> FORTRAN, BASIC, C, C++, Java, Python, Ruby, Perl -- you name it, we
>> know them and have succeeded wildly with them in big serious projects.
>> If the ALU had not managed to erase The Road to Lisp from written
>> history I could point you to the stories of how Lispers found Lisp. A
>> few were born into
>
> what?! That big Road to Lisp thingy just disappeared from Earth??! Why
> didn't it remain at cliki?
The Yobbos threw it out because it was not related to open source
software. No, I am not kidding.
>
> I also don't believe I missed this whole big fun flamewar...
>
>>>> I had a wife like that once.
>>>
>>> What, she spent a lot of time complaining about Java?
>>
>> No, she could have used improvement and maintenance but I put up with
>> her for ten years before switching to a Cherry 2000.
>
> another one for kenny fortunes... :D
>
You'll have to explain the movie, but there is nothing wrong with that,
it's a little known Melanie Griffith classic.
kt
On May 18, 8:54 pm, Kenneth Tilton <·········@gmail.com> wrote:
> namekuseijin wrote:
> > Kenneth Tilton escreveu:
> >> Seamus MacRae wrote:
> >>> Kenneth Tilton wrote (no he didn't):
> >> You missed my point that Lispers know all these other languages,
> >> meaning we are you only we have been saved by finding Lisp. COBOL,
> >> FORTRAN, BASIC, C, C++, Java, Python, Ruby, Perl -- you name it, we
> >> know them and have succeeded wildly with them in big serious projects.
> >> If the ALU had not managed to erase The Road to Lisp from written
> >> history I could point you to the stories of how Lispers found Lisp. A
> >> few were born into
>
> > what?! That big Road to Lisp thingy just disappeared from Earth??! Why
> > didn't it remain at cliki?
>
> The Yobbos threw it out because it was not related to open source
> software. No, I am not kidding.
There's archive.org. Don't know how complete it is:
http://web.archive.org/web/*/http://wiki.alu.org/The_Road_To_Lisp_Survey
http://web.archive.org/web/20080214181905/http://wiki.alu.org/The_Road_To_Lisp_Survey
Lars Rune N�stdal wrote:
> On May 18, 8:54 pm, Kenneth Tilton <·········@gmail.com> wrote:
>> namekuseijin wrote:
>>> Kenneth Tilton escreveu:
>>>> Seamus MacRae wrote:
>>>>> Kenneth Tilton wrote (no he didn't):
>>>> You missed my point that Lispers know all these other languages,
>>>> meaning we are you only we have been saved by finding Lisp. COBOL,
>>>> FORTRAN, BASIC, C, C++, Java, Python, Ruby, Perl -- you name it, we
>>>> know them and have succeeded wildly with them in big serious projects.
>>>> If the ALU had not managed to erase The Road to Lisp from written
>>>> history I could point you to the stories of how Lispers found Lisp. A
>>>> few were born into
>>> what?! That big Road to Lisp thingy just disappeared from Earth??! Why
>>> didn't it remain at cliki?
>> The Yobbos threw it out because it was not related to open source
>> software. No, I am not kidding.
>
> There's archive.org. Don't know how complete it is:
>
> http://web.archive.org/web/*/http://wiki.alu.org/The_Road_To_Lisp_Survey
>
> http://web.archive.org/web/20080214181905/http://wiki.alu.org/The_Road_To_Lisp_Survey
Hey, that does look good. Thx.
Anyone know how to scrape those, or should I just relax and let
web.archive.log serve as the new home... ah, but then the Survey is
ended. Hmmm, hasn't had much life in years...
kt
Kenneth Tilton wrote:
> Lars Rune N�stdal wrote:
>>
>> There's archive.org. Don't know how complete it is:
>>
>> http://web.archive.org/web/*/http://wiki.alu.org/The_Road_To_Lisp_Survey
>>
>> http://web.archive.org/web/20080214181905/http://wiki.alu.org/The_Road_To_Lisp_Survey
>>
>
> Hey, that does look good. Thx.
>
> Anyone know how to scrape those, or should I just relax and let
> web.archive.log serve as the new home... ah, but then the Survey is
> ended. Hmmm, hasn't had much life in years...
>
> kt
Oh, wow. Thank you so much. I've heard so much about this but never
found it. I've just started reading about lisp and its great to read
about how other people found there way here.
Bata wrote:
> Kenneth Tilton wrote:
>> Lars Rune N�stdal wrote:
>>> There's archive.org. Don't know how complete it is:
>>>
>>> http://web.archive.org/web/*/http://wiki.alu.org/The_Road_To_Lisp_Survey
>>>
>>> http://web.archive.org/web/20080214181905/http://wiki.alu.org/The_Road_To_Lisp_Survey
>>>
>> Hey, that does look good. Thx.
>>
>> Anyone know how to scrape those, or should I just relax and let
>> web.archive.log serve as the new home... ah, but then the Survey is
>> ended. Hmmm, hasn't had much life in years...
>>
>> kt
>
> Oh, wow. Thank you so much. I've heard so much about this but never
> found it. I've just started reading about lisp and its great to read
> about how other people found there way here.
I just learned the RtL is not dead, it is resting:
http://cliki.tech.coop:8888/
Headed for resurrection on the ALU wiki, it seems.
(Thx again, Drew.)
kt
Kenneth Tilton wrote:
> Lars Rune N�stdal wrote:
>> On May 18, 8:54 pm, Kenneth Tilton <·········@gmail.com> wrote:
>>> namekuseijin wrote:
>>>> Kenneth Tilton escreveu:
>>>>> Seamus MacRae wrote:
>>>>>> Kenneth Tilton wrote (no he didn't):
>>>>> You missed my point
I missed nothing. But is this a tacit admission that you did indeed
write what you accused me of misattributing?
>> There's archive.org. Don't know how complete it is:
>
> Hey, that does look good. Thx.
...
Lars Rune N�stdal wrote:
> On May 18, 8:54 pm, Kenneth Tilton <·········@gmail.com> wrote:
>> namekuseijin wrote:
>>> Kenneth Tilton escreveu:
>>>> Seamus MacRae wrote:
>>>>> Kenneth Tilton wrote (no he didn't):
>>>> You missed my point
I missed nothing. But is this a tacit admission that Kenneth did indeed
write what he accused me of misattributing?
>>> what?! That big Road to Lisp thingy just disappeared from Earth??! Why
>>> didn't it remain at cliki?
>> The Yobbos threw it out because it was not related to open source
>> software. No, I am not kidding.
>
> There's archive.org. Don't know how complete it is:
>
> http://web.archive.org/web/*/http://wiki.alu.org/The_Road_To_Lisp_Survey
>
> http://web.archive.org/web/20080214181905/http://wiki.alu.org/The_Road_To_Lisp_Survey
Kenneth Tilton wrote:
> namekuseijin wrote:
>> Kenneth Tilton escreveu:
>>> Seamus MacRae wrote:
>>>> Kenneth Tilton wrote (no he didn't):
>>> You missed my point
I missed nothing. But is this a tacit admission that you did indeed
write what you just accused me of misattributing?
>>>>> I had a wife like that once.
>>>>
>>>> What, she spent a lot of time complaining about Java?
>>>
>>> No, she could have used improvement and maintenance but I put up with
>>> her for ten years before switching to a Cherry 2000.
>>
>> another one for kenny fortunes... :D
>
> You'll have to explain the movie, but there is nothing wrong with that,
> it's a little known Melanie Griffith classic.
Those (fully-functional female androids) haven't been invented yet.
Let me guess: you're both from the future, and the anti-Lisp
book-burnings and feedings of Lispers to lions in the Colosseum occur in
the year 2074?
You should stick to writing science fiction and leave the computer
programming to us. :)
namekuseijin wrote:
> Kenneth Tilton escreveu:
>> Seamus MacRae wrote:
>>> Kenneth Tilton wrote (no he didn't):
>> You missed my point
I missed nothing. But is this a tacit admission that Kenneth did indeed
write what he just accused me of misattributing?
> I also don't believe I missed this whole big fun flamewar...
Fun it isn't, and it isn't apparently over yet, either.
>>>> I had a wife like that once.
>>>
>>> What, she spent a lot of time complaining about Java?
>>
>> No, she could have used improvement and maintenance but I put up with
>> her for ten years before switching to a Cherry 2000.
>
> another one for kenny fortunes... :D
Those (fully-functional female androids) haven't been invented yet.
Let me guess: you're both from the future, and the anti-Lisp
book-burnings and feedings of Lispers to lions in the Colosseum occur in
the year 2074?
You should stick to writing science fiction and leave the computer
programming to us. :)
Kenneth Tilton wrote:
> Seamus MacRae wrote:
>> Kenneth Tilton wrote (no he didn't):
>>> Java ("programmers are incompetent").
>
> That was not me
Yes it was, in <························@cv.net>, in which you wrote:
> <sigh> Lisp did that in the Sixties, and with a better Pole Star ("code is
> data is code") than Java ("programmers are incompetent"). I must say, you
> do not seem incompetent, you seem quite bright. Shouldn't you be using a
> language that respects you? Sorry for getting personal.
http://groups.google.com/group/comp.lang.lisp/msg/7b770fd050b6c0b1 if
you don't believe me.
Don't falsely accuse me of lying, misquoting, or misattributing again.
>> Java myth #6! "Java programmers are incompetent".
>>
>>> I must say, you do not seem incompetent, you seem quite bright.
>>
>> Oh wait, it looks like Java myth #6 is starting to be questioned by
>> the lispers. Perhaps a harbinger of bigger changes to come?
>
> You missed my point
I missed nothing. But is this a tacit admission that you did indeed
write what you just accused me of misattributing?
> that Lispers know all these other languages, meaning we are you only we
> have been saved by finding Lisp.
It's nice to have it confirmed that this is a matter of religious belief
for you rather than anything you can be persuaded about rationally. That
is the only conclusion to be drawn by the use of such phrases as "we
have been saved"; this is some sort of messianic belief system rather
than an evidence-based one.
Which, in turn, explains why many of your "arguments" are just
hand-waves: "Wouldn't X then cause all kinds of headaches?" "Nah, not a
problem" rather than a detailed explanation, argument, or some evidence
and citations pointing to some unconsidered workaround for X and
documenting its effectiveness.
The problems are "not a problem" for you not because you have solved
them then but because you have become inured to them; have accepted them
as your penance. They are "not a problem" for you in the way that their
whips are not a problem for flagellants.
> If the ALU had not managed to erase The Road to Lisp from written
> history I could point you to the stories of how Lispers found Lisp.
This religion is even more well-developed than I'd thought! It already
has conspiracy theories, tales of persecution, and a supposed attempt to
purge it from history already woven into it.
Of course, in the modern age in developed countries we do not have
book-burnings or other forms of historical revisionism, so you'll pardon
me if I take the above with a grain of salt roughly the size of Iowa.
Nothing like that kind of madness has happened in western Europe or
North America since 1945, and Lisp hadn't been invented then.
> A few were born into Righteousness
Okay, I think I've heard enough of this hysteria.
Rational discussion with you people is clearly out of the question, so I
guess that's the end of this thread.
>>>> Perhaps Java programmers are more secure in their knowledge of the
>>>> language ...
>>>
>>> Explaining why they spend all their time complaining about it?
>>> I had a wife like that once.
>>
>> What, she spent a lot of time complaining about Java?
>
> No, she could have used improvement and maintenance but I put up with
> her for ten years before switching to a Cherry 2000.
Those (fully-functional female androids) haven't been invented yet.
Let me guess: you're from the future, and the anti-Lisp book-burnings
and feedings of Lispers to lions in the Colosseum occur in the year 2074?
You should stick to writing science fiction and leave the computer
programming to us. :)
>>> You seem like a great guy and quite bright at that. Do yourself a
>>> favor, STFU
>>
>> How rude!
>
> I can imagine you complaining to the fireman carrying you out of the
> burning building that he did not knock before coming in.
Analogy failure. Java is not comparable to a burning building, and
(outside of your messianic religion) Lisp is not a savior, though it may
(in some instances) turn out (occasionally) to be a useful tool.
Seamus MacRae <··········@live.ca.nospam> writes:
> Kenneth Tilton wrote:
>> Lew wrote:
>>> Lew wrote:
>>>>> The main difference between Lisp adherents and Java adherents is
>>>>> that Lisp adherents spend their arrogance making a religion out
>>>>> of defending Lisp against all comers, and Java adherents
>>>>> religiously criticize Java for its shortcomings.
>>>
>>> Kenneth Tilton wrote:
>>>
>>>> Suggesting that the main difference between Lisp and Java is that
>>>> Lisp is unassailably great and Java is full of shortcomings.
>>>
>>>
>>> Say rather that Lisp programmers drink the Kool-Aid and Java
>>> programmers are pragmatic and thoughtful.
>>
>> Say this: Lisp programmers have programming jobs meaning they know
>> Java or Python or Ruby or whatever so there is prolly not much
>> delusion involved. It is more of an informed comparison. Yes, the
>> bad news is that we are also better at those languages than
>> you. Sorry for the comedown.
>
> Nobody makes an arrogant statement like that on usenet without getting
> his nose tweaked.
>
> Nobody.
PUWAHAHAHAHA - Puwaaahahhhahaaahahaaa - Good grief, man, you're talking
to Kenny Tilton.
>
>>>> I have long thought that Java might be the only language no one
>>>> ever loved, including even its creators. In case you are
>>>> wondering, that is not a good sign.
>>>
>>> I was not wondering, and you have not established that goggle-eyed
>>> adoration is superior.
>>
>> I took a different path
>
> That much is certain. (I think it might be that rather well-known one
> that's paved with good intentions.)
You are so sweet in your childish innocence.
>
>> I pointed out that we Lisp Gods have Perfect Knowledge of crud
>
> That is arguably correct also, though Perfect Knowledge is ordinarily
> considered to be the sole preserve of God. Oh, wait, did you not also
> explicitly say you *were* God? I believe you did.
Well, man, I can tell you, he is one of the Lisp Gods, really. Because
he is one of those who are able to help and support others in doing them
good and in doing them bad. (That's a *hint* for you !)
If he says something then you should *listen* - er, read. I have learned
to read twice (at least) when one of the Language Gods (not just the
Lisp Gods, you know) is sending us their wisdom.
Or, do you mean ... are you one of the Java Gods ?
Cheers
Frank
Frank GOENNINGER wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
> [stuff elided]...
> Well, man, I can tell you, he is one of the Lisp Gods, really. Because
> he is one of those who are able to help and support others in doing them
> good and in doing them bad. (That's a *hint* for you !)
>
> If he says something then you should *listen* - er, read. I have learned
> to read twice (at least) when one of the Language Gods (not just the
> Lisp Gods, you know) is sending us their wisdom.
>
> Or, do you mean ... are you one of the Java Gods ?
I assure you that "Seamus" is most definitely not one of the Java gods.
--
Lew
Lew wrote:
> Frank GOENNINGER wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>> [stuff elided]...
>
>> Well, man, I can tell you, he is one of the Lisp Gods, really. Because
>> he is one of those who are able to help and support others in doing them
>> good and in doing them bad. (That's a *hint* for you !)
>>
>> If he says something then you should *listen* - er, read. I have learned
>> to read twice (at least) when one of the Language Gods (not just the
>> Lisp Gods, you know) is sending us their wisdom.
>>
>> Or, do you mean ... are you one of the Java Gods ?
>
> I assure you that "Seamus" is most definitely not one of the Java gods.
Nope. Just an ordinary guy.
Frank GOENNINGER wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Kenneth Tilton wrote:
>>> Lew wrote:
>>>> Lew wrote:
>>>>>> The main difference between Lisp adherents and Java adherents is
>>>>>> that Lisp adherents spend their arrogance making a religion out
>>>>>> of defending Lisp against all comers, and Java adherents
>>>>>> religiously criticize Java for its shortcomings.
>>>> Kenneth Tilton wrote:
>>>>
>>>>> Suggesting that the main difference between Lisp and Java is that
>>>>> Lisp is unassailably great and Java is full of shortcomings.
>>>>
>>>> Say rather that Lisp programmers drink the Kool-Aid and Java
>>>> programmers are pragmatic and thoughtful.
>>> Say this: Lisp programmers have programming jobs meaning they know
>>> Java or Python or Ruby or whatever so there is prolly not much
>>> delusion involved. It is more of an informed comparison. Yes, the
>>> bad news is that we are also better at those languages than
>>> you. Sorry for the comedown.
>> Nobody makes an arrogant statement like that on usenet without getting
>> his nose tweaked.
>>
>> Nobody.
>
> PUWAHAHAHAHA - Puwaaahahhhahaaahahaaa - Good grief, man, you're talking
> to Kenny Tilton.
Damn. I was looking forward to that, sounded kinda kinky.
>
>>>>> I have long thought that Java might be the only language no one
>>>>> ever loved, including even its creators. In case you are
>>>>> wondering, that is not a good sign.
>>>> I was not wondering, and you have not established that goggle-eyed
>>>> adoration is superior.
>>> I took a different path
>> That much is certain. (I think it might be that rather well-known one
>> that's paved with good intentions.)
>
> You are so sweet in your childish innocence.
>
>>> I pointed out that we Lisp Gods have Perfect Knowledge of crud
>> That is arguably correct also, though Perfect Knowledge is ordinarily
>> considered to be the sole preserve of God. Oh, wait, did you not also
>> explicitly say you *were* God? I believe you did.
>
> Well, man, I can tell you, he is one of the Lisp Gods, really. Because
> he is one of those who are able to help and support others in doing them
> good and in doing them bad. (That's a *hint* for you !)
>
> If he says something then you should *listen* - er, read.
Damn. I suppose now I have to start answering your questions about Cello.
Did you grok the coordinate geometry yet? One guy working for me
characterized it as a system only Kenny could understand. Unfortunately
he was gone before I discovered the prior example of a little thing
called OpenGL.
kt
Kenneth Tilton <·········@gmail.com> writes:
> Frank GOENNINGER wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>
>>> Kenneth Tilton wrote:
>>>> Say this: Lisp programmers have programming jobs meaning they know
>>>> Java or Python or Ruby or whatever so there is prolly not much
>>>> delusion involved. It is more of an informed comparison. Yes, the
>>>> bad news is that we are also better at those languages than
>>>> you. Sorry for the comedown.
>>> Nobody makes an arrogant statement like that on usenet without getting
>>> his nose tweaked.
>>>
>>> Nobody.
>>
>> PUWAHAHAHAHA - Puwaaahahhhahaaahahaaa - Good grief, man, you're talking
>> to Kenny Tilton.
>
> Damn. I was looking forward to that, sounded kinda kinky.
Well, I was looking for the right tone in my response and came up short
and dry. This sounded about right and appropriate to the unbelievable
arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>>>>>> I have long thought that Java might be the only language no one
>>>>>> ever loved, including even its creators. In case you are
>>>>>> wondering, that is not a good sign.
>>>>> I was not wondering, and you have not established that goggle-eyed
>>>>> adoration is superior.
>>>> I took a different path
>>> That much is certain. (I think it might be that rather well-known one
>>> that's paved with good intentions.)
>>
>> You are so sweet in your childish innocence.
>>
>>>> I pointed out that we Lisp Gods have Perfect Knowledge of crud
>>> That is arguably correct also, though Perfect Knowledge is ordinarily
>>> considered to be the sole preserve of God. Oh, wait, did you not also
>>> explicitly say you *were* God? I believe you did.
>>
>> Well, man, I can tell you, he is one of the Lisp Gods, really. Because
>> he is one of those who are able to help and support others in doing them
>> good and in doing them bad. (That's a *hint* for you !)
>>
>> If he says something then you should *listen* - er, read.
>
> Damn. I suppose now I have to start answering your questions about
> Cello.
Yep. ;-)
>
> Did you grok the coordinate geometry yet? One guy working for me
> characterized it as a system only Kenny could
> understand. Unfortunately he was gone before I discovered the prior
> example of a little thing called OpenGL.
>
> kt
As you know I am fond of pictures and diagrams. So I am currently making
up a series of slides showing the coordinate geometry's major elements
and their effects to the different kinds of controls / widgets.
I have working the event handling, mouse tracking, and Togl of course. I
have stripped down the former Cello classes to about half the amount in
Cello NX (so far, not counting the various controls).
The one thing I am still working on is to make up a good picture
explanining the concept of an Outset... As soon as I have this done I'd
like you to review it and then we go for a very streamlined
implementation...
Thanks in advance!
Cheers
Frank
Frank GOENNINGER wrote:
> Well, I was looking for the right tone in my response and came up short
> and dry. This sounded about right and appropriate to the unbelievable
> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
Trolls. I recommend not feeding them.
--
Lew
From: Frank GOENNINGER
Subject: OT: Seamus and Series Expansion are trolls, indeed. And: SCREEN CASTS pointer - WAS: Re: macros
Date:
Message-ID: <m2ljovfx5n.fsf_-_@ccde007.de.goenninger.net>
Lew <·····@lewscanon.com> writes:
> Frank GOENNINGER wrote:
>> Well, I was looking for the right tone in my response and came up short
>> and dry. This sounded about right and appropriate to the unbelievable
>> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>
> Trolls. I recommend not feeding them.
Yes, you're right, I know. Sadly these trolls may do damage that is
beyond our control. Therefore I did post a few replies (as other did,
too).
In order to make even this post really valuable to all readers I want to
once again point everybody to a series of screen casts:
http://lispcast.blip.tv/posts?view=archive&nsfw=dc
Start at Episode 1 and watch them in full screen mode. A real good way
of understanding the power of Common Lisp as a full-fledged languange,
SLIME as being a full-fledged IDE. And have some fun.
Enjoy!
Frank
From: Lew
Subject: Re: OT: Seamus and Series Expansion are trolls, indeed. And: SCREEN CASTS pointer - WAS: Re: macros
Date:
Message-ID: <gupnnb$gm6$1@news.albasani.net>
Frank GOENNINGER wrote:
> In order to make even this post really valuable to all readers I want to
> once again point everybody to a series of screen casts:
>
> http://lispcast.blip.tv/posts?view=archive&nsfw=dc
>
> Start at Episode 1 and watch them in full screen mode. A real good way
> of understanding the power of Common Lisp as a full-fledged languange,
> SLIME as being a full-fledged IDE. And have some fun.
>
> Enjoy!
Thanks for the link.
--
Lew
On May 17, 1:37 pm, Frank GOENNINGER <······@googlemail.com> wrote:
[I have taken the liberty of editing the subject header to remove
unproductive and inflammatory ad hominems]
> Lew <·····@lewscanon.com> writes:
> > Frank GOENNINGER wrote:
> >> Well, I was looking for the right tone in my response and came up short
> >> and dry. This sounded about right and appropriate to the unbelievable
> >> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>
> > Trolls. I recommend not feeding them.
>
> Yes, you're right, I know. Sadly these trolls may do damage that is
> beyond our control. Therefore I did post a few replies (as other did,
> too).
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Frank.
> In order to make even this post really valuable to all readers I want to
> once again point everybody to a series of screen casts:
>
> http://lispcast.blip.tv/posts?vomit=archive&nsfw=dc
Please excuse me while I get some Gravol prior to watching these
videos of ASCII being horribly, horribly abused.
> Start at Episode 1 and watch them in full screen mode.
Full-screen mode, forget it. Anything shot with QueasyCam I watch in a
postage-stamp-sized window, even with Gravol. I needed a whole bottle
to get through Blair Witch, two for Cloverfield, and will probably
need five for this bletcherosity.
> SLIME as being a full-fledged IDE.
A full-fledged IDE *inside* the one source code window? Even if this
somehow was achieved, it's an inside-out IDE.
Watching things get turned inside out with pulsing organs everywhere
means doubling the above estimate for the amount of Gravol I'll need.
Please wait for a while until I can obtain some cheaply in bulk
quantities. I go to the local Costco most Saturdays, so I might be
able to watch them on Sunday. We'll see.
From: Seamus MacRae
Subject: Re: OT: Seamus and Series Expansion are trolls, indeed. And: SCREEN CASTS pointer - WAS: Re: macros
Date:
Message-ID: <gv0mjt$60e$3@news.eternal-september.org>
Frank GOENNINGER wrote:
> Lew <·····@lewscanon.com> writes:
>
>> Frank GOENNINGER wrote:
>>> Well, I was looking for the right tone in my response and came up short
>>> and dry. This sounded about right and appropriate to the unbelievable
>>> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>> Trolls. I recommend not feeding them.
>
> Yes, you're right, I know.
But I am not one, nor arrogant.
> In order to make even this post really valuable to all readers I want to
> once again point everybody to a series of screen casts:
>
> http://lispcast.blip.tv/posts?view=archive&nsfw=dc
>
> Start at Episode 1 and watch them in full screen mode. A real good way
> of understanding the power of Common Lisp as a full-fledged languange,
> SLIME as being a full-fledged IDE. And have some fun.
A full-fledged IDE needs to be more, visually, than just a grid of text.
From: Frank GOENNINGER
Subject: Re: OT: Seamus and Series Expansion are trolls, indeed. And: SCREEN CASTS pointer - WAS: Re: macros
Date:
Message-ID: <m2zld8ro05.fsf@goenninger.net>
Seamus MacRae <··········@live.ca.nospam> writes:
> Frank GOENNINGER wrote:
>> Lew <·····@lewscanon.com> writes:
>>
>>> Frank GOENNINGER wrote:
>>>> Well, I was looking for the right tone in my response and came up short
>>>> and dry. This sounded about right and appropriate to the unbelievable
>>>> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>>> Trolls. I recommend not feeding them.
>>
>> Yes, you're right, I know.
>
> But I am not one, nor arrogant.
Yes, Sir, I can see what you want me to see here. With all due respect,
Sir, I will not agree with you on this one, Sir.
>
>> In order to make even this post really valuable to all readers I want to
>> once again point everybody to a series of screen casts:
>>
>> http://lispcast.blip.tv/posts?view=archive&nsfw=dc
>>
>> Start at Episode 1 and watch them in full screen mode. A real good way
>> of understanding the power of Common Lisp as a full-fledged languange,
>> SLIME as being a full-fledged IDE. And have some fun.
>
> A full-fledged IDE needs to be more, visually, than just a grid of text.
Ah - so haven't seen the Lispcasts.
From: Seamus MacRae
Subject: Re: OT: Seamus and Series Expansion are trolls, indeed. And: SCREEN CASTS pointer - WAS: Re: macros
Date:
Message-ID: <gv0tl4$pc9$6@news.eternal-september.org>
Frank GOENNINGER wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Frank GOENNINGER wrote:
>>> Lew <·····@lewscanon.com> writes:
>>>
>>>> Frank GOENNINGER wrote:
>>>>> Well, I was looking for the right tone in my response and came up short
>>>>> and dry. This sounded about right and appropriate to the unbelievable
>>>>> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>>>> Trolls. I recommend not feeding them.
>>> Yes, you're right, I know.
>> But I am not one, nor arrogant.
>
> Yes, Sir, I can see what you want me to see here. With all due respect,
> Sir, I will not agree with you on this one, Sir.
Your behavior is not respectful, though. Least of all your attempts to
misdirect my replies. With the Acrobat Reader post, you even asked me a
question and set it to omit my reply from comp.lang.java.programmer; had
I not fixed that, I would not have ended up seeing a subsequent reply by
you. And here for no logical reason you tried to hijack my reply to
comp.lang.c, where none of this is relevant.
What is the MATTER with you?
>>> SLIME as being a full-fledged IDE. And have some fun.
>> A full-fledged IDE needs to be more, visually, than just a grid of text.
>
> [irrelevancies deleted]
My statement stands. A full-fledged IDE requires things around and to
the sides of the source edit pane.
On May 20, 2:39 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Frank GOENNINGER wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
>
> >> Frank GOENNINGER wrote:
> >>> Lew <·····@lewscanon.com> writes:
>
> >>>> Frank GOENNINGER wrote:
> >>>>> Well, I was looking for the right tone in my response and came up short
> >>>>> and dry. This sounded about right and appropriate to the unbelievable
> >>>>> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
> >>>> Trolls. I recommend not feeding them.
> >>> Yes, you're right, I know.
> >> But I am not one, nor arrogant.
>
> > Yes, Sir, I can see what you want me to see here. With all due respect,
> > Sir, I will not agree with you on this one, Sir.
>
> Your behavior is not respectful, though. Least of all your attempts to
> misdirect my replies. With the Acrobat Reader post, you even asked me a
> question and set it to omit my reply from comp.lang.java.programmer; had
> I not fixed that, I would not have ended up seeing a subsequent reply by
> you. And here for no logical reason you tried to hijack my reply to
> comp.lang.c, where none of this is relevant.
>
> What is the MATTER with you?
>
> >>> SLIME as being a full-fledged IDE. And have some fun.
> >> A full-fledged IDE needs to be more, visually, than just a grid of text.
>
> > [irrelevancies deleted]
>
> My statement stands. A full-fledged IDE requires things around and to
> the sides of the source edit pane.
A generic full-fledged IDE, or just the particular kind of full-
fledged IDE you're accustomed to?
It seems that all your arguments against Emacs reduce to this - that
it hasn't got "things" around the "source edit pane". Interesting... :)
From: Seamus MacRae
Subject: Re: OT: Seamus and Series Expansion are trolls, indeed. And: SCREEN CASTS pointer - WAS: Re: macros
Date:
Message-ID: <gv1f39$ipi$1@news.eternal-september.org>
Alessio Stalla wrote:
> On May 20, 2:39 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> My statement stands. A full-fledged IDE requires things around and to
>> the sides of the source edit pane.
>
> A generic full-fledged IDE, or just the particular kind of full-
> fledged IDE you're accustomed to?
A generic full-fledged IDE. An IDE is more than just the text editor
inside it!
On May 20, 7:36 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 20, 2:39 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> My statement stands. A full-fledged IDE requires things around and to
> >> the sides of the source edit pane.
>
> > A generic full-fledged IDE, or just the particular kind of full-
> > fledged IDE you're accustomed to?
>
> A generic full-fledged IDE. An IDE is more than just the text editor
> inside it!
Right: it's the text editor inside it, plus "things" around it. How
silly of me.
From: Bent C Dalager
Subject: Re: OT: Seamus and Series Expansion are trolls, indeed. And: SCREEN CASTS pointer - WAS: Re: macros
Date:
Message-ID: <slrnh189l7.uk5.bcd@decibel.pvv.ntnu.no>
It appears to me, admittedly after only cursory examination, that this
subthread is quickly devolving into Great SWT Program Redux. I would
suggest that participants can save themselves a lot of time if they
just read the whole "Great SWT Program" discussion on c.l.j.p from
late 2007, rather than try to recreate the thing from scratch.
Cheers,
Bent D
--
Bent Dalager - ···@pvv.org - http://www.pvv.org/~bcd
powered by emacs
From: Seamus MacRae
Subject: Re: OT: Seamus and Series Expansion are trolls, indeed. And: SCREEN CASTS pointer - WAS: Re: macros
Date:
Message-ID: <gv5r4f$tps$1@news.eternal-september.org>
Bent C Dalager wrote:
> It appears to me, admittedly after only cursory examination, that this
> subthread is quickly devolving into Great SWT Program Redux.
What?
*google google*
Oh God, I hope not.
On further inspection, that thread does not seem to be about Lisp. I
guess we're safe then. :)
> Cheers,
> Bent D
Why does that now look familiar?
Oh, wait -- on yet more inspection, it looks like that thread got to be
the way it did because two particularly mulish participants would not
agree to disagree, nor could either sway the other. One of them appears
not to be here but the other one is ...
you.
Oh, shit, there goes the neighborhood.
On May 17, 12:36 pm, Lew <·····@lewscanon.com> wrote:
> Frank GOENNINGER wrote:
> > Well, I was looking for the right tone in my response and came up short
> > and dry. This sounded about right and appropriate to the unbelievable
> > arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>
> Trolls. I recommend not feeding them.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Frank.
On May 17, 12:36 pm, Lew <·····@lewscanon.com> wrote:
> Frank GOENNINGER wrote:
> > Well, I was looking for the right tone in my response and came up short
> > and dry. This sounded about right and appropriate to the unbelievable
> > arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>
> Trolls. I recommend not feeding them.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Frank.
(Reposted after original was silently redirected to hide my response
from comp.lang.java.programmer. "Lew", your perfidy knows no bounds.)
Lew wrote:
> Frank GOENNINGER wrote:
>> Well, I was looking for the right tone in my response and came up short
>> and dry. This sounded about right and appropriate to the unbelievable
>> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
>
> Trolls. I recommend not feeding them.
But I am not one. Nor am I arrogant.
Frank GOENNINGER wrote:
> The one thing I am still working on is to make up a good picture
> explanining the concept of an Outset...
I am not sure why outset is tricky, unless it is the conceptual overlap
with the inset some widgets have. Or maybe it is this: outset has no
meaning other than for (a) containers (b) whose only interest in size is
being just big enough to cover all their kids. And then outset is only
added to the max LR and lb of any kind and subtracted from the min
ll/lt. ie, These containers sizes are determinded by the offset and size
of all their kids, such that they are just big enough (plus an "outset"
margin). Again, you cannot draw the diagram unless you have kids here
and there and then draw a rectangle big enough plus otset to cover them.
kt
Kenneth Tilton <·········@gmail.com> writes:
> Frank GOENNINGER wrote:
>> The one thing I am still working on is to make up a good picture
>> explanining the concept of an Outset...
>
> I am not sure why outset is tricky,
Not really tricky - just one thing to write a few lines of code versus a
diagram showing the concept and the effects on paper. Just as you say:
> unless it is the conceptual
> overlap with the inset some widgets have. Or maybe it is this: outset
> has no meaning other than for (a) containers (b) whose only interest
> in size is being just big enough to cover all their kids.
Which could be done without an "outset" parameter - to my understanding
it's just like the Tcl/Tk's padding parameter: How much space is to be
kept between two widgets as a minimum.
> And then
> outset is only added to the max LR and lb of any kind and subtracted
> from the min ll/lt. ie, These containers sizes are determinded by the
> offset and size of all their kids, such that they are just big enough
> (plus an "outset" margin). Again, you cannot draw the diagram unless
> you have kids here and there and then draw a rectangle big enough plus
> otset to cover them.
>
> kt
Yep. So the diagram will have several kids within a parent control and
then there's the outset disctance to be shown where it is to be
applied. As you already said elsewhere the outset could also be taken to
be the same as the inset values. Hence my thinking: Are there use cases
where one might want to have different inset-interpreted-as-outset
values and real outset values. Or is it just a matter of having the
outset as a slot and default the outset rules to be the same as the
inset values. If a (Cello code) user wants to do something different
it's then only a matter of specifying different Cells rules for the
outset slot values.
Cheers
Frank
Frank GOENNINGER wrote:
> Kenneth Tilton <·········@gmail.com> writes:
>
>> Frank GOENNINGER wrote:
>>> The one thing I am still working on is to make up a good picture
>>> explanining the concept of an Outset...
>> I am not sure why outset is tricky,
>
> Not really tricky - just one thing to write a few lines of code versus a
> diagram showing the concept and the effects on paper. Just as you say:
>
>> unless it is the conceptual
>> overlap with the inset some widgets have. Or maybe it is this: outset
>> has no meaning other than for (a) containers (b) whose only interest
>> in size is being just big enough to cover all their kids.
>
> Which could be done without an "outset" parameter - to my understanding
> it's just like the Tcl/Tk's padding parameter: How much space is to be
> kept between two widgets as a minimum.
>
>> And then
>> outset is only added to the max LR and lb of any kind and subtracted
>> from the min ll/lt. ie, These containers sizes are determinded by the
>> offset and size of all their kids, such that they are just big enough
>> (plus an "outset" margin). Again, you cannot draw the diagram unless
>> you have kids here and there and then draw a rectangle big enough plus
>> otset to cover them.
>>
>> kt
>
> Yep. So the diagram will have several kids within a parent control and
> then there's the outset disctance to be shown where it is to be
> applied. As you already said elsewhere the outset could also be taken to
> be the same as the inset values. Hence my thinking: Are there use cases
> where one might want to have different inset-interpreted-as-outset
> values and real outset values. Or is it just a matter of having the
> outset as a slot and default the outset rules to be the same as the
> inset values. If a (Cello code) user wants to do something different
> it's then only a matter of specifying different Cells rules for the
> outset slot values.
This is all Lisp stuff, correct?
--
Lew
Lew wrote:
> Frank GOENNINGER wrote:
>> Kenneth Tilton <·········@gmail.com> writes:
>>
>>> Frank GOENNINGER wrote:
>>>> The one thing I am still working on is to make up a good picture
>>>> explanining the concept of an Outset...
>>> I am not sure why outset is tricky,
>>
>> Not really tricky - just one thing to write a few lines of code versus a
>> diagram showing the concept and the effects on paper. Just as you say:
>>
>>> unless it is the conceptual
>>> overlap with the inset some widgets have. Or maybe it is this: outset
>>> has no meaning other than for (a) containers (b) whose only interest
>>> in size is being just big enough to cover all their kids.
>>
>> Which could be done without an "outset" parameter - to my understanding
>> it's just like the Tcl/Tk's padding parameter: How much space is to be
>> kept between two widgets as a minimum.
>>> And then
>>> outset is only added to the max LR and lb of any kind and subtracted
>>> from the min ll/lt. ie, These containers sizes are determinded by the
>>> offset and size of all their kids, such that they are just big enough
>>> (plus an "outset" margin). Again, you cannot draw the diagram unless
>>> you have kids here and there and then draw a rectangle big enough plus
>>> otset to cover them.
>>>
>>> kt
>>
>> Yep. So the diagram will have several kids within a parent control and
>> then there's the outset disctance to be shown where it is to be
>> applied. As you already said elsewhere the outset could also be taken to
>> be the same as the inset values. Hence my thinking: Are there use cases
>> where one might want to have different inset-interpreted-as-outset
>> values and real outset values. Or is it just a matter of having the
>> outset as a slot and default the outset rules to be the same as the
>> inset values. If a (Cello code) user wants to do something different
>> it's then only a matter of specifying different Cells rules for the
>> outset slot values.
>
> This is all Lisp stuff, correct?
>
I was hoping someone would be daft enough to try to moderate this
thread... Thanks!
kt
Frank GOENNINGER wrote:
> Kenneth Tilton <·········@gmail.com> writes:
>
>> Frank GOENNINGER wrote:
>>> The one thing I am still working on is to make up a good picture
>>> explanining the concept of an Outset...
>> I am not sure why outset is tricky,
>
> Not really tricky - just one thing to write a few lines of code versus a
> diagram showing the concept and the effects on paper. Just as you say:
>
>> unless it is the conceptual
>> overlap with the inset some widgets have. Or maybe it is this: outset
>> has no meaning other than for (a) containers (b) whose only interest
>> in size is being just big enough to cover all their kids.
>
> Which could be done without an "outset" parameter -
Nope. Unless you mean calling it "inset". :)
Something I left unanswered: I have been thinking and I cannot think of
a case where inset and outset are needed at the same time and the
semantics in the end are the same so they can prolly be collapsed into
one parameter.
> to my understanding
> it's just like the Tcl/Tk's padding parameter: How much space is to be
> kept between two widgets as a minimum.
I think that is just like the spacing parameter in Cello, not outset.
Outset is applied to the min/max of all the child bounds, not each
individually (or between pairs).
kt
Frank GOENNINGER wrote:
> Kenneth Tilton <·········@gmail.com> writes:
>
>> Frank GOENNINGER wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>
>>>> Kenneth Tilton wrote:
>
>>>>> Say this: Lisp programmers have programming jobs meaning they know
>>>>> Java or Python or Ruby or whatever so there is prolly not much
>>>>> delusion involved. It is more of an informed comparison. Yes, the
>>>>> bad news is that we are also better at those languages than
>>>>> you. Sorry for the comedown.
>>>> Nobody makes an arrogant statement like that on usenet without getting
>>>> his nose tweaked.
>>>>
>>>> Nobody.
>>> PUWAHAHAHAHA - Puwaaahahhhahaaahahaaa - Good grief, man, you're talking
>>> to Kenny Tilton.
>> Damn. I was looking forward to that, sounded kinda kinky.
>
> Well, I was looking for the right tone in my response and came up short
> and dry. This sounded about right and appropriate to the unbelievable
> arrogance of Seamus and of Series Idiocy, ah, Series Expansion.
What arrogance? The arrogance on display was "we are also better at
those languages than you. Sorry for the comedown." and a quick Google
search will confirm that Kenneth wrote it, not I nor Series Expansion.
Note also that it is not I that has sunk to the level of flinging around
such astoundingly erudite and adult forms of debate as "Series Idiocy,
ah, Series Expansion" and similar childish insults. I've also not seen
Series Expansion do that much, aside from the odd "dirtbag" or
"fuckhead" or similar every fiftieth post or so.
If an objective judge were to create a ranked list of participants here
from the most to the least mouthfoaming it would resemble:
Lew
You
Pascal and one or two others
Kenneth
Several assorted minor flamers, most from the Lisp side
Series Expansion
one or two random people
me
one or two random people
based on the posts up to this date.
>> Did you grok the coordinate geometry yet? One guy working for me
>> characterized it as a system only Kenny could
>> understand. Unfortunately he was gone before I discovered the prior
>> example of a little thing called OpenGL.
>>
>> kt
>
> As you know I am fond of pictures and diagrams.
Strange to see in a confessed emacs lover. One expects an emacs lover to
be very word-focused rather than image-focused, or verbally rather than
visually dominant, or some such, but the reverse for someone "fond of
pictures and diagrams", who you'd therefore expect to prefer tools more
like NetBeans.
Frank GOENNINGER wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Kenneth Tilton wrote:
>>> Lew wrote:
>>>> Lew wrote:
>>>>>> The main difference between Lisp adherents and Java adherents is
>>>>>> that Lisp adherents spend their arrogance making a religion out
>>>>>> of defending Lisp against all comers, and Java adherents
>>>>>> religiously criticize Java for its shortcomings.
>>>> Kenneth Tilton wrote:
>>>>
>>>>> Suggesting that the main difference between Lisp and Java is that
>>>>> Lisp is unassailably great and Java is full of shortcomings.
>>>>
>>>> Say rather that Lisp programmers drink the Kool-Aid and Java
>>>> programmers are pragmatic and thoughtful.
>>> Say this: Lisp programmers have programming jobs meaning they know
>>> Java or Python or Ruby or whatever so there is prolly not much
>>> delusion involved. It is more of an informed comparison. Yes, the
>>> bad news is that we are also better at those languages than
>>> you. Sorry for the comedown.
>> Nobody makes an arrogant statement like that on usenet without getting
>> his nose tweaked.
>>
>> Nobody.
>
> PUWAHAHAHAHA - Puwaaahahhhahaaahahaaa - Good grief, man, you're talking
> to Kenny Tilton.
Yet he did indeed get his nose tweaked. Repeatedly.
>>>>> I have long thought that Java might be the only language no one
>>>>> ever loved, including even its creators. In case you are
>>>>> wondering, that is not a good sign.
>>>> I was not wondering, and you have not established that goggle-eyed
>>>> adoration is superior.
>>> I took a different path
>> That much is certain. (I think it might be that rather well-known one
>> that's paved with good intentions.)
>
> You are so sweet in your childish innocence.
Blow it out your ethernet jack.
>>> I pointed out that we Lisp Gods have Perfect Knowledge of crud
>> That is arguably correct also, though Perfect Knowledge is ordinarily
>> considered to be the sole preserve of God. Oh, wait, did you not also
>> explicitly say you *were* God? I believe you did.
>
> Well, man, I can tell you, he is one of the Lisp Gods, really.
OK, then let's see him zap that clown Lew with a large bolt of lightning
up the ass.
Go ahead.
Come on!
...
Thought not.
Moving on ...
> If he says something then you should *listen* - er, read. I have learned
> to read twice (at least) when one of the Language Gods (not just the
> Lisp Gods, you know) is sending us their wisdom.
The last "pearls of wisdom" I read from him was an explicit denial that
he'd written some quoted text I'd attributed to him.
My response was to post the message-ID, Google Groups URL, and a larger
chunk of quoted text solidly cementing the case for him having written
the text he denied having written.
This is the sort of "wisdom" typically displayed during interrogation by
suspects on CSI, right before the forensics come back and nail their
asses to the wall.
I think I'll pass, thanks. :)
> Or, do you mean ... are you one of the Java Gods ?
No. I would never be so presumptuous or arrogant as to accept, let alone
grab for, such a title. I'm just a Java programmer.
Pascal J. Bourguignon wrote:
> Series Expansion <·······@gmail.com> writes:
>> On May 15, 3:35 pm, gugamilare <··········@gmail.com> wrote:
>> >
>>> The CL package system will solve the name collision with no harm done.
>>
>> I just explained why the package system won't. Adding new classes in
>> their own packages? No problem, the package system can distinguish
>> foo.String from bar.String. Adding new methods to an existing class,
>> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
>> foo.String.doIt()? They have the same method name, are methods of
>> classes with the same name, and the classes are in the same package.
>
> Why don't you believe it when you're told you don't understand something?
> Perhaps it's time you learn serriously Common Lisp.
> You may start with this introduction: http://www.gigamonkeys.com/book/
>
> In the Common Lisp Object System (CLOS), methods are not attached to a
> class, but to a generic function, and generic functions, like any
> other, may be named by any symbol. It could be a symbol interned in
> the same package as the symbol naming the class of one of the
> parameter of one of the method of the generic function or in another
> package or even in no package at all.
>
> Concerning the names, it's like if having a class foo.String, you
> could define a java method foo.doIt and another java method bar.doIt.
>
> (new foo.MyString).(foo.doIt)() would no call the same method as
> (new foo.MyString).(bar.doIt)().
Isn't this exactly the problem Series Expansion foresaw? Lots of extra
namespace qualifiers dangling all over the place and virtually
unreadable code.
>> As far as the compiler is concerned, they are the same. The package
>> system cannot distinguish them unless we add another layer of
>> namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
>> and foo.String.quux.doIt() instead of just foo.String.doIt() as the
>> fully-qualified names. And now we're deep in migraine-headache
>> territory, without oar or compass...
>
> Right, non-lisp programming languages are migraine-headache territory.
> We never said otherwise.
It was YOUR suggestion, above, to qualify both the nouns and the verbs,
separately.
>> Of course, the best way to avoid multiple incompatible libraries is to
>> have commonly desired functionality built into the standard library.
>> And then letting third parties create (non-private, at least) methods
>> in your classes is unnecessary.
>
> No, the best way to avoid multiple incompatible libraries is to use
> the package system of Lisp.
That means failing to avoid the two-orthogonal-sets-of-namespaces
headache though.
On May 15, 9:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pascal J. Bourguignon wrote:
[...]
> > Concerning the names, it's like if having a class foo.String, you
> > could define a java method foo.doIt and another java method bar.doIt.
> > (new foo.MyString).(foo.doIt)() would no call the same method as
> > (new foo.MyString).(bar.doIt)().
> Isn't this exactly the problem Series Expansion foresaw? Lots of extra
> namespace qualifiers dangling all over the place and virtually
> unreadable code.
In practice, no. You would import what you want into the namespace
you're working in a way that would allow you to avoid most clashes and
thus most of the need for qualifiers. So you could do (translated into
more CLish language, because my Java knowledge is quite limited):
(defpackage #:my-package
(:use #:cl #:foo))
(do-it (make-instance 'my-string))
(bar:do-it (make-instance 'my-string))
Only one qualifier is necessary in this example. DEFPACKAGE provides
very fine-grained control if you need it, should you decide, for
instance, that you really are going to use BAR:DO-IT a lot more than
FOO:DO-IT and thus want to be able to use BAR:DO-IT unqualified
instead.
Cheers,
Pillsy
Pillsy wrote:
> On May 15, 9:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pascal J. Bourguignon wrote:
> [...]
>>> Concerning the names, it's like if having a class foo.String, you
>>> could define a java method foo.doIt and another java method bar.doIt.
>
>>> (new foo.MyString).(foo.doIt)() would no call the same method as
>>> (new foo.MyString).(bar.doIt)().
>
>> Isn't this exactly the problem Series Expansion foresaw? Lots of extra
>> namespace qualifiers dangling all over the place and virtually
>> unreadable code.
>
> In practice, no.
Subject to some qualification, no doubt.
> You would import what you want into the namespace
> you're working in a way that would allow you to avoid most clashes and
> thus most of the need for qualifiers. So you could do (translated into
> more CLish language, because my Java knowledge is quite limited):
>
> (defpackage #:my-package
> (:use #:cl #:foo))
>
> (do-it (make-instance 'my-string))
> (bar:do-it (make-instance 'my-string))
>
> Only one qualifier is necessary in this example. DEFPACKAGE provides
> very fine-grained control if you need it, should you decide, for
> instance, that you really are going to use BAR:DO-IT a lot more than
> FOO:DO-IT and thus want to be able to use BAR:DO-IT unqualified
> instead.
Ah, okay. I see; the qualification is evidently "must be rocket
scientist, or have economy-size bottle of Motrin". :)
Java lets you get by with a plain old
import foo;
by contrast. No mess, no fuss, and none of that shift-3 shit. ;)
On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > On May 15, 9:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
[...]
> >> Isn't this exactly the problem Series Expansion foresaw? Lots of extra
> >> namespace qualifiers dangling all over the place and virtually
> >> unreadable code.
> > In practice, no.
> Subject to some qualification, no doubt.
Nope, not really.
> > You would import what you want into the namespace
> > you're working in a way that would allow you to avoid most clashes and
> > thus most of the need for qualifiers. So you could do (translated into
> > more CLish language, because my Java knowledge is quite limited):
> > (defpackage #:my-package
> > (:use #:cl #:foo))
> > (do-it (make-instance 'my-string))
> > (bar:do-it (make-instance 'my-string))
> > Only one qualifier is necessary in this example. DEFPACKAGE provides
> > very fine-grained control if you need it, should you decide, for
> > instance, that you really are going to use BAR:DO-IT a lot more than
> > FOO:DO-IT and thus want to be able to use BAR:DO-IT unqualified
> > instead.
> Ah, okay. I see; the qualification is evidently "must be rocket
> scientist, or have economy-size bottle of Motrin". :)
Eh, in the general case you just use the packages you want to use and
that's that, but if you want more flexibility it's there.
> Java lets you get by with a plain old
> import foo;
> by contrast.
I'm missing the part where that's conspicuously easier than the Lisp
option.
> No mess, no fuss, and none of that shift-3 shit. ;)
The "#:" is optional, actually.
Cheers,
Pillsy
Pillsy wrote:
> On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> On May 15, 9:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Isn't this exactly the problem Series Expansion foresaw? Lots of extra
>>>> namespace qualifiers dangling all over the place and virtually
>>>> unreadable code.
>
>>> In practice, no.
>
>> Subject to some qualification, no doubt.
>
> Nope, not really.
Pollyanna much?
>>> You would import what you want into the namespace
>>> you're working in a way that would allow you to avoid most clashes and
>>> thus most of the need for qualifiers. So you could do (translated into
>>> more CLish language, because my Java knowledge is quite limited):
>
>>> (defpackage #:my-package
>>> (:use #:cl #:foo))
>
>>> (do-it (make-instance 'my-string))
>>> (bar:do-it (make-instance 'my-string))
>
>>> Only one qualifier is necessary in this example. DEFPACKAGE provides
>>> very fine-grained control if you need it, should you decide, for
>>> instance, that you really are going to use BAR:DO-IT a lot more than
>>> FOO:DO-IT and thus want to be able to use BAR:DO-IT unqualified
>>> instead.
>
>> Ah, okay. I see; the qualification is evidently "must be rocket
>> scientist, or have economy-size bottle of Motrin". :)
>
> Eh, in the general case you just use the packages you want to use and
> that's that
Yes, and meanwhile at Mission Control, you just trigger the final
pre-orbital burn of the hypergolic propellants at max-Q and that's that.
Remind me NOT to ever trust you with a multi-million-dollar satellite
payload. :)
>> Java lets you get by with a plain old
>
>> import foo;
>
>> by contrast.
>
> I'm missing the part where that's conspicuously easier than the Lisp
> option.
Well, let's see...
(defpackage #:my-package
(:use #:cl #:foo))
Two lines. 42 characters (not including internal linefeed and
indentation). Nesting depth of brackets: 2.
import foo;
One line. 11 characters. Nesting depth of brackets: zero.
On May 16, 9:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Pillsy wrote:
> >>> On May 15, 9:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Isn't this exactly the problem Series Expansion foresaw? Lots of extra
> >>>> namespace qualifiers dangling all over the place and virtually
> >>>> unreadable code.
>
> >>> In practice, no.
>
> >> Subject to some qualification, no doubt.
>
> > Nope, not really.
>
> Pollyanna much?
>
>
>
> >>> You would import what you want into the namespace
> >>> you're working in a way that would allow you to avoid most clashes and
> >>> thus most of the need for qualifiers. So you could do (translated into
> >>> more CLish language, because my Java knowledge is quite limited):
>
> >>> (defpackage #:my-package
> >>> (:use #:cl #:foo))
>
> >>> (do-it (make-instance 'my-string))
> >>> (bar:do-it (make-instance 'my-string))
>
> >>> Only one qualifier is necessary in this example. DEFPACKAGE provides
> >>> very fine-grained control if you need it, should you decide, for
> >>> instance, that you really are going to use BAR:DO-IT a lot more than
> >>> FOO:DO-IT and thus want to be able to use BAR:DO-IT unqualified
> >>> instead.
>
> >> Ah, okay. I see; the qualification is evidently "must be rocket
> >> scientist, or have economy-size bottle of Motrin". :)
>
> > Eh, in the general case you just use the packages you want to use and
> > that's that
>
> Yes, and meanwhile at Mission Control, you just trigger the final
> pre-orbital burn of the hypergolic propellants at max-Q and that's that.
>
> Remind me NOT to ever trust you with a multi-million-dollar satellite
> payload. :)
>
> >> Java lets you get by with a plain old
>
> >> import foo;
>
> >> by contrast.
>
> > I'm missing the part where that's conspicuously easier than the Lisp
> > option.
>
> Well, let's see...
>
> (defpackage #:my-package
> (:use #:cl #:foo))
>
> Two lines. 42 characters (not including internal linefeed and
> indentation). Nesting depth of brackets: 2.
>
> import foo;
>
> One line. 11 characters. Nesting depth of brackets: zero.
Hmm, not really. The Java equivalent of that defpackage form would be:
package my.package;
import cl.*;
import foo.*;
repeated in every file that is in package "my.package" and uses
packages "cl" and "foo", while in Lisp you define the package once and
then you use it with
(in-package :my-package)
and that gives you all the external symbols in my-package, cl and foo
accessible without qualifiers.
A.
On May 16, 12:41 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 16, 9:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
>
>
> > Pillsy wrote:
> > > On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > >> Pillsy wrote:
> > >>> On May 15, 9:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > >>>> Isn't this exactly the problem Series Expansion foresaw? Lots of extra
> > >>>> namespace qualifiers dangling all over the place and virtually
> > >>>> unreadable code.
>
> > >>> In practice, no.
>
> > >> Subject to some qualification, no doubt.
>
> > > Nope, not really.
>
> > Pollyanna much?
>
> > >>> You would import what you want into the namespace
> > >>> you're working in a way that would allow you to avoid most clashes and
> > >>> thus most of the need for qualifiers. So you could do (translated into
> > >>> more CLish language, because my Java knowledge is quite limited):
>
> > >>> (defpackage #:my-package
> > >>> (:use #:cl #:foo))
>
> > >>> (do-it (make-instance 'my-string))
> > >>> (bar:do-it (make-instance 'my-string))
>
> > >>> Only one qualifier is necessary in this example. DEFPACKAGE provides
> > >>> very fine-grained control if you need it, should you decide, for
> > >>> instance, that you really are going to use BAR:DO-IT a lot more than
> > >>> FOO:DO-IT and thus want to be able to use BAR:DO-IT unqualified
> > >>> instead.
>
> > >> Ah, okay. I see; the qualification is evidently "must be rocket
> > >> scientist, or have economy-size bottle of Motrin". :)
>
> > > Eh, in the general case you just use the packages you want to use and
> > > that's that
>
> > Yes, and meanwhile at Mission Control, you just trigger the final
> > pre-orbital burn of the hypergolic propellants at max-Q and that's that.
>
> > Remind me NOT to ever trust you with a multi-million-dollar satellite
> > payload. :)
>
> > >> Java lets you get by with a plain old
>
> > >> import foo;
>
> > >> by contrast.
>
> > > I'm missing the part where that's conspicuously easier than the Lisp
> > > option.
>
> > Well, let's see...
>
> > (defpackage #:my-package
> > (:use #:cl #:foo))
>
> > Two lines. 42 characters (not including internal linefeed and
> > indentation). Nesting depth of brackets: 2.
>
> > import foo;
>
> > One line. 11 characters. Nesting depth of brackets: zero.
>
> Hmm, not really. The Java equivalent of that defpackage form would be:
>
> package my.package;
> import cl.*;
> import foo.*;
>
> repeated in every file that is in package "my.package" and uses
> packages "cl" and "foo", while in Lisp you define the package once and
> then you use it with
>
> (in-package :my-package)
>
> and that gives you all the external symbols in my-package, cl and foo
> accessible without qualifiers.
Welll... In Java (but not in C++) the 'import' at the beginning also
instruct javac where to look, via the classpath, for the other
packages/classes.
It is a very nice thing of Java. BTW. If you scrape enough of all
the layers of Eclipse, Netbeans and MSVS, you always get down to the
equivalent of 'javac' or 'cl' (meaming MS C/C++ compiler/linker).
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
Alessio Stalla wrote:
> On May 16, 9:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Pillsy wrote:
>>>>> On May 15, 9:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> Isn't this exactly the problem Series Expansion foresaw? Lots of extra
>>>>>> namespace qualifiers dangling all over the place and virtually
>>>>>> unreadable code.
>>>>> In practice, no.
>>>> Subject to some qualification, no doubt.
>>> Nope, not really.
>> Pollyanna much?
>>
>>
>>
>>>>> You would import what you want into the namespace
>>>>> you're working in a way that would allow you to avoid most clashes and
>>>>> thus most of the need for qualifiers. So you could do (translated into
>>>>> more CLish language, because my Java knowledge is quite limited):
>>>>> (defpackage #:my-package
>>>>> (:use #:cl #:foo))
>>>>> (do-it (make-instance 'my-string))
>>>>> (bar:do-it (make-instance 'my-string))
>>>>> Only one qualifier is necessary in this example. DEFPACKAGE provides
>>>>> very fine-grained control if you need it, should you decide, for
>>>>> instance, that you really are going to use BAR:DO-IT a lot more than
>>>>> FOO:DO-IT and thus want to be able to use BAR:DO-IT unqualified
>>>>> instead.
>>>> Ah, okay. I see; the qualification is evidently "must be rocket
>>>> scientist, or have economy-size bottle of Motrin". :)
>>> Eh, in the general case you just use the packages you want to use and
>>> that's that
>> Yes, and meanwhile at Mission Control, you just trigger the final
>> pre-orbital burn of the hypergolic propellants at max-Q and that's that.
>>
>> Remind me NOT to ever trust you with a multi-million-dollar satellite
>> payload. :)
>>
>>>> Java lets you get by with a plain old
>>>> import foo;
>>>> by contrast.
>>> I'm missing the part where that's conspicuously easier than the Lisp
>>> option.
>> Well, let's see...
>>
>> (defpackage #:my-package
>> (:use #:cl #:foo))
>>
>> Two lines. 42 characters (not including internal linefeed and
>> indentation). Nesting depth of brackets: 2.
>>
>> import foo;
>>
>> One line. 11 characters. Nesting depth of brackets: zero.
>
> Hmm, not really.
Yes really, unless you're going to change your claim.
>>>>> Java lets you get by with a plain old
>>>>> import foo;
>>>> I'm missing the part where that's conspicuously easier than the Lisp
>>>> option.
>>> Well, let's see...
>>>
>>> (defpackage #:my-package
>>> (:use #:cl #:foo))
seems to me to imply that the code at the bottom is the Lisp analogue of
"import foo;". Are you saying that this was an error, perhaps even a lie?
> The Java equivalent of that defpackage form would be:
>
> package my.package;
> import cl.*;
> import foo.*;
>
> repeated in every file that is in package "my.package" and uses
> packages "cl" and "foo"
Apparently you are saying that.
Arguing with a side that contradicts itself and changes the "rules"
every time it's pressed quickly gets tiresome.
I may not bother much longer.
On May 20, 12:43 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Alessio Stalla wrote:
> > On May 16, 9:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Pillsy wrote:
> >>> On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Pillsy wrote:
> >>>>> On May 15, 9:37 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>>>> Isn't this exactly the problem Series Expansion foresaw? Lots of extra
> >>>>>> namespace qualifiers dangling all over the place and virtually
> >>>>>> unreadable code.
> >>>>> In practice, no.
> >>>> Subject to some qualification, no doubt.
> >>> Nope, not really.
> >> Pollyanna much?
>
> >>>>> You would import what you want into the namespace
> >>>>> you're working in a way that would allow you to avoid most clashes and
> >>>>> thus most of the need for qualifiers. So you could do (translated into
> >>>>> more CLish language, because my Java knowledge is quite limited):
> >>>>> (defpackage #:my-package
> >>>>> (:use #:cl #:foo))
> >>>>> (do-it (make-instance 'my-string))
> >>>>> (bar:do-it (make-instance 'my-string))
> >>>>> Only one qualifier is necessary in this example. DEFPACKAGE provides
> >>>>> very fine-grained control if you need it, should you decide, for
> >>>>> instance, that you really are going to use BAR:DO-IT a lot more than
> >>>>> FOO:DO-IT and thus want to be able to use BAR:DO-IT unqualified
> >>>>> instead.
> >>>> Ah, okay. I see; the qualification is evidently "must be rocket
> >>>> scientist, or have economy-size bottle of Motrin". :)
> >>> Eh, in the general case you just use the packages you want to use and
> >>> that's that
> >> Yes, and meanwhile at Mission Control, you just trigger the final
> >> pre-orbital burn of the hypergolic propellants at max-Q and that's that.
>
> >> Remind me NOT to ever trust you with a multi-million-dollar satellite
> >> payload. :)
>
> >>>> Java lets you get by with a plain old
> >>>> import foo;
> >>>> by contrast.
> >>> I'm missing the part where that's conspicuously easier than the Lisp
> >>> option.
> >> Well, let's see...
>
> >> (defpackage #:my-package
> >> (:use #:cl #:foo))
>
> >> Two lines. 42 characters (not including internal linefeed and
> >> indentation). Nesting depth of brackets: 2.
>
> >> import foo;
>
> >> One line. 11 characters. Nesting depth of brackets: zero.
>
> > Hmm, not really.
>
> Yes really, unless you're going to change your claim.
>
> >>>>> Java lets you get by with a plain old
> >>>>> import foo;
> >>>> I'm missing the part where that's conspicuously easier than the Lisp
> >>>> option.
> >>> Well, let's see...
>
> >>> (defpackage #:my-package
> >>> (:use #:cl #:foo))
>
> seems to me to imply that the code at the bottom is the Lisp analogue of
> "import foo;". Are you saying that this was an error, perhaps even a lie?
>
> > The Java equivalent of that defpackage form would be:
>
> > package my.package;
> > import cl.*;
> > import foo.*;
>
> > repeated in every file that is in package "my.package" and uses
> > packages "cl" and "foo"
>
> Apparently you are saying that.
Yes, apparently I'm saying that. So? :)
> Arguing with a side that contradicts itself and changes the "rules"
> every time it's pressed quickly gets tiresome.
That's because the concepts are similar enough between Lisp and Java,
yet not completely equal.
Let me explain:
package myPackage;
in Java does 2 things:
1. declares that package myPackage exists
2. declares that the code in the current file is to be considered
inside package myPackage.
import foo.*;
in Java means: the symbols in package foo can be accessed unqualified.
(defpackage :my-package
(:use #:cl #:foo))
in Lisp does 2 things:
1. declares package my-package exists
2. declares that all symbols from packages :cl and :foo are also in
package my-package (and thus can be accessed unqualified when code is
read in package my-package)
(in-package :my-package)
in Lisp means: the symbols read from now on in this file will be read
in package my-package.
As you see, the place where you say which symbols from other packages
are unqualified is different between Lisp and Java, and this probably
is where confusion arises.
hth,
Alessio
Alessio Stalla wrote:
> On May 20, 12:43 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Alessio Stalla wrote:
>>> On May 16, 9:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Pillsy wrote:
>>>>> On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> Pillsy wrote:
>>>>>>> Java lets you get by with a plain old
>>>>>>> import foo;
>>>>>> I'm missing the part where that's conspicuously easier than the Lisp
>>>>>> option.
>>>>> Well, let's see...
>>>>> (defpackage #:my-package
>>>>> (:use #:cl #:foo))
>> seems to me to imply that the code at the bottom is the Lisp analogue of
>> "import foo;". Are you saying that this was an error, perhaps even a lie?
>>
>>> The Java equivalent of that defpackage form would be:
>>> package my.package;
>>> import cl.*;
>>> import foo.*;
>>> repeated in every file that is in package "my.package" and uses
>>> packages "cl" and "foo"
>> Apparently you are saying that.
>
> Yes, apparently I'm saying that. So? :)
So, you're contradicting Pillsy. Pillsy implied that that code only does
the equivalent of "import foo.*".
>> Arguing with a side that contradicts itself and changes the "rules"
>> every time it's pressed quickly gets tiresome.
>
> That's because the concepts are similar enough between Lisp and Java,
> yet not completely equal.
No, it's two different Lisp users contradicting each other about Lisp
here that I'm pointing out, not a Lisp and a Java user disagreeing.
(Though we've had lots of that, too.)
> (defpackage :my-package
> (:use #:cl #:foo))
>
> in Lisp does 2 things:
>
> 1. declares package my-package exists
> 2. declares that all symbols from packages :cl and :foo are also in
> package my-package (and thus can be accessed unqualified when code is
> read in package my-package)
How ugly. Imports shouldn't genuinely change package membership, just
visibility. Now people can use my-package:sym when sym is really foo:sym!
Furthermore, the explicit :use #:cl must be something like having an
explicit import java.lang.*; in Java. Java does that automatically so
you don't have to. That's one more point in favor of Java, albeit a very
minor one.
On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> No, it's two different Lisp users contradicting each other about Lisp
> here that I'm pointing out, not a Lisp and a Java user disagreeing.
> (Though we've had lots of that, too.)
That is the problem with relying on a usenet thread for your
information about Lisp. If you are interested in understanding Lisp,
you would be much better served referencing a Lisp text and the Common
Lisp Hyperspec.
> > (defpackage :my-package
> > (:use #:cl #:foo))
>
> > in Lisp does 2 things:
>
> > 1. declares package my-package exists
> > 2. declares that all symbols from packages :cl and :foo are also in
> > package my-package (and thus can be accessed unqualified when code is
> > read in package my-package)
>
> How ugly. Imports shouldn't genuinely change package membership, just
> visibility. Now people can use my-package:sym when sym is really foo:sym!
Imports don't genuinely change package membership. People will not be
able to use my-package:sym if sym is really foo:sym.
> Furthermore, the explicit :use #:cl must be something like having an
> explicit import java.lang.*; in Java. Java does that automatically so
> you don't have to. That's one more point in favor of Java, albeit a very
> minor one.
Having the option of not using the external symbols of the COMMON-LISP
package is particularly useful when you are implementing a DSL or even
creating a new language on top of Common Lisp. This is neither a point
in favor of or against Common Lisp, it is merely a feature to
facilitate certain types of programming.
Hope that helps,
Tom
Thomas M. Hermann wrote:
> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> No, it's two different Lisp users contradicting each other about Lisp
>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>> (Though we've had lots of that, too.)
>
> That is the problem with relying on a usenet thread for your
> information about Lisp. If you are interested in understanding Lisp,
> you would be much better served referencing a Lisp text
Don't have one, sorry.
My point stands: if you guys can't be arsed to get your act together and
present your case MUCH better, you can hardly complain if you find you
don't manage to acquire many new converts or if you find your various
errors or disagreements being nitpicked by people you'd previously flamed.
>>> (defpackage :my-package
>>> (:use #:cl #:foo))
>>> in Lisp does 2 things:
>>> 1. declares package my-package exists
>>> 2. declares that all symbols from packages :cl and :foo are also in
>>> package my-package (and thus can be accessed unqualified when code is
>>> read in package my-package)
>> How ugly. Imports shouldn't genuinely change package membership, just
>> visibility. Now people can use my-package:sym when sym is really foo:sym!
>
> Imports don't genuinely change package membership.
But Alessio said "declares that all symbols from packages x and y are
also in package my-package" ...
Sigh. See above.
On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Thomas M. Hermann wrote:
> > On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> No, it's two different Lisp users contradicting each other about Lisp
> >> here that I'm pointing out, not a Lisp and a Java user disagreeing.
> >> (Though we've had lots of that, too.)
>
> > That is the problem with relying on a usenet thread for your
> > information about Lisp. If you are interested in understanding Lisp,
> > you would be much better served referencing a Lisp text
>
> Don't have one, sorry.
That paragraph does not assign anything to you, so there is nothing
for you to have or not have. It states the problem with relying on
information about a programming language from posts on usenet is that
the information has no assurance of correctness. To avoid this
problem, you should refer to the appropriate texts documenting the
programming language.
> My point stands: if you guys can't be arsed to get your act together and
> present your case MUCH better, you can hardly complain if you find you
> don't manage to acquire many new converts or if you find your various
> errors or disagreements being nitpicked by people you'd previously flamed.
There is no case to present. I am not trying to convert anyone. I'm
not complaining about anything. I only wish to provide the necessary
information back by the appropriate references to reduce the confusion
about the behavior of Common Lisp.
> >>> (defpackage :my-package
> >>> (:use #:cl #:foo))
> >>> in Lisp does 2 things:
> >>> 1. declares package my-package exists
> >>> 2. declares that all symbols from packages :cl and :foo are also in
> >>> package my-package (and thus can be accessed unqualified when code is
> >>> read in package my-package)
> >> How ugly. Imports shouldn't genuinely change package membership, just
> >> visibility. Now people can use my-package:sym when sym is really foo:sym!
>
> > Imports don't genuinely change package membership.
>
> But Alessio said "declares that all symbols from packages x and y are
> also in package my-package" ...
>
> Sigh. See above.
Fortunately, the behavior of Common Lisp is not specified by what
Alessio said on usenet. Rather, it is specified by the ANSI standard,
accessible online through the Hyperspec.
http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
Specifically
http://www.lispworks.com/documentation/HyperSpec/Body/m_defpkg.htm
Implementation dependent behavior will be specified by the relevant
implementation documentation.
Hope that helps,
Tom
On May 20, 11:24 pm, "Thomas M. Hermann" <··········@gmail.com> wrote:
> On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> > Thomas M. Hermann wrote:
> > > On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> > >> No, it's two different Lisp users contradicting each other about Lisp
> > >> here that I'm pointing out, not a Lisp and a Java user disagreeing.
> > >> (Though we've had lots of that, too.)
>
> > > That is the problem with relying on a usenet thread for your
> > > information about Lisp. If you are interested in understanding Lisp,
> > > you would be much better served referencing a Lisp text
>
> > Don't have one, sorry.
>
> That paragraph does not assign anything to you, so there is nothing
> for you to have or not have. It states the problem with relying on
> information about a programming language from posts on usenet is that
> the information has no assurance of correctness. To avoid this
> problem, you should refer to the appropriate texts documenting the
> programming language.
>
> > My point stands: if you guys can't be arsed to get your act together and
> > present your case MUCH better, you can hardly complain if you find you
> > don't manage to acquire many new converts or if you find your various
> > errors or disagreements being nitpicked by people you'd previously flamed.
>
> There is no case to present. I am not trying to convert anyone. I'm
> not complaining about anything. I only wish to provide the necessary
> information back by the appropriate references to reduce the confusion
> about the behavior of Common Lisp.
>
>
>
>
>
> > >>> (defpackage :my-package
> > >>> (:use #:cl #:foo))
> > >>> in Lisp does 2 things:
> > >>> 1. declares package my-package exists
> > >>> 2. declares that all symbols from packages :cl and :foo are also in
> > >>> package my-package (and thus can be accessed unqualified when code is
> > >>> read in package my-package)
> > >> How ugly. Imports shouldn't genuinely change package membership, just
> > >> visibility. Now people can use my-package:sym when sym is really foo:sym!
>
> > > Imports don't genuinely change package membership.
>
> > But Alessio said "declares that all symbols from packages x and y are
> > also in package my-package" ...
>
> > Sigh. See above.
>
> Fortunately, the behavior of Common Lisp is not specified by what
> Alessio said on usenet. Rather, it is specified by the ANSI standard,
> accessible online through the Hyperspec.
>
> http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
>
> Specifically
>
> http://www.lispworks.com/documentation/HyperSpec/Body/m_defpkg.htm
>
> Implementation dependent behavior will be specified by the relevant
> implementation documentation.
>
> Hope that helps,
>
> Tom- Hide quoted text -
>
> - Show quoted text -
Supplant to that free books such as PCL and On Lisp. Since you both
(Series and Seamus) seem to mistrust links posted in messages, just
google "Practical Common Lisp", or "Paul Graham" "On Lisp" and you'll
get the respective links.
- Adlai
Thomas M. Hermann wrote:
> On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Thomas M. Hermann wrote:
>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> No, it's two different Lisp users contradicting each other about Lisp
>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>>> (Though we've had lots of that, too.)
>>> That is the problem with relying on a usenet thread for your
>>> information about Lisp. If you are interested in understanding Lisp,
>>> you would be much better served referencing a Lisp text
>> Don't have one, sorry.
>
> there is nothing for you to have or not have.
"A Lisp text"?
[trimmed some condescending fluff with no meaningful substance]
>> My point stands: if you guys can't be arsed to get your act together and
>> present your case MUCH better, you can hardly complain if you find you
>> don't manage to acquire many new converts or if you find your various
>> errors or disagreements being nitpicked by people you'd previously flamed.
>
> There is no case to present. I am not trying to convert anyone.
Then you must have made a wrong turn somewhere. This is the
converting-Lispers-to-Java-and-vice-versa place. You may have been
looking for the ordinary-Java-discussions place, which is thataway, or
the ordinary-Lisp-discussions place, which is THATaway.
> I only wish to provide the necessary information back by the appropriate
> references to reduce the confusion about the behavior of Common Lisp.
You can do that without involving me. I'd suggest starting with
gugamilare, he's the one that's most frequently been contradicted by one
or more of the others, so he's probably the most confused.
>>>>> (defpackage :my-package
>>>>> (:use #:cl #:foo))
>>>>> in Lisp does 2 things:
>>>>> 1. declares package my-package exists
>>>>> 2. declares that all symbols from packages :cl and :foo are also in
>>>>> package my-package (and thus can be accessed unqualified when code is
>>>>> read in package my-package)
>>>> How ugly. Imports shouldn't genuinely change package membership, just
>>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
>>> Imports don't genuinely change package membership.
>> But Alessio said "declares that all symbols from packages x and y are
>> also in package my-package" ...
>>
>> Sigh. See above.
On May 20, 3:54 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Thomas M. Hermann wrote:
> > On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Thomas M. Hermann wrote:
> >>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> No, it's two different Lisp users contradicting each other about Lisp
> >>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
> >>>> (Though we've had lots of that, too.)
> >>> That is the problem with relying on a usenet thread for your
> >>> information about Lisp. If you are interested in understanding Lisp,
> >>> you would be much better served referencing a Lisp text
> >> Don't have one, sorry.
>
> > there is nothing for you to have or not have.
>
> "A Lisp text"?
A - indefinite article : not any particular or certain one of a
class or group.
Lisp - programming language : Common Lisp (sorry for not being
specific)
text - noun : the main body of matter in a manuscript, book,
newspaper, etc., as distinguished from notes, appendices, headings,
illustrations, etc.
So, what I'm recommending is that you reference the text in one or
many of the books, online or otherwise, covering the topic of the
Common Lisp programming language rather than obtaining the
information, of unknown quality, from a usenet thread. Furthermore, I
erred in only recommending the text, I also highly recommend looking
at the notes, appendices, headings, illustrations and any other
information contained in the books.
>
> [trimmed some condescending fluff with no meaningful substance]
>
> >> My point stands: if you guys can't be arsed to get your act together and
> >> present your case MUCH better, you can hardly complain if you find you
> >> don't manage to acquire many new converts or if you find your various
> >> errors or disagreements being nitpicked by people you'd previously flamed.
>
> > There is no case to present. I am not trying to convert anyone.
>
> Then you must have made a wrong turn somewhere. This is the
> converting-Lispers-to-Java-and-vice-versa place. You may have been
> looking for the ordinary-Java-discussions place, which is thataway, or
> the ordinary-Lisp-discussions place, which is THATaway.
But there is no one to convert. Studying Java and studying Lisp are
not exclusive activities. Studying programming languages is not a zero
sum game.
> > I only wish to provide the necessary information back by the appropriate
> > references to reduce the confusion about the behavior of Common Lisp.
>
> You can do that without involving me. I'd suggest starting with
> gugamilare, he's the one that's most frequently been contradicted by one
> or more of the others, so he's probably the most confused.
Whether or not you are involved in the discussion is not within my
control.
>
> >>>>> (defpackage :my-package
> >>>>> (:use #:cl #:foo))
> >>>>> in Lisp does 2 things:
> >>>>> 1. declares package my-package exists
> >>>>> 2. declares that all symbols from packages :cl and :foo are also in
> >>>>> package my-package (and thus can be accessed unqualified when code is
> >>>>> read in package my-package)
> >>>> How ugly. Imports shouldn't genuinely change package membership, just
> >>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
> >>> Imports don't genuinely change package membership.
> >> But Alessio said "declares that all symbols from packages x and y are
> >> also in package my-package" ...
>
> >> Sigh. See above.
>
>
Hope that helps,
Tom
Thomas M. Hermann wrote:
> On May 20, 3:54 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Thomas M. Hermann wrote:
>>> On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Thomas M. Hermann wrote:
>>>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> No, it's two different Lisp users contradicting each other about Lisp
>>>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>>>>> (Though we've had lots of that, too.)
>>>>> That is the problem with relying on a usenet thread for your
>>>>> information about Lisp. If you are interested in understanding Lisp,
>>>>> you would be much better served referencing a Lisp text
>>>> Don't have one, sorry.
>>> there is nothing for you to have or not have.
>> "A Lisp text"?
>
> A - indefinite article : not any particular or certain one of a
> class or group.
Oh for Christ's sake. I meant, what I don't have is a Lisp text. So
"there is nothing for you to have or not have" was wrong. Who wrote that
anyway? Oh, you did.
Stop being intentionally dense, admit it, and move on already.
>>>> My point stands: if you guys can't be arsed to get your act together and
>>>> present your case MUCH better, you can hardly complain if you find you
>>>> don't manage to acquire many new converts or if you find your various
>>>> errors or disagreements being nitpicked by people you'd previously flamed.
>>> There is no case to present. I am not trying to convert anyone.
>> Then you must have made a wrong turn somewhere. This is the
>> converting-Lispers-to-Java-and-vice-versa place. You may have been
>> looking for the ordinary-Java-discussions place, which is thataway, or
>> the ordinary-Lisp-discussions place, which is THATaway.
>
> But there is no one to convert.
Then you might as well quit arguing!
>>> I only wish to provide the necessary information back by the appropriate
>>> references to reduce the confusion about the behavior of Common Lisp.
>> You can do that without involving me. I'd suggest starting with
>> gugamilare, he's the one that's most frequently been contradicted by one
>> or more of the others, so he's probably the most confused.
>
> Whether or not you are involved in the discussion is not within my
> control.
More intentional density. I meant, of course, that if your disagreement
is really with gugamilare or any other non-me person, then you can
express that in replies to their posts and leave my name out of it!
>>>>>>> 2. declares that all symbols from packages :cl and :foo are also in
>>>>>>> package my-package (and thus can be accessed unqualified when code is
>>>>>>> read in package my-package)
>>>>>> How ugly. Imports shouldn't genuinely change package membership, just
>>>>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
>>>>> Imports don't genuinely change package membership.
>>>> But Alessio said "declares that all symbols from packages x and y are
>>>> also in package my-package" ...
>>>> Sigh. See above.
>
> Hope that helps,
>
> Tom
Is this a way of saying "no comment" without actually saying "no
comment", which has acquired a connotation of "guilty but not admitting
it" after decades of scandal-embroiled politicians using it? :)
On May 22, 4:31 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Thomas M. Hermann wrote:
> > On May 20, 3:54 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Thomas M. Hermann wrote:
> >>> On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Thomas M. Hermann wrote:
> >>>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>>>> No, it's two different Lisp users contradicting each other about Lisp
> >>>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
> >>>>>> (Though we've had lots of that, too.)
> >>>>> That is the problem with relying on a usenet thread for your
> >>>>> information about Lisp. If you are interested in understanding Lisp,
> >>>>> you would be much better served referencing a Lisp text
> >>>> Don't have one, sorry.
> >>> there is nothing for you to have or not have.
> >> "A Lisp text"?
>
> > A - indefinite article : not any particular or certain one of a
> > class or group.
>
> Oh for Christ's sake. I meant, what I don't have is a Lisp text. So
> "there is nothing for you to have or not have" was wrong. Who wrote that
> anyway? Oh, you did.
>
> Stop being intentionally dense, admit it, and move on already.
I'm not being intentionally dense. It was inconceivable to me that
when you replied "Don't have one, sorry." that the one you referred to
was a Lisp text, because you had been repeatedly given references to
freely accessible Lisp texts including the language standard. Next, I
connected "one" to a problem and in no way wished to imply that you
had a problem for fear of you thinking I was making a personal attack.
On reflection, it probably would have been most appropriate for me to
connect "Don't have one, sorry." with an interest in understanding
Lisp.
>
> >>>> My point stands: if you guys can't be arsed to get your act together and
> >>>> present your case MUCH better, you can hardly complain if you find you
> >>>> don't manage to acquire many new converts or if you find your various
> >>>> errors or disagreements being nitpicked by people you'd previously flamed.
> >>> There is no case to present. I am not trying to convert anyone.
> >> Then you must have made a wrong turn somewhere. This is the
> >> converting-Lispers-to-Java-and-vice-versa place. You may have been
> >> looking for the ordinary-Java-discussions place, which is thataway, or
> >> the ordinary-Lisp-discussions place, which is THATaway.
>
> > But there is no one to convert.
>
> Then you might as well quit arguing!
I am not arguing. I have only posted information and links to Common
Lisp references in the attempt to resolve misunderstandings about
Common Lisp. Well, now, I suppose I am arguing that I'm not arguing,
but it's more a clarification than an argument.
> >>> I only wish to provide the necessary information back by the appropriate
> >>> references to reduce the confusion about the behavior of Common Lisp.
> >> You can do that without involving me. I'd suggest starting with
> >> gugamilare, he's the one that's most frequently been contradicted by one
> >> or more of the others, so he's probably the most confused.
>
> > Whether or not you are involved in the discussion is not within my
> > control.
>
> More intentional density. I meant, of course, that if your disagreement
> is really with gugamilare or any other non-me person, then you can
> express that in replies to their posts and leave my name out of it!
Oh, I do not have a disagreement with gugamilare, nor you for that
matter. I only wish to help people in this discussion understand
Common Lisp. The best way I know of helping you understand Common Lisp
is directing you to suitable references so that you can explore it for
yourself.
>
> >>>>>>> 2. declares that all symbols from packages :cl and :foo are also in
> >>>>>>> package my-package (and thus can be accessed unqualified when code is
> >>>>>>> read in package my-package)
> >>>>>> How ugly. Imports shouldn't genuinely change package membership, just
> >>>>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
> >>>>> Imports don't genuinely change package membership.
> >>>> But Alessio said "declares that all symbols from packages x and y are
> >>>> also in package my-package" ...
> >>>> Sigh. See above.
>
> > Hope that helps,
>
> > Tom
>
> Is this a way of saying "no comment" without actually saying "no
> comment", which has acquired a connotation of "guilty but not admitting
> it" after decades of scandal-embroiled politicians using it? :)
No, it's a way of saying that I hope the information and
clarifications I provided helped you in your understanding of Common
Lisp and in our communication.
Hope that helps,
Tom
P.S. I noticed that you selectively clipped the quotations of my
responses without noting that they were clipped. In some cases, the
information you neglected to quote was important context for the
conversation. Just as you do not appreciate being selectively quoted,
neither do I.
Thomas M. Hermann wrote:
> On May 22, 4:31 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Thomas M. Hermann wrote:
>>> On May 20, 3:54 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Thomas M. Hermann wrote:
>>>>> On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> Thomas M. Hermann wrote:
>>>>>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>>>> No, it's two different Lisp users contradicting each other about Lisp
>>>>>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>>>>>>> (Though we've had lots of that, too.)
>>>>>>> That is the problem with relying on a usenet thread for your
>>>>>>> information about Lisp. If you are interested in understanding Lisp,
>>>>>>> you would be much better served referencing a Lisp text
>>>>>> Don't have one, sorry.
>>>>> there is nothing for you to have or not have.
>>>> "A Lisp text"?
>>> A - indefinite article : not any particular or certain one of a
>>> class or group.
>> Oh for Christ's sake. I meant, what I don't have is a Lisp text. So
>> "there is nothing for you to have or not have" was wrong. Who wrote that
>> anyway? Oh, you did.
>>
>> Stop being intentionally dense, admit it, and move on already.
>
> I'm not being intentionally dense.
Sure looked like you were.
> It was inconceivable to me that when you replied "Don't have one, sorry."
> that the one you referred to was a Lisp text
Why? Very few people in the world tend to keep Lisp texts lying around.
Probably mostly just you guys.
> On reflection, it probably would have been most appropriate for me to
> connect "Don't have one, sorry." with an interest in understanding
> Lisp.
No, that also would have been incorrect.
>>>>>> My point stands: if you guys can't be arsed to get your act together and
>>>>>> present your case MUCH better, you can hardly complain if you find you
>>>>>> don't manage to acquire many new converts or if you find your various
>>>>>> errors or disagreements being nitpicked by people you'd previously flamed.
>>>>> There is no case to present. I am not trying to convert anyone.
>>>> Then you must have made a wrong turn somewhere. This is the
>>>> converting-Lispers-to-Java-and-vice-versa place. You may have been
>>>> looking for the ordinary-Java-discussions place, which is thataway, or
>>>> the ordinary-Lisp-discussions place, which is THATaway.
>>> But there is no one to convert.
>> Then you might as well quit arguing!
>
> I am not arguing.
There! You just did it again -- you argued!
> I have only posted information and links to Common
> Lisp references in the attempt to resolve misunderstandings
I have had no misunderstandings, save perhaps when one of you has made
an erroneous or otherwise misleading statement here.
>>>>> I only wish to provide the necessary information back by the appropriate
>>>>> references to reduce the confusion about the behavior of Common Lisp.
>>>> You can do that without involving me. I'd suggest starting with
>>>> gugamilare, he's the one that's most frequently been contradicted by one
>>>> or more of the others, so he's probably the most confused.
>>> Whether or not you are involved in the discussion is not within my
>>> control.
>> More intentional density. I meant, of course, that if your disagreement
>> is really with gugamilare or any other non-me person, then you can
>> express that in replies to their posts and leave my name out of it!
>
> Oh, I do not have a disagreement with gugamilare, nor you for that
> matter.
That's an exceedingly odd thing for you to say shortly after saying
things contradicting things that both of us have said AND after
insulting me personally.
>>>>>>>>> 2. declares that all symbols from packages :cl and :foo are also in
>>>>>>>>> package my-package (and thus can be accessed unqualified when code is
>>>>>>>>> read in package my-package)
>>>>>>>> How ugly. Imports shouldn't genuinely change package membership, just
>>>>>>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
>>>>>>> Imports don't genuinely change package membership.
>>>>>> But Alessio said "declares that all symbols from packages x and y are
>>>>>> also in package my-package" ...
>>>>>> Sigh. See above.
>>> Hope that helps,
>>> Tom
>> Is this a way of saying "no comment" without actually saying "no
>> comment", which has acquired a connotation of "guilty but not admitting
>> it" after decades of scandal-embroiled politicians using it? :)
>
> No, it's a way of saying that I hope the information and
> clarifications I provided helped you in your understanding of Common
> Lisp and in our communication.
I referred to your conspicuous omission of two levels of quoted
material, quotation of some other material, and then giving your signoff
without any more topical text of your own.
> P.S. I noticed that you selectively clipped the quotations of my
> responses [rest of accusation of dishonesty deleted]
I did sometimes elide pointless and insulting parts, leaving only what
was relevant to the issue of Java vs. Lisp, in the interests of decorum,
clarity, and avoiding unnecessary distractions from the topic at hand.
On May 22, 11:29 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Thomas M. Hermann wrote:
> > On May 22, 4:31 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Thomas M. Hermann wrote:
> >>> On May 20, 3:54 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> Thomas M. Hermann wrote:
> >>>>> On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>>>> Thomas M. Hermann wrote:
> >>>>>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>>>>>> No, it's two different Lisp users contradicting each other about Lisp
> >>>>>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
> >>>>>>>> (Though we've had lots of that, too.)
> >>>>>>> That is the problem with relying on a usenet thread for your
> >>>>>>> information about Lisp. If you are interested in understanding Lisp,
> >>>>>>> you would be much better served referencing a Lisp text
> >>>>>> Don't have one, sorry.
> >>>>> there is nothing for you to have or not have.
> >>>> "A Lisp text"?
> >>> A - indefinite article : not any particular or certain one of a
> >>> class or group.
> >> Oh for Christ's sake. I meant, what I don't have is a Lisp text. So
> >> "there is nothing for you to have or not have" was wrong. Who wrote that
> >> anyway? Oh, you did.
>
> >> Stop being intentionally dense, admit it, and move on already.
>
> > I'm not being intentionally dense.
>
> Sure looked like you were.
That is what you perceived. I responded to clarify.
>
> > It was inconceivable to me that when you replied "Don't have one, sorry."
> > that the one you referred to was a Lisp text
>
> Why? Very few people in the world tend to keep Lisp texts lying around.
> Probably mostly just you guys.
My sentence concluded "... because you had been repeatedly given
references to freely accessible Lisp texts including the language
standard." If you had read the entire sentence, there would have been
no reason to ask why.
>
> > On reflection, it probably would have been most appropriate for me to
> > connect "Don't have one, sorry." with an interest in understanding
> > Lisp.
>
> No, that also would have been incorrect.
There were three possibilities, (1) you have a problem, (2) you have
no interest in understanding Common Lisp and (3) you don't have a lisp
text. Possibility (1) is outside the scope of this discussion. You had
repeatedly been given the means to rectify possibility (3) prior my
response. Consequently, possibility (2) was the only one remaining.
The fact that you have been given the means to rectify possibility (3)
and have not further supports possibility (2).
>
> >>>>>> My point stands: if you guys can't be arsed to get your act together and
> >>>>>> present your case MUCH better, you can hardly complain if you find you
> >>>>>> don't manage to acquire many new converts or if you find your various
> >>>>>> errors or disagreements being nitpicked by people you'd previously flamed.
> >>>>> There is no case to present. I am not trying to convert anyone.
> >>>> Then you must have made a wrong turn somewhere. This is the
> >>>> converting-Lispers-to-Java-and-vice-versa place. You may have been
> >>>> looking for the ordinary-Java-discussions place, which is thataway, or
> >>>> the ordinary-Lisp-discussions place, which is THATaway.
> >>> But there is no one to convert.
> >> Then you might as well quit arguing!
>
> > I am not arguing.
>
> There! You just did it again -- you argued!
No I didn't.
>
> > I have only posted information and links to Common
> > Lisp references in the attempt to resolve misunderstandings
>
> I have had no misunderstandings, save perhaps when one of you has made
> an erroneous or otherwise misleading statement here.
>
> >>>>> I only wish to provide the necessary information back by the appropriate
> >>>>> references to reduce the confusion about the behavior of Common Lisp.
> >>>> You can do that without involving me. I'd suggest starting with
> >>>> gugamilare, he's the one that's most frequently been contradicted by one
> >>>> or more of the others, so he's probably the most confused.
> >>> Whether or not you are involved in the discussion is not within my
> >>> control.
> >> More intentional density. I meant, of course, that if your disagreement
> >> is really with gugamilare or any other non-me person, then you can
> >> express that in replies to their posts and leave my name out of it!
>
> > Oh, I do not have a disagreement with gugamilare, nor you for that
> > matter.
>
> That's an exceedingly odd thing for you to say shortly after saying
> things contradicting things that both of us have said AND after
> insulting me personally.
You have not been insulted personally by me, ever. Conversely, you
have insulted me.
> >>>>>>>>> 2. declares that all symbols from packages :cl and :foo are also in
> >>>>>>>>> package my-package (and thus can be accessed unqualified when code is
> >>>>>>>>> read in package my-package)
> >>>>>>>> How ugly. Imports shouldn't genuinely change package membership, just
> >>>>>>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
> >>>>>>> Imports don't genuinely change package membership.
> >>>>>> But Alessio said "declares that all symbols from packages x and y are
> >>>>>> also in package my-package" ...
> >>>>>> Sigh. See above.
> >>> Hope that helps,
> >>> Tom
> >> Is this a way of saying "no comment" without actually saying "no
> >> comment", which has acquired a connotation of "guilty but not admitting
> >> it" after decades of scandal-embroiled politicians using it? :)
>
> > No, it's a way of saying that I hope the information and
> > clarifications I provided helped you in your understanding of Common
> > Lisp and in our communication.
>
> I referred to your conspicuous omission of two levels of quoted
> material, quotation of some other material, and then giving your signoff
> without any more topical text of your own.
All omissions were noted. Enough context was left to support the
discussion.
>
> > P.S. I noticed that you selectively clipped the quotations of my
> > responses [rest of accusation of dishonesty deleted]
>
> I did sometimes elide pointless and insulting parts, leaving only what
> was relevant to the issue of Java vs. Lisp, in the interests of decorum,
> clarity, and avoiding unnecessary distractions from the topic at hand.
The omissions contained points, you insult me calling them pointless.
Do you, Seamus MacRae, have an interest in learning and understanding
Common Lisp?
Thomas M. Hermann wrote:
> On May 22, 11:29 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Thomas M. Hermann wrote:
>>> On May 22, 4:31 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Thomas M. Hermann wrote:
>>>>> On May 20, 3:54 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> Thomas M. Hermann wrote:
>>>>>>> On May 20, 3:05 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>>>> Thomas M. Hermann wrote:
>>>>>>>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>>>>>> No, it's two different Lisp users contradicting each other about Lisp
>>>>>>>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>>>>>>>>> (Though we've had lots of that, too.)
>>>>>>>>> That is the problem with relying on a usenet thread for your
>>>>>>>>> information about Lisp. If you are interested in understanding Lisp,
>>>>>>>>> you would be much better served referencing a Lisp text
>>>>>>>> Don't have one, sorry.
>>>>>>> there is nothing for you to have or not have.
>>>>>> "A Lisp text"?
>>>>> A - indefinite article : not any particular or certain one of a
>>>>> class or group.
>>>> Oh for Christ's sake. I meant, what I don't have is a Lisp text. So
>>>> "there is nothing for you to have or not have" was wrong. Who wrote that
>>>> anyway? Oh, you did.
>>>> Stop being intentionally dense, admit it, and move on already.
>>> I'm not being intentionally dense.
>> Sure looked like you were.
>
> That is what you perceived. I responded to clarify.
You failed.
>>> It was inconceivable to me that when you replied "Don't have one, sorry."
>>> that the one you referred to was a Lisp text
>> Why? Very few people in the world tend to keep Lisp texts lying around.
>> Probably mostly just you guys.
>
> My sentence concluded "... because you had been repeatedly given
How your sentence concluded is irrelevant. It does not change the fact
that very few people in the world tend to keep Lisp texts lying around.
Probably mostly just you guys.
>>> On reflection, it probably would have been most appropriate for me to
>>> connect "Don't have one, sorry." with an interest in understanding
>>> Lisp.
>> No, that also would have been incorrect.
>
> There were three possibilities, (1) you have a problem, (2) you have
> no interest in understanding Common Lisp and (3) you don't have a lisp
> text. Possibility (1) is outside the scope of this discussion. You had
> repeatedly been given the means to rectify possibility (3) prior my
> response. Consequently, possibility (2) was the only one remaining.
That does not follow. Possibility (3) remains, because giving someone
the means to "rectify" it does not necessarily result in their instantly
actually doing so. Perhaps they have not gotten around to it yet. I also
dispute the claim that the means were actually given, and the
implication that my non-possession of a Lisp text is necessarily a state
of affairs in need of "rectification".
> The fact that you have been given the means to rectify possibility (3)
> and have not further supports possibility (2).
It certainly does not prove it, especially after so short a period of
time. You cannot make assumptions about my physical location, either; it
is possible I'm making NNTP connections via a modem and sat-phone from
the middle of the Amazon rain forest, so far as you can tell, and
therefore several weeks of travel from the nearest bookstore.
And as for your implication that possibility (3), a lack of interest in
Lisp, is a condition in need of "rectification", that would be begging
the question, that is to say, assuming something (Lisp's superiority)
that you have set out to prove.
>>>>>>>> My point stands: if you guys can't be arsed to get your act together and
>>>>>>>> present your case MUCH better, you can hardly complain if you find you
>>>>>>>> don't manage to acquire many new converts or if you find your various
>>>>>>>> errors or disagreements being nitpicked by people you'd previously flamed.
>>>>>>> There is no case to present. I am not trying to convert anyone.
>>>>>> Then you must have made a wrong turn somewhere. This is the
>>>>>> converting-Lispers-to-Java-and-vice-versa place. You may have been
>>>>>> looking for the ordinary-Java-discussions place, which is thataway, or
>>>>>> the ordinary-Lisp-discussions place, which is THATaway.
>>>>> But there is no one to convert.
>>>> Then you might as well quit arguing!
>>> I am not arguing.
>> There! You just did it again -- you argued!
> No I didn't.
And there you go again.
*shakes head* Most illogical ...
>>>>>>> I only wish to provide the necessary information back by the appropriate
>>>>>>> references to reduce the confusion about the behavior of Common Lisp.
[snip]
>>> Oh, I do not have a disagreement with gugamilare, nor you for that
>>> matter.
>> That's an exceedingly odd thing for you to say shortly after saying
>> things contradicting things that both of us have said AND after
>> insulting me personally.
>
> You have not been insulted personally by me, ever.
That is not correct. The deeply-nested two lines quoted above, for
instance, imply such an insult.
> Conversely, you have insulted me.
That much is probably true.
>>>>>>>>>>> 2. declares that all symbols from packages :cl and :foo are also in
>>>>>>>>>>> package my-package (and thus can be accessed unqualified when code is
>>>>>>>>>>> read in package my-package)
>>>>>>>>>> How ugly. Imports shouldn't genuinely change package membership, just
>>>>>>>>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
>>>>>>>>> Imports don't genuinely change package membership.
>>>>>>>> But Alessio said "declares that all symbols from packages x and y are
>>>>>>>> also in package my-package" ...
>>>>>>>> Sigh. See above.
>>>>> Hope that helps,
>>>>> Tom
>>>> Is this a way of saying "no comment" without actually saying "no
>>>> comment", which has acquired a connotation of "guilty but not admitting
>>>> it" after decades of scandal-embroiled politicians using it? :)
>>> No, it's a way of saying that I hope the information and
>>> clarifications I provided helped you in your understanding of Common
>>> Lisp and in our communication.
>> I referred to your conspicuous omission of two levels of quoted
>> material, quotation of some other material, and then giving your signoff
>> without any more topical text of your own.
>
> All omissions were noted. Enough context was left to support the
> discussion.
What discussion? That quoted text was followed by a generic signoff, but
by no other unquoted content. Quoting something without a response does
not constitute discussing it.
>>> P.S. I noticed that you selectively clipped the quotations of my
>>> responses [rest of accusation of dishonesty deleted]
>> I did sometimes elide pointless and insulting parts, leaving only what
>> was relevant to the issue of Java vs. Lisp, in the interests of decorum,
>> clarity, and avoiding unnecessary distractions from the topic at hand.
>
> The omissions contained points, you insult me calling them pointless.
With good reason. What you called "points" were invalid ad hominem
arguments that utterly failed to actually logically support your
contention that Lisp is superior to Java.
> Do you, Seamus MacRae, have an interest in learning and understanding
> Common Lisp?
I had a bit. Now I confess I have much less, due to the company that
Common Lisp keeps. If Common Lisp had been a female suitor, it would be
as if I had just come into contact with several of her large and
dangerously unsocialized dogs, several of them apparently possessed of a
vicious streak, the existence of which had heretofore been unknown to
me. Needless to say, that would tend to somewhat diminish my interest.
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Thomas M. Hermann wrote:
>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> No, it's two different Lisp users contradicting each other about Lisp
>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>> (Though we've had lots of that, too.)
>>
>> That is the problem with relying on a usenet thread for your
>> information about Lisp. If you are interested in understanding Lisp,
>> you would be much better served referencing a Lisp text
>
> Don't have one, sorry.
You don't have Internet access? How do you post?
There are a number of free books about Common Lisp that you can download.
(Your antedeluvial browser might blow up on a PDF, mind you).
Moreover, the HTML-ized form of the ANSI CL standard, courtesy of Kent Pitman,
is available for download for local installation, as well as hosted by several
sites for online reading.
I don't have any Java book on my shelf, but before posting anything about Java,
I check my facts in _The Java Language Specification_ and other sources
online.
> My point stands: if you guys can't be arsed to get your act together and
> present your case MUCH better, you can hardly complain if you find you
> don't manage to acquire many new converts or if you find your various
> errors or disagreements being nitpicked by people you'd previously flamed.
Not everyone cares about converts. The fewer people program in Lisp, the
better.
Idiots of the world, stick to wearing your bear skins and carving with stone
knives.
>>>> (defpackage :my-package
>>>> (:use #:cl #:foo))
>>>> in Lisp does 2 things:
>>>> 1. declares package my-package exists
>>>> 2. declares that all symbols from packages :cl and :foo are also in
>>>> package my-package (and thus can be accessed unqualified when code is
>>>> read in package my-package)
>>> How ugly. Imports shouldn't genuinely change package membership, just
>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
>>
>> Imports don't genuinely change package membership.
Use (as via the :use clause in defpackage) is not import. Package use
doesn't change package membership. Symbol import does.
Visibility does mean that that if package foo has an external symbol sym, then
you can now use my-package::sym. But you cannot use my-package:sym. The
accessibility situation does not cause the symbol to be external in my-package.
The effect is as if my-package had an internal symbol called sym.
My-package can, however, re-export the symbol:
(defpackage :my-package
(:use :foo) ;; provides SYM
(:export :sym) ;; re-export SYM
)
Now we can write my-package:sym.
> But Alessio said "declares that all symbols from packages x and y are
> also in package my-package" ...
The facts, from the Common Lisp HyperSpec are this: the use of one package by
another causes the exported symbols of the used package to be /accessible/
through the one which is using it. A symbol import is different; it actually
sticks a symbol into a package. The same symbol object can be imported into
more than one package. It is then more than just /accessible/ in all those
packages; it is said to be /present/ in all of them. One of the packages
where a symbol is present may be its home package. This is the package that is
returned when we ask a symbol what its package is using the symbol-package
function. Symbols which have no home package are printed with a special
notation (the #: prefix).
Not all people in comp.lang.lisp are language lawyers, let alone about the
intricacy of packages.
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Thomas M. Hermann wrote:
>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> No, it's two different Lisp users contradicting each other about Lisp
>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>> (Though we've had lots of that, too.)
>>
>> That is the problem with relying on a usenet thread for your
>> information about Lisp. If you are interested in understanding Lisp,
>> you would be much better served referencing a Lisp text
>
> Don't have one, sorry.
You don't have Internet access? How do you post?
There are a number of free books about Common Lisp that you can download.
(Your antedeluvial browser might blow up on a PDF, mind you).
Moreover, the HTML-ized form of the ANSI CL standard, courtesy of Kent Pitman,
is available for download for local installation, as well as hosted by several
sites for online reading.
I don't have any Java book on my shelf, but before posting anything about Java,
I check my facts in _The Java Language Specification_ and other sources
online.
> My point stands: if you guys can't be arsed to get your act together and
> present your case MUCH better, you can hardly complain if you find you
> don't manage to acquire many new converts or if you find your various
> errors or disagreements being nitpicked by people you'd previously flamed.
Not everyone cares about converts. The fewer people program in Lisp, the
better.
Idiots of the world, stick to wearing your bear skins and carving with stone
knives.
>>>> (defpackage :my-package
>>>> (:use #:cl #:foo))
>>>> in Lisp does 2 things:
>>>> 1. declares package my-package exists
>>>> 2. declares that all symbols from packages :cl and :foo are also in
>>>> package my-package (and thus can be accessed unqualified when code is
>>>> read in package my-package)
>>> How ugly. Imports shouldn't genuinely change package membership, just
>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
>>
>> Imports don't genuinely change package membership.
Use (as via the :use clause in defpackage) is not import. Package use
doesn't change package membership. Symbol import does.
Visibility does mean that that if package foo has an external symbol sym, then
you can now use my-package::sym. But you cannot use my-package:sym. The
accessibility situation does not cause the symbol to be external in my-package.
The effect is as if my-package had an internal symbol called sym.
My-package can, however, re-export the symbol:
(defpackage :my-package
(:use :foo) ;; provides SYM
(:export :sym) ;; re-export SYM
)
Now we can write my-package:sym.
> But Alessio said "declares that all symbols from packages x and y are
> also in package my-package" ...
The facts, from the Common Lisp HyperSpec are this: the use of one package by
another causes the exported symbols of the used package to be /accessible/
through the one which is using it. A symbol import is different; it actually
sticks a symbol into a package. The same symbol object can be imported into
more than one package. It is then more than just /accessible/ in all those
packages; it is said to be /present/ in all of them. One of the packages
where a symbol is present may be its home package. This is the package that is
returned when we ask a symbol what its package is using the symbol-package
function. Symbols which have no home package are printed with a special
notation (the #: prefix).
Not all people in comp.lang.lisp are language lawyers, let alone about the
intricacy of packages.
Kaz Kylheku wrote:
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Thomas M. Hermann wrote:
>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> No, it's two different Lisp users contradicting each other about Lisp
>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>>> (Though we've had lots of that, too.)
>>> That is the problem with relying on a usenet thread for your
>>> information about Lisp. If you are interested in understanding Lisp,
>>> you would be much better served referencing a Lisp text
>> Don't have one, sorry.
>
> You don't have Internet access?
No, a Lisp text, silly! (How the hell did you make that error? The
preceding text doesn't mention the Internet, and it's fairly obvious
that I DO have internet access. Really, the referent of my "don't have
one" should have been quite obvious. I can't help suspecting you're
being intentionally obtuse.)
> How do you post?
Motzarella. ISP stopped carrying newsgroups, the fuckers.
> I don't have any Java book on my shelf, but before posting anything about Java,
> I check my facts in _The Java Language Specification_ and other sources
> online.
Is this intended to be a veiled insult?
It doesn't help your case that you apparently feel the need to resort to
such tactics instead of putting forth cogent, rational arguments to
support your cause.
>> My point stands: if you guys can't be arsed to get your act together and
>> present your case MUCH better, you can hardly complain if you find you
>> don't manage to acquire many new converts or if you find your various
>> errors or disagreements being nitpicked by people you'd previously flamed.
>
> Not everyone cares about converts. The fewer people program in Lisp, the
> better.
So now you've actually been convinced by our side? Then can we stop
fighting now? :)
> Idiots of the world, stick to wearing your bear skins and carving with stone
> knives.
I guess not. How disappointing. Although I'll have you know my IQ tested
in the 120-130 range in high school.
>>>>> 2. declares that all symbols from packages :cl and :foo are also in
>>>>> package my-package (and thus can be accessed unqualified when code is
>>>>> read in package my-package)
>>>> How ugly. Imports shouldn't genuinely change package membership, just
>>>> visibility. Now people can use my-package:sym when sym is really foo:sym!
>>> Imports don't genuinely change package membership.
Statement 2 and the last line contradict each other, and both came from
the Lisp side (same parity of nesting depth, with a paragraph by me in
between). My statement assumes Statement 2 to be the correct one of the
two; if it's not, the error lies with Statement 2's author, and I am to
be held blameless for it.
> Package use doesn't change package membership. Symbol import does.
This sounds consistent with Statement 2 again though.
> Visibility does mean that that if package foo has an external symbol sym, then
> you can now use my-package::sym.
As does this.
>> But Alessio said "declares that all symbols from packages x and y are
>> also in package my-package" ...
>
> The facts, from the Common Lisp HyperSpec are this: the use of one package by
> another causes the exported symbols of the used package to be /accessible/
> through the one which is using it.
As does this.
> [A rather large Excedrin headache deleted]
>
> Not all people in comp.lang.lisp are language lawyers, let alone about the
> intricacy of packages.
But apparently to understand the intricacies of your coworkers' code
you'll need to become one. At least you have the consolation of knowing
that if Novartis someday decides to give some sort of free stuff to
their one billionth customer, you've got excellent odds of claiming the
prize.
On May 22, 12:41 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Kaz Kylheku wrote:
> > On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Thomas M. Hermann wrote:
> >>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> >>>> No, it's two different Lisp users contradicting each other about Lisp
> >>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
> >>>> (Though we've had lots of that, too.)
> >>> That is the problem with relying on a usenet thread for your
> >>> information about Lisp. If you are interested in understanding Lisp,
> >>> you would be much better served referencing a Lisp text
> >> Don't have one, sorry.
>
> > You don't have Internet access?
>
> No, a Lisp text, silly! (How the hell did you make that error? The
> preceding text doesn't mention the Internet, and it's fairly obvious
> that I DO have internet access. Really, the referent of my "don't have
> one" should have been quite obvious. I can't help suspecting you're
> being intentionally obtuse.)
>
Having Internet access IS having access to a Lisp text.
Google "Practical Common Lisp". Seriously. It's free and teaches you
how to do all sorts of neat shit.
- Adlai
Adlai wrote:
> On May 22, 12:41 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Kaz Kylheku wrote:
>>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Thomas M. Hermann wrote:
>>>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> No, it's two different Lisp users contradicting each other about Lisp
>>>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>>>>> (Though we've had lots of that, too.)
>>>>> That is the problem with relying on a usenet thread for your
>>>>> information about Lisp. If you are interested in understanding Lisp,
>>>>> you would be much better served referencing a Lisp text
>>>> Don't have one, sorry.
>>> You don't have Internet access?
>> No, a Lisp text, silly! (How the hell did you make that error? The
>> preceding text doesn't mention the Internet, and it's fairly obvious
>> that I DO have internet access. Really, the referent of my "don't have
>> one" should have been quite obvious. I can't help suspecting you're
>> being intentionally obtuse.)
Seamus MacRae wrote:
> Kaz Kylheku wrote:
>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>> Thomas M. Hermann wrote:
>>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>> No, it's two different Lisp users contradicting each other about Lisp
>>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>>>> (Though we've had lots of that, too.)
>>>> That is the problem with relying on a usenet thread for your
>>>> information about Lisp. If you are interested in understanding Lisp,
>>>> you would be much better served referencing a Lisp text
>>> Don't have one, sorry.
>>
>> You don't have Internet access?
>
> No, a Lisp text, silly! (How the hell did you make that error? The
> preceding text doesn't mention the Internet, and it's fairly obvious
> that I DO have internet access. Really, the referent of my "don't have
> one" should have been quite obvious. I can't help suspecting you're
> being intentionally obtuse.)
I think you are missing the point.
There are Lisp texts available on the internet.
>> How do you post?
>
> Motzarella.
Known for anonymity of posters.
>> Idiots of the world, stick to wearing your bear skins and carving with
>> stone
>> knives.
>
> I guess not. How disappointing. Although I'll have you know my IQ tested
> in the 120-130 range in high school.
Should I post the well-known links describing the remarkable
impression you made back then?
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Kaz Kylheku wrote:
>>> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Thomas M. Hermann wrote:
>>>>> On May 20, 1:44 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>>>> No, it's two different Lisp users contradicting each other about Lisp
>>>>>> here that I'm pointing out, not a Lisp and a Java user disagreeing.
>>>>>> (Though we've had lots of that, too.)
>>>>> That is the problem with relying on a usenet thread for your
>>>>> information about Lisp. If you are interested in understanding Lisp,
>>>>> you would be much better served referencing a Lisp text
>>>> Don't have one, sorry.
>>>
>>> You don't have Internet access?
>>
>> No, a Lisp text, silly! (How the hell did you make that error? The
>> preceding text doesn't mention the Internet, and it's fairly obvious
>> that I DO have internet access. Really, the referent of my "don't have
>> one" should have been quite obvious. I can't help suspecting you're
>> being intentionally obtuse.)
>
> I think you are missing the point.
You keep saying that. It doesn't become any truer from repetition; it's
simply false. Nor would it be evidence in favor of either Lisp or Java
were it true.
>>> How do you post?
>>
>> Motzarella.
>
> Known for anonymity of posters.
This is also not relevant to either Lisp or Java. I suspect you intended
it as a disparagement, but it fails to accomplish even that dubious goal.
On May 20, 3:43 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> Arguing with a side that contradicts itself and changes the "rules"
> every time it's pressed quickly gets tiresome.
>
> I may not bother much longer.
Yes, please, leave us stupid Lispers to our own ignorance.
Duane
On May 16, 3:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
[...]
> >> Subject to some qualification, no doubt.
> > Nope, not really.
> Pollyanna much?
Why do you keep insisting that I believe you instead of my own lying
eyes?
[...]
> >> Ah, okay. I see; the qualification is evidently "must be rocket
> >> scientist, or have economy-size bottle of Motrin". :)
> > Eh, in the general case you just use the packages you want to use and
> > that's that
> Yes, and meanwhile at Mission Control, you just trigger the final
> pre-orbital burn of the hypergolic propellants at max-Q and that's that.
Well, OK, let's talk about the not-so-general case, where you try to
use two packages that both export the same name.
You'll get an error telling you that you're trying to use two packages
with the same name, and what that name is. Now that the implementation
has stopped you from defining the new package and told you about the
conflict, you can change the definition of the package so the conflict
doesn't exist anymore.
> Remind me NOT to ever trust you with a multi-million-dollar satellite
> payload. :)
Why not? You keep insisting I'm a rocket scientist. ;)
[...]
> >> Java lets you get by with a plain old
> >> import foo;
> >> by contrast.
> > I'm missing the part where that's conspicuously easier than the Lisp
> > option.
> Well, let's see...
> (defpackage #:my-package
> (:use #:cl #:foo))
> Two lines. 42 characters (not including internal linefeed and
> indentation). Nesting depth of brackets: 2.
> import foo;
> One line. 11 characters. Nesting depth of brackets: zero.
Yeah, except what I've done is equivalent to Java's
package myPackage;
import foo;
If you want to obsess about a few extra characters, have fun.
Cheers,
Pillsy
On May 16, 11:56 am, Pillsy <·········@gmail.com> wrote:
> On May 16, 3:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
[...]
> > One line. 11 characters. Nesting depth of brackets: zero.
> Yeah, except what I've done is equivalent to Java's
> package myPackage;
> import foo;
I mean, "import foo.*;" of course, like Mr Stalla said.
I don't know Java all that well. However, if you really like, I can
invent a bunch of terrible problems with the language that you've just
been ignoring all this time due to your exuberant optimism.
Cheers, Pillsy
Pillsy wrote:
> On May 16, 11:56 am, Pillsy <·········@gmail.com> wrote:
>> On May 16, 3:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> [...]
>>> One line. 11 characters. Nesting depth of brackets: zero.
>
>> Yeah, except what I've done is equivalent to Java's
>
>> package myPackage;
>> import foo;
>
> I mean, "import foo.*;" of course, like Mr Stalla said.
>
> I don't know Java all that well. However, if you really like, I can
> invent a bunch of terrible problems with the language that you've just
> been ignoring all this time due to your exuberant optimism.
That would be silly, perhaps even sillier than your thinly-veiled and
erroneous implication that I've been doing something analogous.
Seamus MacRae <··········@live.ca.nospam> writes:
> Pillsy wrote:
> > I don't know Java all that well. However, if you really like, I can
> > invent a bunch of terrible problems with the language that you've just
> > been ignoring all this time due to your exuberant optimism.
>
> That would be silly, perhaps even sillier than your thinly-veiled and
> erroneous implication that I've been doing something analogous.
Hmm. First of all, it wasn't thinly veiled. Second of all, it isn't
erroneous.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Pillsy wrote:
>>> I don't know Java all that well. However, if you really like, I can
>>> invent a bunch of terrible problems with the language that you've just
>>> been ignoring all this time due to your exuberant optimism.
>> That would be silly, perhaps even sillier than your thinly-veiled and
>> erroneous implication that I've been doing something analogous.
>
> [calls me a liar, and tries to do it behind my back, failing miserably]
Par for the course, but we can all see who's the dishonest one here.
Pillsy wrote:
> On May 16, 3:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>
>>> On May 15, 11:13 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> [...]
>>>> Subject to some qualification, no doubt.
>
>>> Nope, not really.
>
>> Pollyanna much?
>
> Why do you keep insisting that I believe you instead of my own lying
> eyes?
Your eyes lie? Or do you mean the other sense ... amblyopia then?
Anyway, you keep insisting I believe you instead of what reason and
logic says follows from your own prior statements...
>>>> Ah, okay. I see; the qualification is evidently "must be rocket
>>>> scientist, or have economy-size bottle of Motrin". :)
>
>>> Eh, in the general case you just use the packages you want to use and
>>> that's that
>
>> Yes, and meanwhile at Mission Control, you just trigger the final
>> pre-orbital burn of the hypergolic propellants at max-Q and that's that.
>
> Well, OK, let's talk about the not-so-general case, where you try to
> use two packages that both export the same name.
>
> You'll get an error telling you that you're trying to use two packages
> with the same name, and what that name is. Now that the implementation
> has stopped you from defining the new package
Hey, hey, hey. Wait a minute here. Who said anything about defining a
new package? I'm not interested in that. In the equivalent of Java code
such as:
package foo;
import java.util.Date;
...
Date today = new Date();
javax.sql.Date thingyDate = thingyFromDatabase.getDate();
I am interested in the "import java.util.Date;" and the "javax.sql.Date
thingyDate = thingyFromDatabase.getDate()" bits, or rather, their Lisp
equivalents, rather than the "package foo;" bit or its equivalent.
>> Remind me NOT to ever trust you with a multi-million-dollar satellite
>> payload. :)
>
> Why not? You keep insisting I'm a rocket scientist. ;)
Actually, that you have pretensions in that area, and an unknown actual
level of skill, but a lot of pride and little self-examination or
thought given to the possibility that you might be, you know, *wrong*
once in a while.
>>>> Java lets you get by with a plain old
>
>>>> import foo;
>
>>>> by contrast.
>
>>> I'm missing the part where that's conspicuously easier than the Lisp
>>> option.
>
>> Well, let's see...
>
>> (defpackage #:my-package
>> (:use #:cl #:foo))
>
>> Two lines. 42 characters (not including internal linefeed and
>> indentation). Nesting depth of brackets: 2.
>
>> import foo;
>
>> One line. 11 characters. Nesting depth of brackets: zero.
>
> Yeah, except what I've done is equivalent to Java's
>
> package myPackage;
> import foo;
Except this was in response to, basically, "how does Lisp do import
foo;?". Apparently it was not actually an accurate answer to the posed
question!
> If you want to obsess about a few extra characters, have fun.
The point is that the Lisp option is not conspicuously easier. At best
it's about on a par; in practice, the quantity of shifted characters is
likely to make it quite bit more awkward to type. (Those would be :#()
with a total of 11 of those -- as many characters as the ENTIRE Java
import has; ZERO of which were shifted.)
On May 20, 6:56 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > On May 16, 3:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> >> Pillsy wrote:
[...]
> >> Pollyanna much?
> > Why do you keep insisting that I believe you instead of my own lying
> > eyes?
> Your eyes lie? Or do you mean the other sense ... amblyopia then?
> Anyway, you keep insisting I believe you instead of what reason and
> logic says follows from your own prior statements...
If you think I'm lying about what problems I've experienced, this
conversation couldn't be more pointless. If you don't think I'm
lying, the only other option is that your logic and reason are faulty.
IMO, when theory and practice differ, practice ought to trump theory,
not the other way around. YM evidently V.
[...]
> >> Yes, and meanwhile at Mission Control, you just trigger the final
> >> pre-orbital burn of the hypergolic propellants at max-Q and that's that.
> > Well, OK, let's talk about the not-so-general case, where you try to
> > use two packages that both export the same name.
> > You'll get an error telling you that you're trying to use two packages
> > with the same name, and what that name is. Now that the implementation
> > has stopped you from defining the new package
> Hey, hey, hey. Wait a minute here. Who said anything about defining a
> new package?
I did. That's usually the way you manage namespaces in Common Lisp:
you make a package, you suck in everything you need in the package,
export everything you want to expose, and then put IN-PACKAGE forms at
the top of all the source files that define functions, macros,
classes, et c. in that package.
> I'm not interested in that. In the equivalent of Java code
> such as:
> package foo;
> import java.util.Date;
> ...
> Date today = new Date();
> javax.sql.Date thingyDate = thingyFromDatabase.getDate();
> I am interested in the "import java.util.Date;" and the "javax.sql.Date
> thingyDate = thingyFromDatabase.getDate()" bits, or rather, their Lisp
> equivalents, rather than the "package foo;" bit or its equivalent.
Believe it or not, different things are grouped differently in
different languages. When you define a namespace with the DEFPACKAGE
form, *that's* the place that you also say what other packages are
being used (roughly equivalent to Java's "import foo.*", AIUI), what
individual symbols are being imported, how conflicts are resolved, and
what symbols you want to export.
[...]
> >> One line. 11 characters. Nesting depth of brackets: zero.
> > Yeah, except what I've done is equivalent to Java's
> > package myPackage;
> > import foo;
> Except this was in response to, basically, "how does Lisp do import
> foo;?". Apparently it was not actually an accurate answer to the posed
> question!
That may be because the two language constructs aren't precisely
equivalent. I suspect this is ultimately because Java closely
intertwines a number of things that Lisp leaves separate.
> > If you want to obsess about a few extra characters, have fun.
> The point is that the Lisp option is not conspicuously easier. At best
> it's about on a par; in practice, the quantity of shifted characters is
> likely to make it quite bit more awkward to type.
I'm not sure where you got the idea that anybody said it's
conspicuously easier. It looks about the same to me.
Cheers,
Pillsy
Pillsy wrote:
> On May 20, 6:56 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> On May 16, 3:42 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>>>> Pillsy wrote:
> [...]
>>>> Pollyanna much?
>
>>> Why do you keep insisting that I believe you instead of my own lying
>>> eyes?
>
>> Your eyes lie? Or do you mean the other sense ... amblyopia then?
>
>> Anyway, you keep insisting I believe you instead of what reason and
>> logic says follows from your own prior statements...
>
> If you think I'm lying about what problems I've experienced, this
> conversation couldn't be more pointless. If you don't think I'm
> lying, the only other option is that your logic and reason are faulty.
Nope. False dichotomy. I think you're not so much intentionally lying as
viewing Lisp through rose-colored glasses.
(My logic and reason are, of course, flawless.)
> IMO, when theory and practice differ, practice ought to trump theory,
When theory and hearsay testimony differ, hearsay testimony ought to
give way to theory.
>>>> Yes, and meanwhile at Mission Control, you just trigger the final
>>>> pre-orbital burn of the hypergolic propellants at max-Q and that's that.
>
>>> Well, OK, let's talk about the not-so-general case, where you try to
>>> use two packages that both export the same name.
>
>>> You'll get an error telling you that you're trying to use two packages
>>> with the same name, and what that name is. Now that the implementation
>>> has stopped you from defining the new package
>
>> Hey, hey, hey. Wait a minute here. Who said anything about defining a
>> new package?
>
> I did.
Well, that's cheating. You're not doing the same exact thing as I was,
which will render any comparison meaningless and result in you failing
to prove that Lisp does it more efficiently, which I assume is your goal.
>> I'm not interested in that. In the equivalent of Java code
>> such as:
>
>> package foo;
>> import java.util.Date;
>
>> ...
>
>> Date today = new Date();
>> javax.sql.Date thingyDate = thingyFromDatabase.getDate();
>
>> I am interested in the "import java.util.Date;" and the "javax.sql.Date
>> thingyDate = thingyFromDatabase.getDate()" bits, or rather, their Lisp
>> equivalents, rather than the "package foo;" bit or its equivalent.
>
> Believe it or not, different things are grouped differently in
> different languages.
This remark does not seem to be relevant.
>>>> One line. 11 characters. Nesting depth of brackets: zero.
>
>>> Yeah, except what I've done is equivalent to Java's
>
>>> package myPackage;
>>> import foo;
>
>> Except this was in response to, basically, "how does Lisp do import
>> foo;?". Apparently it was not actually an accurate answer to the posed
>> question!
>
> That may be because [excuses, excuses]
Are you endeavoring to assist in getting to the truth of the matter of
which language has the more efficient syntax for imports, or are you
intentionally muddying the waters?
> I suspect this is ultimately because Java closely intertwines a number
> of things that Lisp leaves separate.
From what you said earlier, it's the other way around, with Lisp
intertwining package declarations and imports and Java keeping them
separate (though all at the top of the source file).
>>> If you want to obsess about a few extra characters, have fun.
>
>> The point is that the Lisp option is not conspicuously easier. At best
>> it's about on a par; in practice, the quantity of shifted characters is
>> likely to make it quite bit more awkward to type.
>
> I'm not sure where you got the idea that anybody said it's
> conspicuously easier. It looks about the same to me.
You were the one to originally raise the question as to which was
easier, in
<····································@v4g2000vba.googlegroups.com>:
http://groups.google.com/group/comp.lang.lisp/msg/948007c3b7f26ec9
You:
> Me:
>> Java lets you get by with a plain old
>> import foo;
>> by contrast.
>
> I'm missing the part where that's conspicuously easier than the Lisp
> option.
You implied the Java way of doing things wasn't; by implication, that
the Lisp way of doing things was the easier instead. I disputed that.
But I did not originally raise the topic.
So, where I got the idea that anybody said it's conspicuously easier was
from you claiming Java's wasn't and implying that Lisp's was, four days ago.
On May 20, 3:00 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
[...]
> >> Hey, hey, hey. Wait a minute here. Who said anything about defining a
> >> new package?
> > I did.
> Well, that's cheating. You're not doing the same exact thing as I was,
> which will render any comparison meaningless and result in you failing
> to prove that Lisp does it more efficiently, which I assume is your goal.
Why would I do the exact same thing, when doing a somewhat different
thing is more idiomatic Lisp and gets the job done without any more
trouble? I don't know about you, but I don't slavishly immitate
languages I don't use when I work with languages I do.
[...]
> >> I am interested in the "import java.util.Date;" and the "javax.sql.Date
> >> thingyDate = thingyFromDatabase.getDate()" bits, or rather, their Lisp
> >> equivalents, rather than the "package foo;" bit or its equivalent.
> > Believe it or not, different things are grouped differently in
> > different languages.
> This remark does not seem to be relevant.
Of course it's relevant, because the most natural approach to the
problem in Lisp is to group the package definition and the imports
together.
[...]
> >> Except this was in response to, basically, "how does Lisp do import
> >> foo;?". Apparently it was not actually an accurate answer to the posed
> >> question!
> > That may be because [excuses, excuses]
> Are you endeavoring to assist in getting to the truth of the matter of
> which language has the more efficient syntax for imports, or are you
> intentionally muddying the waters?
The former. But thanks for asking!
> > I suspect this is ultimately because Java closely intertwines a number
> > of things that Lisp leaves separate.
> From what you said earlier, it's the other way around, with Lisp
> intertwining package declarations and imports and Java keeping them
> separate (though all at the top of the source file).
Well, OK, then.
[...]
> >> The point is that the Lisp option is not conspicuously easier. At best
> >> it's about on a par; in practice, the quantity of shifted characters is
> >> likely to make it quite bit more awkward to type.
> > I'm not sure where you got the idea that anybody said it's
> > conspicuously easier. It looks about the same to me.
> You were the one to originally raise the question as to which was
> easier, in
> <····································@v4g2000vba.googlegroups.com>:
> http://groups.google.com/group/comp.lang.lisp/msg/948007c3b7f26ec9
> You:
> > Me:
> >> Java lets you get by with a plain old
> >> import foo;
> >> by contrast.
> > I'm missing the part where that's conspicuously easier than the Lisp
> > option.
> You implied the Java way of doing things wasn't; by implication, that
> the Lisp way of doing things was the easier instead.
So, because I said that I don't think the Java way is much easier than
the Lisp way, I must be implying that the Lisp way must be much easier
than the Java way?
Yeah, your logic is flawless alright.
Sheesh,
Pillsy
Pillsy wrote:
> On May 20, 3:00 pm, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> On May 20, Seamus MacRae <··········@live.ca.nospam> wrote: [fixed]
>>>> Hey, hey, hey. Wait a minute here. Who said anything about defining a
>>>> new package?
>>> I did.
>
>> Well, that's cheating. You're not doing the same exact thing as I was,
>> which will render any comparison meaningless and result in you failing
>> to prove that Lisp does it more efficiently, which I assume is your goal.
>
> Why would I do the exact same thing
To make a fair comparison that would actually support your point?
Of course, "why would you NOT do the exact same thing?" might well be
answered with "to AVOID a fair comparison that would actually support
SEAMUS'S point".
> languages I don't use
If you don't use Java what's your purpose for participating in a Java
vs. Lisp debate?
>>>> I am interested in the "import java.util.Date;" and the "javax.sql.Date
>>>> thingyDate = thingyFromDatabase.getDate()" bits, or rather, their Lisp
>>>> equivalents, rather than the "package foo;" bit or its equivalent.
>
>>> Believe it or not, different things are grouped differently in
>>> different languages.
>
>> This remark does not seem to be relevant.
>
> Of course
>
>>>> Except this was in response to, basically, "how does Lisp do import
>>>> foo;?". Apparently it was not actually an accurate answer to the posed
>>>> question!
>
>>> That may be because [excuses, excuses]
>
>> Are you endeavoring to assist in getting to the truth of the matter of
>> which language has the more efficient syntax for imports, or are you
>> intentionally muddying the waters?
>
> The former.
Fine job so far. :P
>>> I suspect this is ultimately because Java closely intertwines a number
>>> of things that Lisp leaves separate.
>>
>> From what you said earlier, it's the other way around, with Lisp
>> intertwining package declarations and imports and Java keeping them
>> separate (though all at the top of the source file).
>
> Well, OK, then.
>
>> You implied the Java way of doing things wasn't; by implication, that
>> the Lisp way of doing things was the easier instead.
>
> your logic is flawless
Thanks. I try. :)
On 16 maio, 04:42, Seamus MacRae <··········@live.ca.nospam> wrote:
> Pillsy wrote:
> > I'm missing the part where that's conspicuously easier than the Lisp
> > option.
>
> Well, let's see...
>
> (defpackage #:my-package
> (:use #:cl #:foo))
>
> Two lines. 42 characters (not including internal linefeed and
> indentation). Nesting depth of brackets: 2.
>
> import foo;
>
> One line. 11 characters. Nesting depth of brackets: zero.
No, that code you write just once. Then in every file you just put a
(in-package :my-package).
Anyway, you are not seriously trying to argue that, if for one thing
CL use a few more characters, than CL is necessarily bad. You really
don't have good arguments.
"Seamus MacRae" wrote:
>> (defpackage #:my-package
>> (:use #:cl #:foo))
>>
>> Two lines. 42 characters (not including internal linefeed and
>> indentation). Nesting depth of brackets: 2.
>>
>> import foo;
>>
>> One line. 11 characters. Nesting depth of brackets: zero.
gugamilare wrote:
> No, that code you write just once. Then in every file you just put a
> (in-package :my-package).
> Anyway, you are not seriously trying to argue that, if for one thing
> CL use a few more characters, than CL is necessarily bad. You really
> don't have good arguments.
He really doesn't. Java is a fine language, really, as is Lisp, clearly,
regardless of what "Seamus" says or does.
He seems to understand the Java language well enough, but he doesn't make a
good apologist for it.
--
Lew
Lew wrote:
> "Seamus MacRae" wrote:
>>> (defpackage #:my-package
>>> (:use #:cl #:foo))
>>>
>>> Two lines. 42 characters (not including internal linefeed and
>>> indentation). Nesting depth of brackets: 2.
>>>
>>> import foo;
>>>
>>> One line. 11 characters. Nesting depth of brackets: zero.
>
> gugamilare wrote:
>> No, that code you write just once. Then in every file you just put a
>> (in-package :my-package).
>> Anyway, you are not seriously trying to argue that, if for one thing
>> CL use a few more characters, than CL is necessarily bad. You really
>> don't have good arguments.
>
> He really doesn't.
These insults are becoming tiresome. So is hearing people discussing me
as if I wasn't in the room.
Let's recap:
* Pillsy claims Java's imports are harder to type than Lisp's.
* Someone posts Lisp's syntax for doing an "import foo;".
* I post a note making explicit what was already obvious on inspection:
Java's is considerably easier to type.
* Everyone jumps down my throat.
What is this, National Shoot the Messenger Day?
> He seems to understand the Java language well enough, but he doesn't
> make a good apologist for it.
More personal attacks and more talking about me in the third person in
my presence!
gugamilare wrote:
> On 16 maio, 04:42, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Pillsy wrote:
>>> I'm missing the part where that's conspicuously easier than the Lisp
>>> option.
>> Well, let's see...
>>
>> (defpackage #:my-package
>> (:use #:cl #:foo))
>>
>> Two lines. 42 characters (not including internal linefeed and
>> indentation). Nesting depth of brackets: 2.
>>
>> import foo;
>>
>> One line. 11 characters. Nesting depth of brackets: zero.
>
> No
Yes. Count the characters yourself if you don't believe me.
> Anyway, you are not seriously trying to argue that, if for one thing
> CL use a few more characters, than CL is necessarily bad.
No, I'm trying to argue that if CL uses a lot more characters, many of
them shift-chords, then it is NOT true that Lisp's way of doing this is
easier. As for why I'm doing so, it's to refute Pillsy's assertion
that Java's wasn't easy.
> You really don't have good arguments.
This insult is false. If anyone doesn't have good arguments here it's
Pillsy. He's the one that started arguing about which language's import
statements were easier, after all, I just continued it.
Lew wrote:
> Seamus MacRae wrote:
>> Well, let's see...
>>
>> (defpackage #:my-package
>> (:use #:cl #:foo))
>>
>> Two lines. 42 characters (not including internal linefeed and
>> indentation). Nesting depth of brackets: 2.
>>
>> import foo;
>>
>> One line. 11 characters. Nesting depth of brackets: zero.
>
> That is such an irrelevant comparison.
Take that up with Pillsy. He's the one who asserted that Lisp's way of
doing this was easier than Java's, and thereby raised the issue that you
claim is irrelevant. I just refuted that assertion, that's all.
Seamus MacRae <··········@live.ca.nospam> writes:
> Java lets you get by with a plain old
>
> import foo;
As opposed to Lisp, where one is force to use
(import 'foo)
instead. That seems to be a mere syntax change....
--
Thomas A. Russ, USC/Information Sciences Institute
On 18 maio, 19:33, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
> > Java lets you get by with a plain old
>
> > import foo;
>
> As opposed to Lisp, where one is force to use
>
> (import 'foo)
>
> instead. That seems to be a mere syntax change....
Save your breath. Seamus seems to have completely abandoned the thread
a long time ago and Series Expansion is still responding posts from
yesterday, if he really is going to post here since it's been a long
time from his last post. He probably have given up, he was writing too
long posts. Besides, all these things that you are saying all have
already been said more than once, so writing it all over again will
not make him change his mind, and no one else in this thread is
agreeing with him.
Instead of wasting more of your time here, post other interesting
threads in c.l.l. or write one more nice library for CL using macros,
generic function and all this good stuff that they flamed here ;)
gugamilare wrote:
> Instead of wasting more of your time here, post other interesting
> threads in c.l.l. or write one more nice library for CL using macros,
> generic function and all this good stuff that they flamed here ;)
And cease posting in clj.programmer.
--
Lew
gugamilare wrote:
> On 18 maio, 19:33, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> Seamus MacRae <··········@live.ca.nospam> writes:
>>> Java lets you get by with a plain old
>>> import foo;
>> As opposed to Lisp, where one is force to use
>>
>> (import 'foo)
>>
>> instead. That seems to be a mere syntax change....
>
> Save your breath. Seamus seems to have completely abandoned the thread
Wishful thinking?
> a long time ago and Series Expansion is still responding posts from
> yesterday
How is he relevant in this particular side-branch, where he is not
participating? He seems to be concerned solely with Lisp's macro system
and uninterested in packages and imports, at least based on my skimming
of the large chunks of this thread that don't involve me and that I have
not the time to read in detail.
> He probably have given up, he was writing too long posts.
Who was?
> Besides, all these things that you are saying all have
> already been said more than once, so writing it all over again will
> not make him change his mind, and no one else in this thread is
> agreeing with him.
Series seems to agree with me to some extent, certainly about preferring
Java to Lisp. :)
I suspect many of the other comp.lang.java.programmer users prefer Java
too, and have not been convinced by you, though have not been as vocal
at calling BS on some of your less-believable claims in favor of Lisp.
Lew has been mostly just flaming anything that moves in this thread, but
at one point I distinctly saw him state a refusal to use Lisp.
> Instead of wasting more of your time here, post other interesting
> threads in c.l.l. or write one more nice library for CL using macros,
> generic function and all this good stuff that they flamed here ;)
Lew has done most of the flaming in this thread.
You're right though about the productivity of this debate. It's like
evolutionists vs. creationists: one side has logic and evidence on its
side, the other unshakable faith, and neither will budge. We'll never
give up our logic and evidence and apparently you'll never give up your
faith. And since there are no important public policy issues at stake,
your continuing to argue is pointless.
Seamus MacRae wrote:
> You're right though about the productivity of this debate. It's like
> evolutionists vs. creationists: one side has logic and evidence on its
> side, the other unshakable faith, and neither will budge. We'll never
> give up our logic and evidence and apparently you'll never give up your
> faith. And since there are no important public policy issues at stake,
> your continuing to argue is pointless.
It's ironic, really, that when you write something which seems to make
sense, you have got it exactly backwards: You are obviously the one
arguing from faith and faulty reasoning. The others know what they are
talking about, from actual experience. This applies to all topics here:
emacs, Lisp, Unix, xterms. You have no clue in any of these areas.
Lars Enderin wrote:
> Seamus MacRae wrote:
>
>> You're right though about the productivity of this debate. It's like
>> evolutionists vs. creationists: one side has logic and evidence on its
>> side, the other unshakable faith, and neither will budge. We'll never
>> give up our logic and evidence and apparently you'll never give up
>> your faith. And since there are no important public policy issues at
>> stake, your continuing to argue is pointless.
>
> It's ironic, really, that when you write something which seems to make
> sense, you have got it exactly backwards: You are obviously the one
> arguing from faith and faulty reasoning. [& further personal attacks]
Who are you, and what is the point of this unprovoked drive-by flaming?
On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
> Lars Enderin wrote:
>> Seamus MacRae wrote:
>>
>>> You're right though about the productivity of this debate. It's like
>>> evolutionists vs. creationists: one side has logic and evidence on its
>>> side, the other unshakable faith, and neither will budge. We'll never
>>> give up our logic and evidence and apparently you'll never give up
>>> your faith. And since there are no important public policy issues at
>>> stake, your continuing to argue is pointless.
>>
>> It's ironic, really, that when you write something which seems to make
>> sense, you have got it exactly backwards: You are obviously the one
>> arguing from faith and faulty reasoning. [& further personal attacks]
>
> Who are you, and what is the point of this unprovoked drive-by flaming?
You should ask yourself ``what am I doing to provoke drive-by flaming''?
I personally don't have a problem with drive-by flaming; if you keep
experiencing drive-by flaming, the common denominator in all such
situations is /you/.
Kaz Kylheku wrote:
> On 2009-05-20, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Lars Enderin wrote:
>>> Seamus MacRae wrote:
>>>
>>>> You're right though about the productivity of this debate. It's like
>>>> evolutionists vs. creationists: one side has logic and evidence on its
>>>> side, the other unshakable faith, and neither will budge. We'll never
>>>> give up our logic and evidence and apparently you'll never give up
>>>> your faith. And since there are no important public policy issues at
>>>> stake, your continuing to argue is pointless.
>>> It's ironic, really, that when you write something which seems to make
>>> sense, you have got it exactly backwards: You are obviously the one
>>> arguing from faith and faulty reasoning. [& further personal attacks]
>> Who are you, and what is the point of this unprovoked drive-by flaming?
>
> You should ask yourself ``what am I doing to provoke drive-by flaming''?
I already did, and the answer was "nothing".
Well, not quite. I am apparently arguing against the unprovable,
probably-wrong, but deeply cherished religious beliefs of some people of
faith, which does tend to get some such people angry.
But it's also not wrong. I'd also not hesitate to teach evolution in a
Bible Belt state. So sue me.
Seamus MacRae wrote:
> Lars Enderin wrote:
>> Seamus MacRae wrote:
>>
>>> You're right though about the productivity of this debate. It's like
>>> evolutionists vs. creationists: one side has logic and evidence on
>>> its side, the other unshakable faith, and neither will budge. We'll
>>> never give up our logic and evidence and apparently you'll never give
>>> up your faith. And since there are no important public policy issues
>>> at stake, your continuing to argue is pointless.
>>
>> It's ironic, really, that when you write something which seems to make
>> sense, you have got it exactly backwards: You are obviously the one
>> arguing from faith and faulty reasoning. [& further personal attacks]
>
> Who are you, and what is the point of this unprovoked drive-by flaming?
The point is to expose you as a fraud.
And unless you really are a schizo, you know me through your other
aliases: Twisted, Jerry Gerrone, etc, etc.
It must be hard work to keep pretending to be so many different persons.
On May 21, 1:28 pm, Lars Enderin <············@telia.com> wrote:
> Seamus MacRae wrote:
> > Lars Enderin wrote:
> >> Seamus MacRae wrote:
>
> >>> You're right though about the productivity of this debate. It's like
> >>> evolutionists vs. creationists: one side has logic and evidence on
> >>> its side, the other unshakable faith, and neither will budge. We'll
> >>> never give up our logic and evidence and apparently you'll never give
> >>> up your faith. And since there are no important public policy issues
> >>> at stake, your continuing to argue is pointless.
>
> >> It's ironic, really, that when you write something which seems to make
> >> sense, [numerous insults deleted]
>
> > Who are you, and what is the point of this unprovoked drive-by flaming?
>
> The point is to expose you as a [insult deleted].
> And unless you really are a schizo, you know me through your other
> aliases: Twisted, Jerry Gerrone, etc, etc.
No. Seamus is not me and none of the nasty things that you have said
or implied about me are at all true.
Jerry Gerrone wrote:
> On May 21, 1:28 pm, Lars Enderin <············@telia.com> wrote:
>> Seamus MacRae wrote:
>>> Lars Enderin wrote:
>>>> Seamus MacRae wrote:
>>>>> You're right though about the productivity of this debate. It's like
>>>>> evolutionists vs. creationists: one side has logic and evidence on
>>>>> its side, the other unshakable faith, and neither will budge. We'll
>>>>> never give up our logic and evidence and apparently you'll never give
>>>>> up your faith. And since there are no important public policy issues
>>>>> at stake, your continuing to argue is pointless.
>>>> It's ironic, really, that when you write something which seems to make
>>>> sense, [numerous insults deleted]
>>> Who are you, and what is the point of this unprovoked drive-by flaming?
>> The point is to expose you as a [insult deleted].
>> And unless you really are a schizo, you know me through your other
>> aliases: Twisted, Jerry Gerrone, etc, etc.
>
> No. Seamus is not me and none of the nasty things that you have said
> or implied about me are at all true.
I find it difficult to believe that there could exist more than one
person (in Canada) with your particular hangups and delusions. It's a
kind of Occams's Razor reasoning. The alternative, that there are
several wackos like you, is quite horrible to contemplate.
On May 22, 9:57 am, Lars Enderin <············@telia.com> wrote:
> Jerry Gerrone wrote:
> > On May 21, 1:28 pm, Lars Enderin <············@telia.com> wrote:
> >> Seamus MacRae wrote:
> >>> Lars Enderin wrote:
> >>>> Seamus MacRae wrote:
> >>>>> You're right though about the productivity of this debate. It's like
> >>>>> evolutionists vs. creationists: one side has logic and evidence on
> >>>>> its side, the other unshakable faith, and neither will budge. We'll
> >>>>> never give up our logic and evidence and apparently you'll never give
> >>>>> up your faith. And since there are no important public policy issues
> >>>>> at stake, your continuing to argue is pointless.
> >>>> It's ironic, really, that when you write something which seems to make
> >>>> sense, [numerous insults deleted]
> >>> Who are you, and what is the point of this unprovoked drive-by flaming?
> >> The point is to expose you as a [insult deleted].
> >> And unless you really are a [insult deleted], you know me through
> >> your other aliases: Twisted, Jerry Gerrone, etc, etc.
>
> > No. Seamus is not me and none of the nasty things that you have said
> > or implied about me are at all true.
>
> I find it difficult to believe that there could exist more than one
> person (in Canada) with your particular [insults deleted]. It's a
> kind of Occams's Razor reasoning. The alternative, that there are
> several [insult deleted] like you, is quite horrible to contemplate.
No, you're the crazy one.
None of the nasty things that you have said or implied about me are at
all true.
Besides, who said Seamus was in Canada? I don't see any claim of this
by anyone except you, nor any evidence to support it.
Jerry Gerrone wrote:
> On May 22, 9:57 am, Lars Enderin <············@telia.com> wrote:
>> Jerry Gerrone wrote:
>>> On May 21, 1:28 pm, Lars Enderin <············@telia.com> wrote:
>>>> Seamus MacRae wrote:
>>>>> Lars Enderin wrote:
>>>>>> Seamus MacRae wrote:
>>>>>>> You're right though about the productivity of this debate. It's like
>>>>>>> evolutionists vs. creationists: one side has logic and evidence on
>>>>>>> its side, the other unshakable faith, and neither will budge. We'll
>>>>>>> never give up our logic and evidence and apparently you'll never give
>>>>>>> up your faith. And since there are no important public policy issues
>>>>>>> at stake, your continuing to argue is pointless.
>>>>>> It's ironic, really, that when you write something which seems to make
>>>>>> sense, [numerous insults deleted]
>>>>> Who are you, and what is the point of this unprovoked drive-by flaming?
>>>> The point is to expose you as a [insult deleted].
>>>> And unless you really are a [insult deleted], you know me through
>>>> your other aliases: Twisted, Jerry Gerrone, etc, etc.
>>> No. Seamus is not me and none of the nasty things that you have said
>>> or implied about me are at all true.
>> I find it difficult to believe that there could exist more than one
>> person (in Canada) with your particular [insults deleted]. It's a
>> kind of Occams's Razor reasoning. The alternative, that there are
>> several [insult deleted] like you, is quite horrible to contemplate.
>
> No, you're the crazy one.
>
> None of the nasty things that you have said or implied about me are at
> all true.
>
> Besides, who said Seamus was in Canada? I don't see any claim of this
> by anyone except you, nor any evidence to support it.
I can give you a hint.
The email address he has chosen to supply is:
··········@live.ca.nospam
What do you think .ca is?
Arne
Lars Enderin wrote:
> Jerry Gerrone wrote:
>> On May 21, 1:28 pm, Lars Enderin <············@telia.com> wrote:
>>> Seamus MacRae wrote:
>>>> Lars Enderin wrote:
>>>>> Seamus MacRae wrote:
>>>>>> You're right though about the productivity of this debate. It's like
>>>>>> evolutionists vs. creationists: one side has logic and evidence on
>>>>>> its side, the other unshakable faith, and neither will budge. We'll
>>>>>> never give up our logic and evidence and apparently you'll never give
>>>>>> up your faith. And since there are no important public policy issues
>>>>>> at stake, your continuing to argue is pointless.
>>>>> It's ironic, really, that when you write something which seems to make
>>>>> sense, [numerous insults deleted]
>>>> Who are you, and what is the point of this unprovoked drive-by flaming?
>>> The point is to expose you as a [insult deleted].
>>> And unless you really are a schizo, you know me through your other
>>> aliases: Twisted, Jerry Gerrone, etc, etc.
>>
>> No. Seamus is not me and none of the nasty things that you have said
>> or implied about me are at all true.
>
> I find it difficult to believe that there could exist more than one
> person (in Canada) with your particular blah blah blah blah blah blah blah
Who said I was in Canada? Whoever it was ought to try asking me instead
of making wild guesses next time.
Seamus MacRae wrote:
> Lars Enderin wrote:
>> Jerry Gerrone wrote:
>>> On May 21, 1:28 pm, Lars Enderin <············@telia.com> wrote:
>>>> Seamus MacRae wrote:
>>>>> Lars Enderin wrote:
>>>>>> Seamus MacRae wrote:
>>>>>>> You're right though about the productivity of this debate. It's like
>>>>>>> evolutionists vs. creationists: one side has logic and evidence on
>>>>>>> its side, the other unshakable faith, and neither will budge. We'll
>>>>>>> never give up our logic and evidence and apparently you'll never
>>>>>>> give
>>>>>>> up your faith. And since there are no important public policy issues
>>>>>>> at stake, your continuing to argue is pointless.
>>>>>> It's ironic, really, that when you write something which seems to
>>>>>> make
>>>>>> sense, [numerous insults deleted]
>>>>> Who are you, and what is the point of this unprovoked drive-by
>>>>> flaming?
>>>> The point is to expose you as a [insult deleted].
>>>> And unless you really are a schizo, you know me through your other
>>>> aliases: Twisted, Jerry Gerrone, etc, etc.
>>>
>>> No. Seamus is not me and none of the nasty things that you have said
>>> or implied about me are at all true.
>>
>> I find it difficult to believe that there could exist more than one
>> person (in Canada) with your particular blah blah blah blah blah blah
>> blah
>
> Who said I was in Canada? Whoever it was ought to try asking me instead
> of making wild guesses next time.
Your email is ··········@live.ca.nospam.
Could be as much of a fake as yourself, of course.
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Who said I was in Canada? Whoever it was ought to try asking me
>> instead of making wild guesses next time.
>
> Your email is ··········@live.ca.nospam.
Canada's TLD is .ca, not .nospam.
(More seriously, anyone can sign up for a live.ca address at Hotmail, or
at least they could when I got mine.)
> Could be as much of a fake as yourself, of course.
This insulting quip serves no legitimate purpose in a debate over
programming language design.
Seamus MacRae wrote:
> Lars Enderin wrote:
>> Jerry Gerrone wrote:
>>> On May 21, 1:28 pm, Lars Enderin <············@telia.com> wrote:
>>>> Seamus MacRae wrote:
>>>>> Lars Enderin wrote:
>>>>>> Seamus MacRae wrote:
>>>>>>> You're right though about the productivity of this debate. It's like
>>>>>>> evolutionists vs. creationists: one side has logic and evidence on
>>>>>>> its side, the other unshakable faith, and neither will budge. We'll
>>>>>>> never give up our logic and evidence and apparently you'll never
>>>>>>> give
>>>>>>> up your faith. And since there are no important public policy issues
>>>>>>> at stake, your continuing to argue is pointless.
>>>>>> It's ironic, really, that when you write something which seems to
>>>>>> make
>>>>>> sense, [numerous insults deleted]
>>>>> Who are you, and what is the point of this unprovoked drive-by
>>>>> flaming?
>>>> The point is to expose you as a [insult deleted].
>>>> And unless you really are a schizo, you know me through your other
>>>> aliases: Twisted, Jerry Gerrone, etc, etc.
>>>
>>> No. Seamus is not me and none of the nasty things that you have said
>>> or implied about me are at all true.
>>
>> I find it difficult to believe that there could exist more than one
>> person (in Canada) with your particular blah blah blah blah blah blah
>> blah
>
> Who said I was in Canada? Whoever it was ought to try asking me instead
> of making wild guesses next time.
You did.
Check the email address you are posting.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Who said I was in Canada? Whoever it was ought to try asking me
>> instead of making wild guesses next time.
>
> You did.
I did not.
> Check the email address you are posting.
It indicates that the email provider has servers in Canada. Since it is
a free web-based email, however, the location of the servers says little
about where any particular user is located.
Lars Enderin wrote:
> Seamus MacRae wrote:
>> Lars Enderin wrote:
>>> Seamus MacRae wrote:
>>>
>>>> You're right though about the productivity of this debate. It's like
>>>> evolutionists vs. creationists: one side has logic and evidence on
>>>> its side, the other unshakable faith, and neither will budge. We'll
>>>> never give up our logic and evidence and apparently you'll never
>>>> give up your faith. And since there are no important public policy
>>>> issues at stake, your continuing to argue is pointless.
>>>
>>> It's ironic, really, that when you write something which seems to
>>> make sense, you have got it exactly backwards: You are obviously the
>>> one arguing from faith and faulty reasoning. [& further personal
>>> attacks]
>>
>> Who are you, and what is the point of this unprovoked drive-by flaming?
>
> The point is to expose you as a fraud.
Such an effort is doomed to failure, since I'm not one. Your time is
therefore better spent elsewhere.
> And unless you really are a schizo, you know me through your other
> aliases: Twisted, Jerry Gerrone, etc, etc.
Are you barvy? I have no such aliases.
> It must be hard work to keep pretending to be so many different persons.
Statement assumes a premise that's not accepted as true. It may as well
be ignored.
On May 22, 5:45 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Lars Enderin wrote:
> > Seamus MacRae wrote:
> >> Lars Enderin wrote:
> >>> Seamus MacRae wrote:
>
> >>>> You're right though about the productivity of this debate. It's like
> >>>> evolutionists vs. creationists: one side has logic and evidence on
> >>>> its side, the other unshakable faith, and neither will budge. We'll
> >>>> never give up our logic and evidence and apparently you'll never
> >>>> give up your faith. And since there are no important public policy
> >>>> issues at stake, your continuing to argue is pointless.
>
> >>> It's ironic, really, that when you write something which seems to
> >>> make sense, [numerous insults deleted]
>
> >> Who are you, and what is the point of this unprovoked drive-by flaming?
>
> > The point is to expose you as a [insult deleted].
>
> Such an effort is doomed to failure, since I'm not one. Your time is
> therefore better spent elsewhere.
>
> > And unless you really are a [insult deleted], you know me through your
> > other aliases: Twisted, Jerry Gerrone, etc, etc.
No. Seamus is not me and none of the nasty things that Lars has said
or implied about me are at all true.
> > [calls me a liar]
No, Lars is the liar.
None of the nasty things that Lars has said or implied about me are at
all true.
(Why can't people in this particular newsgroup ever have an argument
without someone eventually dragging my name into it??!)
Jerry Gerrone wrote:
> On May 22, 5:45 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Lars Enderin wrote:
>>> Seamus MacRae wrote:
>>>> Lars Enderin wrote:
>>>>> Seamus MacRae wrote:
>>>>>> You're right though about the productivity of this debate. It's like
>>>>>> evolutionists vs. creationists: one side has logic and evidence on
>>>>>> its side, the other unshakable faith, and neither will budge. We'll
>>>>>> never give up our logic and evidence and apparently you'll never
>>>>>> give up your faith. And since there are no important public policy
>>>>>> issues at stake, your continuing to argue is pointless.
>>>>> It's ironic, really, that when you write something which seems to
>>>>> make sense, [numerous insults deleted]
>>>> Who are you, and what is the point of this unprovoked drive-by flaming?
>>> The point is to expose you as a [insult deleted].
>> Such an effort is doomed to failure, since I'm not one. Your time is
>> therefore better spent elsewhere.
>>
>>> And unless you really are a [insult deleted], you know me through your
>>> other aliases: Twisted, Jerry Gerrone, etc, etc.
>
> No. Seamus is not me and none of the nasty things that Lars has said
> or implied about me are at all true.
>
>>> [calls me a liar]
>
> No, Lars is the liar.
>
> None of the nasty things that Lars has said or implied about me are at
> all true.
What the fuck is all this about? My post already said Lars was off his
rocker. This seems rather redundant. And I'm not sure I care for the
vaguely admonishing tone, "no this, no that" as if I shouldn't have even
quoted Lars's stupidities. Though by doing so I do the world a service,
ensuring that his barvy meanderings will be preserved as a part of the
public record so everyone can see what a wacko he is, even if he cancels
his post and gets Google to delete it from their archive.
> (Why can't people in this particular newsgroup ever have an argument
> without someone eventually dragging my name into it??!)
I just want to know why they apparently can't have an argument without
getting nasty and making it personal!
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Java lets you get by with a plain old
>>
>> import foo;
>
> As opposed to Lisp, where one is force to use
>
> (import 'foo)
>
> instead. That seems to be a mere syntax change....
Nobody cares.
--
Lew
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Java lets you get by with a plain old
>>
>> import foo;
>
> As opposed to Lisp, where one is force to use
>
> (import 'foo)
>
> instead. That seems to be a mere syntax change....
But the other guy said it was
(defpackage #:my-package
(:use #:cl #:foo))
Which is it?
I do find it irritating that you keep contradicting one another. It's
hard to argue against (or for!) an incoherent position.
Seamus MacRae <··········@live.ca.nospam> writes:
> Thomas A. Russ wrote:
> > Seamus MacRae <··········@live.ca.nospam> writes:
> >
> >> Java lets you get by with a plain old
> >>
> >> import foo;
> > As opposed to Lisp, where one is force to use
> > (import 'foo)
> > instead. That seems to be a mere syntax change....
>
> But the other guy said it was
>
> (defpackage #:my-package
> (:use #:cl #:foo))
>
> Which is it?
>
> I do find it irritating that you keep contradicting one another. It's
> hard to argue against (or for!) an incoherent position.
Either one. The difference is similar to the difference between
import javax.swing.JPanel
and
import javax.swing.*;
If you USE a package, it automatically imports all of the exported
symbols of that package. IMPORT just imports the specific symbol.
Both of these forms can be used either as standalone or as options in
DEFPACKAGE.
So, the positions aren't incoherent, but rather complementary.
Flexibility is one of the keys to understanding the lisp design
philosophy.
There's usually more than one way to do most things. We think that's
good.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>> Thomas A. Russ wrote:
>>> Seamus MacRae <··········@live.ca.nospam> writes:
>>>
>>>> Java lets you get by with a plain old
>>>>
>>>> import foo;
>>> As opposed to Lisp, where one is force to use
>>> (import 'foo)
>>> instead. That seems to be a mere syntax change....
>> But the other guy said it was
>>
>> (defpackage #:my-package
>> (:use #:cl #:foo))
>>
>> Which is it?
>>
>> I do find it irritating that you keep contradicting one another. It's
>> hard to argue against (or for!) an incoherent position.
>
> [five paragraphs amounting to "liar, liar, pants on fire!"]
Hanging on a telephone wire. Caught you once again trying to sneak one
under the radar. So much for any pretensions you may have had to be
engaging in an honest debate, hmm?
Series Expansion <·······@gmail.com> writes:
I'd really kill my parents if they gave me such a name...
[snip]
> I just explained why the package system won't.
No, you didn't.
> Adding new classes in
> their own packages? No problem, the package system can distinguish
> foo.String from bar.String. Adding new methods to an existing class,
> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
> foo.String.doIt()? They have the same method name, are methods of
> classes with the same name, and the classes are in the same package.
> As far as the compiler is concerned, they are the same.
No, not in CLOS. You better read up on CLOS before you post such crap.
> The package
> system cannot distinguish them unless we add another layer of
> namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
> and foo.String.quux.doIt() instead of just foo.String.doIt() as the
> fully-qualified names. And now we're deep in migraine-headache
> territory, without oar or compass...
See my comment above.
[snip]
>
> So, basically, you're saying that the way you avoid the name clash is
> to make baz's String.doIt() and quux's String.doIt() private.
No.
> Of
> course, this now means that anyone who wants their own code to call a
> String.doIt() has to roll their own and can't get a canned one from a
> library. Because if they do, and there's multiple incompatible
> libraries that provide this, then we're back to square one and name
> clashes.
No.
>
> Of course, the best way to avoid multiple incompatible libraries is to
> have commonly desired functionality built into the standard library.
Ah - who's the Standard Committee for Java again?
> And then letting third parties create (non-private, at least) methods
> in your classes is unnecessary.
>
> Of course letting them create private ones is also tricky. They need
> to be a new kind of private: private to the module that defines them,
> NOT to the class they're defined in (now that those are different).
No.
> Now the private/public/local/global scope system gets more
> complicated.
No need to. Just doesn't happen!
>
> Everywhere I look I see tradeoffs here.
Yep, I do too in Java. No so in Common Lisp. There's freedom and
liberty. Not everybody knows how to use this to one's benefit.
>
> Ah, I love the smell of boilerplate code in the morning!
Ah, I love the smell of efficiency in coding in Lisp all day long ...
Frank
On May 16, 3:05 am, Frank GOENNINGER <······@googlemail.com> wrote:
> Series Expansion <·······@gmail.com> writes:
>
> I'd really kill my parents if they gave me such a name...
>
> [snip]
>
> > I just explained why the package system won't.
>
> No, you didn't.
Yes, I did.
> No, not in CLOS. You better read up on CLOS before you post such crap.
How rude.
> [snip]
>
> No.
>
> No.
>
> No.
>
> No need to. Just doesn't happen!
Denial is a wonderful thing.
What was the next stage again? Oh, crap, it was anger, wasn't it?
> > Everywhere I look I see tradeoffs here.
>
> Yep, I do too in Java. No so in Common Lisp. There's freedom and
> liberty.
The mantra of a man of faith and deep patriotism. Not, however, a
reasoned argument of any kind.
> > Ah, I love the smell of boilerplate code in the morning!
>
> Ah, I love the smell of efficiency in coding in Lisp all day long ...
It takes that long?
On 16 maio, 17:23, Series Expansion <·······@gmail.com> wrote:
> On May 16, 3:05 am, Frank GOENNINGER <······@googlemail.com> wrote:
>
> > Series Expansion <·······@gmail.com> writes:
>
> > I'd really kill my parents if they gave me such a name...
>
> > [snip]
>
> > > I just explained why the package system won't.
>
> > No, you didn't.
>
> Yes, I did.
>
> > No, not in CLOS. You better read up on CLOS before you post such crap.
>
> How rude.
>
> > [snip]
>
> > No.
>
> > No.
>
> > No.
>
> > No need to. Just doesn't happen!
>
> Denial is a wonderful thing.
You are being hypocrite. You have just ignored everything he explained
about the package system and how methods are defined, and complains
about him denying something you said. Please not that everything he
said "no" to are things that are no longer valid IF you understand his
argument - which seems almost impossible.
> What was the next stage again? Oh, crap, it was anger, wasn't it?
Yes. For now he is just denying that you don't have idea of what you
are talking about, and that actually you can understand what he is
trying to explain. It will take a while until he realizes that
convincing you is just hopeless because you ignore or misinterpret
every damn good point we make.
> > > Ah, I love the smell of boilerplate code in the morning!
>
> > Ah, I love the smell of efficiency in coding in Lisp all day long ...
>
> It takes that long?
Wow, I am impressed. You are so convincing with all these arguments.
You know what? I will not waste one more precious minute of my time
trying to explain everything to you. If you want to continue this
debate, read the ENTIRE book which is here: http://www.gigamonkeys.com/book
, following everything like the newbie _in Lisp_ that you are. Than we
can continue this conversation.
On May 16, 4:52 pm, gugamilare <··········@gmail.com> wrote:
> On 16 maio, 17:23, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 3:05 am, Frank GOENNINGER <······@googlemail.com> wrote:
> > > No.
>
> > > No.
>
> > > No.
>
> > > No need to. Just doesn't happen!
>
> > Denial is a wonderful thing.
>
> You are being hypocrite.
You are being rude.
> You have just ignored everything he explained
I don't consider "No, no, no, no" to be an explanation. Sorry.
> > What was the next stage again? Oh, crap, it was anger, wasn't it?
>
> Yes.
As evidenced by the flame I'm now replying to.
> you don't have idea of what you are talking about
That's a good example of such flamage, yes.
> convincing you is just hopeless because you ignore or misinterpret
> every damn good point we make.
And look! Here's some more anger. Let me check that guide to see what
the next stage is. Ah, here it is -- withdrawal. I guess you'll be
shutting up soon, then.
(*What* good points you make? I've yet to see any.)
> > > > Ah, I love the smell of boilerplate code in the morning!
>
> > > Ah, I love the smell of efficiency in coding in Lisp all day long ...
>
> > It takes that long?
>
> Wow, I am impressed.
Why, thank you.
> You know what? I will not waste one more precious minute of my time
> trying to explain everything to you.
And there it is, right on cue -- withdrawal. And the stage after
*that* is ...
Hoo boy. Apparently it's acceptance! I guess the argument is finally
almost over then. :)
> If you want to continue this debate, read the ENTIRE book
If you'll pay for it (shipping and tax included), I'll be happy to.
Otherwise, not interested.
On May 17, 9:59 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:52 pm, gugamilare <··········@gmail.com> wrote:
>
> > On 16 maio, 17:23, Series Expansion <·······@gmail.com> wrote:
> > > On May 16, 3:05 am, Frank GOENNINGER <······@googlemail.com> wrote:
> > > > No.
>
> > > > No.
>
> > > > No.
>
> > > > No need to. Just doesn't happen!
>
> > > Denial is a wonderful thing.
>
> > You are being hypocrite.
>
> You are being rude.
>
> > You have just ignored everything he explained
>
> I don't consider "No, no, no, no" to be an explanation. Sorry.
>
> > > What was the next stage again? Oh, crap, it was anger, wasn't it?
>
> > Yes.
>
> As evidenced by the flame I'm now replying to.
>
> > you don't have idea of what you are talking about
>
> That's a good example of such flamage, yes.
>
> > convincing you is just hopeless because you ignore or misinterpret
> > every damn good point we make.
>
> And look! Here's some more anger. Let me check that guide to see what
> the next stage is. Ah, here it is -- withdrawal. I guess you'll be
> shutting up soon, then.
>
> (*What* good points you make? I've yet to see any.)
I think there have been some good explanations in some of my threads
explaining how Emacs IS A GRAPHICAL SYSTEM, and is much much much much
much much more than just a text editor. 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.
>
> > > > > Ah, I love the smell of boilerplate code in the morning!
>
> > > > Ah, I love the smell of efficiency in coding in Lisp all day long ...
>
> > > It takes that long?
>
> > Wow, I am impressed.
>
> Why, thank you.
>
> > You know what? I will not waste one more precious minute of my time
> > trying to explain everything to you.
>
> And there it is, right on cue -- withdrawal. And the stage after
> *that* is ...
>
> Hoo boy. Apparently it's acceptance! I guess the argument is finally
> almost over then. :)
>
> > If you want to continue this debate, read the ENTIRE book
>
> If you'll pay for it (shipping and tax included), I'll be happy to.
> Otherwise, not interested.
Dude, it's been said 5 or 6 times already --
a) it's free
b) we've pointed you to a specific chapter to look at
c) it's right here -- the ENTIRE BOOK FOR FREE. http://www.gigamonkeys.com/book/
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.
- Adlai
gugamilare wrote:
>>> If you want to continue this debate, read the ENTIRE book
Series Expansion wrote:
>> If you'll pay for it (shipping and tax included), I'll be happy to.
>> Otherwise, not interested.
While this answer tells us that "Series" *will* read the book, I suspect he
won't keep his word.
Adlai wrote:
> Dude, it's been said 5 or 6 times already --
>
> a) it's free
>
> b) we've pointed you to a specific chapter to look at
>
> c) it's right here -- the ENTIRE BOOK FOR FREE.
> <http://www.gigamonkeys.com/book/>
> 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.
"Series" is a troll. He doesn't want to learn anything. He just wants to
pepper you with foul-mouthed trash while claiming that you're the one getting
personal.
I got personal with him explicitly and he didn't scold me for it, I notice.
What, don't I deserve a four-letter word?
Of course, I wasn't defending Lisp, either.
I'm going to read the FREE (including shipping and tax) book.
Then I'm going to continue not using Lisp.
--
Lew
Lew <·····@lewscanon.com> writes:
> gugamilare wrote:
>>>> If you want to continue this debate, read the ENTIRE book
>
> Series Expansion wrote:
>>> If you'll pay for it (shipping and tax included), I'll be happy to.
>>> Otherwise, not interested.
>
> While this answer tells us that "Series" *will* read the book, I
> suspect he won't keep his word.
>
> Adlai wrote:
>> Dude, it's been said 5 or 6 times already --
>>
>> a) it's free
>>
>> b) we've pointed you to a specific chapter to look at
>>
>> c) it's right here -- the ENTIRE BOOK FOR
>> FREE. <http://www.gigamonkeys.com/book/>
>> 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.
>
> "Series" is a troll. He doesn't want to learn anything. He just
> wants to pepper you with foul-mouthed trash while claiming that you're
> the one getting personal.
>
> I got personal with him explicitly and he didn't scold me for it, I
> notice. What, don't I deserve a four-letter word?
>
> Of course, I wasn't defending Lisp, either.
>
> I'm going to read the FREE (including shipping and tax) book.
>
> Then I'm going to continue not using Lisp.
First read it. Then do yourself a favor and try the examples in just the
first three chapters. And then decide if you're going to continue to not
using Lisp.
Thanks, Lew.
Cheers
Frank
Frank GOENNINGER wrote:
> First read it. Then do yourself a favor and try the examples in just the
> first three chapters. And then decide if you're going to continue to not
> using Lisp.
Please do me a favor and discuss Lisp in the Lisp newsgroup.
--
Lew
Lew <·····@lewscanon.com> writes:
> Frank GOENNINGER wrote:
>> First read it. Then do yourself a favor and try the examples in just the
>> first three chapters. And then decide if you're going to continue to not
>> using Lisp.
>
> Please do me a favor and discuss Lisp in the Lisp newsgroup.
Come on, Lew. You understand perfectly well that this is not relevant to
Lispers - but relevant to all the other threads and their readers in
other groups than c.l.l - I therefore was cross-posting. But enough of
that now. We all should know when enough is just enough. ;-)
Thanks for being patient and honest.
Frank
On May 17, 5:40 pm, Frank GOENNINGER <······@googlemail.com> wrote:
> Lew <·····@lewscanon.com> writes:
> > Please do me a favor and discuss Lisp in the Lisp newsgroup.
>
> Thanks for being patient and honest.
This statement is peculiar, seeing as how "Lew" has been neither.
On May 17, 12:42 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> >> If you'll pay for it (shipping and tax included), I'll be happy to.
> >> Otherwise, not interested.
>
> While this answer tells us that "Series" *will* read the book, I suspect he
> won't keep his word.
That is incorrect.
> Adlai wrote:
> > 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.
>
> "Series" is a troll. He doesn't want to learn anything. He just wants to
> pepper you with foul-mouthed trash while claiming that you're the one getting
> personal.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Adlai.
> I got personal with him explicitly and he didn't scold me for it, I notice.
That is incorrect.
> What, don't I deserve a four-letter word?
No. You deserve remedial lessons in logic, particularly in
understanding why the ad hominem fallacy is a fallacy.
> Of course, I wasn't defending Lisp, either.
Indeed. Rather, you appear to be attacking both sides in a remarkable
display of unreason.
On May 17, 12:42 pm, Lew <·····@lewscanon.com> wrote:
> Adlai wrote:
> > Series Expansion wrote:
> >> gugamilare wrote:
> >>> If you want to continue this debate, read the ENTIRE book
> >> If you'll pay for it (shipping and tax included), I'll be happy to.
> >> Otherwise, not interested.
>
> While this answer tells us that "Series" *will* read the book
It does not. [attributions restored to normal]
> I suspect he won't keep his word.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > 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.
>
> "Series" is a troll. He doesn't want to learn anything. He just wants to
> pepper you with foul-mouthed trash while claiming that you're the one getting
> personal.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Adlai.
I have had precisely two emotional outbursts with use of expletives.
In one I referred to someone as a "dipshit" and in the other I
employed the F-word.
You have had a much larger number of personal attack posts in this
thread, far more than a mere two. So have several other participants.
You are a hypocrite.
(Okay, make that three from me.)
> I got personal with him explicitly and he didn't scold me for it, I notice.
Sure I did.
> What, don't I deserve a four-letter word?
You deserve remedial lessons in logic, particularly to understand why
the ad hominem fallacy is a fallacy.
> Of course, I wasn't defending Lisp, either.
It would seem that you have instead been attacking both sides, for
reasons unknown.
(Reposted after original was silently redirected to hide my response
from comp.lang.java.programmer. "Lew", your perfidy knows no bounds.)
On May 17, 3:13 am, Adlai <·········@gmail.com> wrote:
> On May 17, 9:59 am, Series Expansion <·······@gmail.com> wrote:
> > (*What* good points you make? I've yet to see any.)
>
> 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.
> > > You know what? I will not waste one more precious minute of my time
(yet the thread continues to grow apace, with the author of the above
line prominent among the authors of the newest posts)
> > > If you want to continue this debate, read the ENTIRE book
>
> > If you'll pay for it (shipping and tax included), I'll be happy to.
> > Otherwise, not interested.
>
> 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.
On 17 maio, 03:59, Series Expansion <·······@gmail.com> wrote:
> (*What* good points you make? I've yet to see any.)
You already saw them. The only thing is that you don't understand them
because you don't understand Lisp.
gugamilare wrote:
> On 17 maio, 03:59, Series Expansion <·······@gmail.com> wrote:
>> (*What* good points you make? I've yet to see any.)
>
> You already saw them. The only thing is that you don't understand them
> because you don't understand Lisp.
You fed the troll.
--
Lew
On May 17, 12:42 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > On 17 maio, 03:59, Series Expansion <·······@gmail.com> wrote:
> >> (*What* good points you make? I've yet to see any.)
>
> > You already saw them. The only thing is that you don't understand them
> > because you don't understand Lisp.
>
> You fed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and gugamilare.
On May 17, 12:42 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > On 17 maio, 03:59, Series Expansion <·······@gmail.com> wrote:
> >> (*What* good points you make? I've yet to see any.)
>
> > You already saw them. The only thing is that you don't understand them
> > because you don't understand Lisp.
>
> You fed the troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and gugamilare.
(Reposted after original was silently redirected to hide my response
from comp.lang.java.programmer. "Lew", your perfidy knows no bounds.)
On May 17, 3:23 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 03:59, Series Expansion <·······@gmail.com> wrote:
>
> > (*What* good points you make? I've yet to see any.)
>
> You already saw them. The only thing is that you don't understand them
> because you don't understand Lisp.
I still have yet to see any. Certainly the above-quoted personal
attack fails to impress.
Series Expansion <·······@gmail.com> writes:
> On May 16, 3:05�am, Frank GOENNINGER <······@googlemail.com> wrote:
>> Series Expansion <·······@gmail.com> writes:
>>
>> I'd really kill my parents if they gave me such a name...
>>
>> [snip]
>>
>> > I just explained why the package system won't.
>>
>> No, you didn't.
>
> Yes, I did.
>
>> No, not in CLOS. You better read up on CLOS before you post such crap.
>
> How rude.
>
>> [snip]
>>
>> No.
>>
>> No.
>>
>> No.
>>
>> No need to. Just doesn't happen!
>
> Denial is a wonderful thing.
This is not denial. It's damage control. We wouldn't want to let
innocent nearby readers believe your lies.
--
__Pascal Bourguignon__
On May 16, 5:02 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> > Denial is a wonderful thing.
>
> This is not denial. It's damage control. We wouldn't want to let
> innocent nearby readers believe your lies.
That's it. Flame on, fuckwad.
I am not a liar, and I resent you publicly badmouthing me by calling
me one. Your behavior is reprehensible and you appear to be an
asshole. Good day, sir.
Damn. I'm way out of practice being genuinely rude. :)
Series Expansion wrote:
> On May 16, 5:02 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>>> Denial is a wonderful thing.
>> This is not denial. It's damage control. We wouldn't want to let
>> innocent nearby readers believe your lies.
>
> That's it. Flame on, fuckwad.
Potty mouth. Potty mouth. Even if you are describing yourself.
> I am not a liar, and I resent you publicly badmouthing me by calling
You are, too, a liar. Liar, liar, pants on fire, "Series".
> me one. Your behavior is reprehensible and you appear to be an
> asshole. Good day, sir.
You don't just appear to be one, you genuinely are one. And a hypocrite and a
liar, too, Series.
> Damn. I'm way out of practice being genuinely rude. :)
Hah, good one. Every word out of your keyboard has been genuinely rude, you liar.
You're a liar, Series Expansion.
--
Lew
On May 17, 12:45 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > On May 16, 5:02 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >>> Denial is a wonderful thing.
> >> This is not denial. It's damage control. We wouldn't want to let
> >> innocent nearby readers believe your lies.
>
> > That's it. Flame on, fuckwad.
>
> Potty mouth. Potty mouth. Even if you are describing yourself.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
My outburst was in response to the extreme provocation of being
explicitly called a liar in a public forum. Your much greater volume
of mouth foaming is in response to what? Seeing a third party, Pascal,
called a name that nobody is likely to take seriously? Actually no
since you have exhibited this behavior since a considerably earlier
point in time, before any post of mine that might either have directly
provoked you or more indirectly earned your ire.
> > I am not a liar, and I resent you publicly badmouthing me by calling
>
> You are, too, a liar. Liar, liar, pants on fire, "Series".
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew". Moreover, your latest ones are
particularly childish. I therefore revise downwards my previous
estimate of the youngest age present here, from "below legal drinking
age" to "kindergarten".
> > me one. Your behavior is reprehensible and you appear to be an
> > asshole. Good day, sir.
>
> You don't just appear to be one, you genuinely are one. And a hypocrite and a
> liar, too, Series.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > Damn. I'm way out of practice being genuinely rude. :)
>
> Hah, good one. Every word out of your keyboard has been genuinely rude, you liar.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> You're a liar, Series Expansion.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
On May 17, 12:45 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > On May 16, 5:02 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >>> Denial is a wonderful thing.
> >> This is not denial. It's damage control. We wouldn't want to let
> >> innocent nearby readers believe your lies.
>
> > That's it. Flame on, fuckwad.
>
> Potty mouth. Potty mouth. Even if you are describing yourself.
I am not.
Your tiresome personal attacks do not constitute rational arguments in
favor of either Lisp or Java, "Lew" and Pascal.
> > I am not a liar, and I resent you publicly badmouthing me by calling
>
> You are, too, a liar. Liar, liar, pants on fire, "Series".
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew". However, they have inspired me
to revise downward my estimated upper bound of the lowest age present
in this thread from "below legal drinking age" to "kindergarten".
> > me one. Your behavior is reprehensible and you appear to be an
> > asshole. Good day, sir.
>
> You don't just appear to be one, you genuinely are one. And a hypocrite and a
> liar, too, Series.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > Damn. I'm way out of practice being genuinely rude. :)
>
> Hah, good one. Every word out of your keyboard has been genuinely rude, you liar.
>
> You're a liar, Series Expansion.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
(Reposted after original was silently redirected to hide my response
from comp.lang.java.programmer. "Lew", your perfidy knows no bounds.)
From: Thomas A. Russ
Subject: Re: macros (was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <ymi4ovio1na.fsf@blackcat.isi.edu>
Series Expansion <·······@gmail.com> writes:
> On May 15, 3:35��pm, gugamilare <··········@gmail.com> wrote:
> >
> > You are once again flaming what you do not understand.
>
> I'm not the one doing the flaming here at all.
I'll grant that you are not flaming. You are just blathering. You are
just spouting idiotic comments about technology that you clearly do not
understand.
> > The CL package system will solve the name collision with no harm done.
>
> I just explained why the package system won't. Adding new classes in
> their own packages? No problem, the package system can distinguish
> foo.String from bar.String. Adding new methods to an existing class,
> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
> foo.String.doIt()? They have the same method name, are methods of
> classes with the same name, and the classes are in the same package.
> As far as the compiler is concerned, they are the same. The package
> system cannot distinguish them unless we add another layer of
> namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
> and foo.String.quux.doIt() instead of just foo.String.doIt() as the
> fully-qualified names. And now we're deep in migraine-headache
> territory, without oar or compass...
Well, the above paragraph is prima facie evidence that you have a
profound ignorance of how the Lisp package system works. You also have
a profound ignorance of how the Lisp object system works. And taken
together, those sources of ignorance lead you to raise objections that
are absolutely incorrect.
First of all, methods don't belong to classes. Period.
Second of all, classes don't establish any sort of namepsace. Period.
The only way in Lisp for you to have "classes of the same name" is for
them to be exactly the same class, as in EQ classes. To put this into
Java terms for you, the confusion you are imagining would be akin to
saying that one could have two classses java.lang.String and
java.lang.String which are different, and thus confusable. You can't,
since they are the same classes.
So the Lisp package system is quite capable of easily distinguishing
between different generic functions when you seek to invoke them, or add
methods to them. In fact, adding new methods to existing generic
functions is one of the great strengths of the Common Lisp language.
And it all works fine, and has done so ever since the Common Lisp
specification was formulated in 1994. In fact, it was never a problem
even before the specification was created, so there has been more than
15 years of work that has, amazingly enough, never run into the problem
that you in your lack of knowledge so blithely assert.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 18, 8:45 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> I'll grant that you are not flaming. You are just blathering. You are
> just spouting idiotic comments about technology that you clearly do not
> understand.
I prefer not to participate in Usenet pissing matches, but I sometimes
get my jollies by reading along. In this case I gotta say, with
Series the laughs just never stop.
I fear you're wasting your breath, though.
-- Scott
On May 18, 9:29 am, Scott Burson <········@gmail.com> wrote:
> On May 18, 8:45 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
>
>
> > I'll grant that you are not flaming. You are just blathering. You are
> > just spouting idiotic comments about technology that you clearly do not
> > understand.
>
> I prefer not to participate in Usenet pissing matches, but I sometimes
> get my jollies by reading along. In this case I gotta say, with
> Series the laughs just never stop.
>
> I fear you're wasting your breath, though.
I agree on both counts. This weekend has been very entertaining.
It's like the standard formula for SitComs on TV, where the
protagonist gets the entirely wrong idea about some reality, and the
interactions with the antagonists generates the humor to the delight
of the audience.
However, I'd give this comedy only 3 out of 5 stars, for two reasons:
first, it is too long, and second, such a sitcom is much funnier if
the antagonists would only misunderstand the protagonist as well; then
the double-meanings of the conversations would take on a whole new
level of hilarity. But unfortunately, this isn't happening here, and
thus the lower rating...
Duane
·····@franz.com wrote:
> However, I'd give this comedy only 3 out of 5 stars, for two reasons:
> first, it is too long,
And yet you lengthen it.
--
Lew
On May 18, 5:43 pm, ·····@franz.com wrote:
> On May 18, 9:29 am, Scott Burson <········@gmail.com> wrote:
>
> > On May 18, 8:45 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > > I'll grant that you are not flaming. You are just blathering. You are
> > > just spouting idiotic comments about technology that you clearly do not
> > > understand.
>
> > I prefer not to participate in Usenet pissing matches, but I sometimes
> > get my jollies by reading along. In this case I gotta say, with
> > Series the laughs just never stop.
>
> > I fear you're wasting your breath, though.
>
> I agree on both counts. This weekend has been very entertaining.
> It's like the standard formula for SitComs on TV, where the
> protagonist gets the entirely wrong idea about some reality, and the
> interactions with the antagonists generates the humor to the delight
> of the audience.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Duane, Scott, and Thomas.
[rest deleted]
On May 20, 12:05 pm, Series Expansion <·······@gmail.com> wrote:
> On May 18, 5:43 pm, ·····@franz.com wrote:
>
>
>
> > On May 18, 9:29 am, Scott Burson <········@gmail.com> wrote:
>
> > > On May 18, 8:45 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > > > I'll grant that you are not flaming. You are just blathering. You are
> > > > just spouting idiotic comments about technology that you clearly do not
> > > > understand.
>
> > > I prefer not to participate in Usenet pissing matches, but I sometimes
> > > get my jollies by reading along. In this case I gotta say, with
> > > Series the laughs just never stop.
>
> > > I fear you're wasting your breath, though.
>
> > I agree on both counts. This weekend has been very entertaining.
> > It's like the standard formula for SitComs on TV, where the
> > protagonist gets the entirely wrong idea about some reality, and the
> > interactions with the antagonists generates the humor to the delight
> > of the audience.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, Duane, Scott, and Thomas.
>
> [rest deleted]
Ah, yes, the attacks. If you're so tired of them, why don't you stop
them?
Duane
On May 20, 3:48 pm, ·····@franz.com wrote:
> On May 20, 12:05 pm, Series Expansion <·······@gmail.com> wrote:
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, Duane, Scott, and Thomas.
>
> > [rest deleted]
>
> Ah, yes, the attacks. If you're so tired of them, why don't you stop
> them?
Because they are not mine to stop. As was noted in the post to which
you are replying, some of them were yours and others were by Scott and
Thomas. They are the ones you should ask to stop attacking me, after,
of course, stopping doing so yourself.
From: Thomas A. Russ
Subject: Re: macros (was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <ymiljoukou2.fsf@blackcat.isi.edu>
Scott Burson <········@gmail.com> writes:
> On May 18, 8:45��am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> >
> > I'll grant that you are not flaming. ��You are just blathering. ��You are
> > just spouting idiotic comments about technology that you clearly do not
> > understand.
>
> I prefer not to participate in Usenet pissing matches, but I sometimes
> get my jollies by reading along. In this case I gotta say, with
> Series the laughs just never stop.
>
> I fear you're wasting your breath, though.
Undoubtedly. But I figured I shouldn't waste a bon mot.
But I have tired of this as well.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 18, 6:50 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Scott Burson <········@gmail.com> writes:
> > On May 18, 8:45Ž am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > > I'll grant that you are not flaming. Ž You are just blathering. Ž You are
> > > just spouting idiotic comments about technology that you clearly do not
> > > understand.
>
> > I prefer not to participate in Usenet pissing matches, but I sometimes
> > get my jollies by reading along. In this case I gotta say, with
> > Series the laughs just never stop.
>
> > I fear you're wasting your breath, though.
>
> Undoubtedly. But I figured I shouldn't waste a bon mot.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas and Scott.
On May 18, 12:29 pm, Scott Burson <········@gmail.com> wrote:
> On May 18, 8:45 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
>
>
> > I'll grant that you are not flaming. You are just blathering. You are
> > just spouting idiotic comments about technology that you clearly do not
> > understand.
>
> I prefer not to participate in Usenet pissing matches, but I sometimes
> get my jollies by reading along. In this case I gotta say, with
> Series the laughs just never stop.
>
> I fear you're wasting your breath, though.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Scott and Thomas.
Thomas A. Russ wrote:
> Series Expansion <·······@gmail.com> writes:
>> I just explained why the package system won't. Adding new classes in
>> their own packages? No problem, the package system can distinguish
>> foo.String from bar.String. Adding new methods to an existing class,
>> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
>> foo.String.doIt()? They have the same method name, are methods of
>> classes with the same name, and the classes are in the same package.
>> As far as the compiler is concerned, they are the same. The package
>> system cannot distinguish them unless we add another layer of
>> namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
>> and foo.String.quux.doIt() instead of just foo.String.doIt() as the
>> fully-qualified names. And now we're deep in migraine-headache
>> territory, without oar or compass...
>
> Well, the above paragraph is prima facie evidence that you have a
> profound ignorance of how the Lisp package system works. You also have
> a profound ignorance of how the Lisp object system works. And taken
> together, those sources of ignorance lead you to raise objections that
> are absolutely incorrect.
>
> First of all, methods don't belong to classes. Period.
> Second of all, classes don't establish any sort of namepsace. Period.
I will take your word for it.
> The only way in Lisp for you to have "classes of the same name" is for
> them to be exactly the same class, as in EQ classes. To put this into
> Java terms for you, the confusion you are imagining would be akin to
> saying that one could have two classses java.lang.String and
> java.lang.String which are different, and thus confusable. You can't,
> since they are the same classes.
Technically two classes with same name including package are
considered different in Java if they are loaded by different
classloaders.
Not that it really matters for your argumentation - it is still
perfectly valid.
Arne
On May 18, 9:09 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Thomas A. Russ wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> I just explained why the package system won't. Adding new classes in
> >> their own packages? No problem, the package system can distinguish
> >> foo.String from bar.String. Adding new methods to an existing class,
> >> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
> >> foo.String.doIt()? They have the same method name, are methods of
> >> classes with the same name, and the classes are in the same package.
> >> As far as the compiler is concerned, they are the same. The package
> >> system cannot distinguish them unless we add another layer of
> >> namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
> >> and foo.String.quux.doIt() instead of just foo.String.doIt() as the
> >> fully-qualified names. And now we're deep in migraine-headache
> >> territory, without oar or compass...
>
> > Well, the above paragraph is prima facie evidence that you have a
> > profound ignorance ... incorrect ... yadda yadda yadda
> Not that it really matters for your argumentation - it is still
> perfectly valid.
No, Thomas's argumentation is not "perfectly valid". Argumentum ad
hominem has been recognized as a fallacy for thousands of years.
Series Expansion wrote:
> On May 18, 9:09 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>> Thomas A. Russ wrote:
>>> Series Expansion <·······@gmail.com> writes:
>>>> I just explained why the package system won't. Adding new classes in
>>>> their own packages? No problem, the package system can distinguish
>>>> foo.String from bar.String. Adding new methods to an existing class,
>>>> say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
>>>> foo.String.doIt()? They have the same method name, are methods of
>>>> classes with the same name, and the classes are in the same package.
>>>> As far as the compiler is concerned, they are the same. The package
>>>> system cannot distinguish them unless we add another layer of
>>>> namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
>>>> and foo.String.quux.doIt() instead of just foo.String.doIt() as the
>>>> fully-qualified names. And now we're deep in migraine-headache
>>>> territory, without oar or compass...
>>> Well, the above paragraph is prima facie evidence that you have a
>>> profound ignorance of how the Lisp package system works. You also have
>>> a profound ignorance of how the Lisp object system works. And taken
>>> together, those sources of ignorance lead you to raise objections that
>>> are absolutely incorrect.
>>>
>>> First of all, methods don't belong to classes. Period.
>> Second of all, classes don't establish any sort of namepsace. Period.
>>>I will take your word for it.
>>> The only way in Lisp for you to have "classes of the same name" is for
>>> them to be exactly the same class, as in EQ classes. To put this into
>>> Java terms for you, the confusion you are imagining would be akin to
>>> saying that one could have two classses java.lang.String and
>>> java.lang.String which are different, and thus confusable. You can't,
>>> since they are the same classes.
>> Technically two classes with same name including package are
>> considered different in Java if they are loaded by different
>> classloaders.
>> Not that it really matters for your argumentation - it is still
>> perfectly valid.
>
> No, Thomas's argumentation is not "perfectly valid". Argumentum ad
> hominem has been recognized as a fallacy for thousands of years.
You must be smoking something illegal.
He is arguing very technical about classes and namespaces in Lisp
and Java.
Arne
On May 22, 10:24 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 18, 9:09 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Thomas A. Russ wrote:
[snip]
> >> Not that it really matters for your argumentation - it is still
> >> perfectly valid.
>
> > No, Thomas's argumentation is not "perfectly valid". Argumentum ad
> > hominem has been recognized as a fallacy for thousands of years.
>
> You must be smoking something illegal.
I most certainly am not.
> He is arguing very technical about classes and namespaces in Lisp
> and Java.
I was not referring to any technical argument he may have made. I was
referring to the ad hominem argument that he also made.
Meanwhile, it would be wise of you to look into what laws against
defamation apply in your location of residence. It is quite possible
that posting the unsubstantiated and erroneous accusation of criminal
activity that you just posted was itself an illegal act on your part.
On May 18, 11:45 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 3:35Ž pm, gugamilare <··········@gmail.com> wrote:
>
> > > You are once again flaming what you do not understand.
>
> > I'm not the one doing the flaming here at all.
>
> I'll grant that you are not flaming. You are just blathering. You are
> just spouting idiotic comments about technology that you clearly do not
> understand.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
> > > The CL package system will solve the name collision with no harm done.
>
> > I just explained why the package system won't. Adding new classes in
> > their own packages? No problem, the package system can distinguish
> > foo.String from bar.String. Adding new methods to an existing class,
> > say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
> > foo.String.doIt()? They have the same method name, are methods of
> > classes with the same name, and the classes are in the same package.
> > As far as the compiler is concerned, they are the same. The package
> > system cannot distinguish them unless we add another layer of
> > namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
> > and foo.String.quux.doIt() instead of just foo.String.doIt() as the
> > fully-qualified names. And now we're deep in migraine-headache
> > territory, without oar or compass...
>
> Well, the above paragraph is prima facie evidence that you have a
> profound ignorance [lots more bullshit deleted]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
> [much deleted]
> To put this into Java terms for you, the confusion you are
> imagining would be akin to saying that one could have two
> classses java.lang.String and java.lang.String which are
> different, and thus confusable. You can't, since they are
> the same classes.
Unless they were created with different ClassLoaders.
> [most of rest of post deleted]
> that you in your lack of knowledge so blithely assert.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
gugamilare wrote:
> You are once again flaming what you do not understand.
It's not a flame until someone accuses the other of flaming and failing to
understand.
--
Lew
From: Thomas A. Russ
Subject: Re: macros (was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <ymihbzmnn9t.fsf@blackcat.isi.edu>
Series Expansion <·······@gmail.com> writes:
> On May 15, 12:34��pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > (BTW, this is caused by the inability to add methods to a Java class
> > once it is defined. ��Another nice, flexible benefit of CLOS).
>
> Another potential source of headaches too, I'll warrant. Imagine the
> chaos that would ensue if Java did allow this. Someone might add a
> method to the String class called "foo" to do X. Someone else adds a
> method to the String class called "foo" to do Y. Then someone tries to
> use both pieces of code together in the same project and kaboom!
>
> The only way out looks like adding a whole 'nother system of package
> namespaces *inside* *each and every class* for its methods.
Well, it seems that Common Lisp has already solved that problem.
They have namespaces (called "packages" in Lisp terminology) that take
care of this problem for you.
So this is absolutely not a headache.
> Even then you get dependency headaches. Code calling someString.foo()
> won't compile if you don't have the right non-standard String
> extension in your classpath somewhere.
Hmmm. Classpath. Lisp doesn't have classpaths. Of course, you do have
the headache of making sure that even code containing such a call, even
if it never executes, won't compile. So you can't do early testing of
partial implementations.
And if you want to defend Java, I wouldn't get started on library
dependencies. I've experienced software combinations where one had to
have multiple versions of a particular library available, and in exactly
the right order in the classpath so that the code would run.
But again, this isn't really a problem in Lisp. I don't know why you
think it would be. The language just works differently.
> It's one thing if you have
> instanceOfSomeUnfamiliarClass.foo() and obviously need a library
> installed, but when code calls non-existent methods on standard
> library classes like String, who you gonna call? A google search for
> "SomeUnfamiliarClass" might turn up the needed library; a google
> search for "String" isn't likely to help much.
Um, you are making the mistake of commenting on an object system that
you don't understand.
Strange at it may seem, there actually is more than one possible model
of object-oriented programming. In fact, Lisp (not Common Lisp) at one
time had a message-passing object system called Flavors, that was a
single-dispatch system a lot closer to the Java/C++ model. But
experience with that and the development of Common Loops (an object
system, it has nothing to do with the LOOP macro) lead to the
development of the Common Lisp Object System.
In CLOS, objects just encapsulate data. Period.
Methods DO NOT BELONG TO CLASSES. Instead they are organized base on
the function they perform. Each such "generic function" is a particular
operation. Methods are added to the generic function to handle
particular argument types (via dynamic multiple dispatch). So the
methods really belong to the generic function.
And if no such generic function is defined, your lisp compiler will
complain about it. So what you would do is Google for the generic
function you wanted. And if that function has the behavior you want but
no method for your classes, you can just add it yourself! So your
complaint about how to search for the method just underscores your
profound lack of understanding of the technology you are trying to
criticize. Hard to take seriously.
Being able to create generic functions that work with objects created by
others (say in some library code you are using) is a nice way to add
functionality that the library authors didn't anticipate. To illustrate
this I like to use the analogy of a hammer.
Suppose one manufactured hammers in the manner of an object model where
methods belonged directly to classes. In that case, there would be a
set of operations anticipated by the library designer for these new
hammer objects. Typical operations would involve things like driving
nails and pulling them out. Very functional.
Now, suppose we are laying out a picnic blanket on a windy day. We
might decide that we would like to use a hammer to help hold it down.
But we can't do that with an ordinary hammer, because it doesn't have a
method for anchoring a blanket. We could only do that if we created our
own specialized hammer-that-can-anchor-blankets subclass, or else if we
put the hammer inside a special anchoring-objects bag first. The plain,
ordinary hammer can't fulfill this new purpose, because it wasn't
anticipated.
And without access to the source code, you can't change this.
Now the real irony in this discussion is that often the most outrageous
claims are made about Lisp, based on ignorance of the basics of the
language design and philosophy. That isn't even to say any real
practical knowledge gained by using the language. On the other hand,
almost all of the Lisp programmers are a lot more familiar and often do
program in other languages like Java.
I suppose one could adopt the view that the Common Lisp advocates have
somehow had their brains warped by the experience, and inexplicably
cling to the view that Common Lisp is nicer to use for many things. But
perhaps a more rational view is that those people most familiar with
both languages prefer Lisp. Those people who don't really know anything
about Lisp are the ones that don't like it. So what unifying theory
could explain such facts. I wonder.
In any case, there are lots of objections that just display a
fundamental ignorance of the Lisp language. It makes it hard to take
the critics seriously when they complain about perceived problems that
JUST DO NOT EXIST in Common Lisp programming practice.
And we'll ignore the delusion that strongly typed languages which
compile are therefore bug-free.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 15, 4:07 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 12:34Ž pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > > (BTW, this is caused by the inability to add methods to a Java class
> > > once it is defined. Ž Another nice, flexible benefit of CLOS).
>
> > Another potential source of headaches too, I'll warrant. Imagine the
> > chaos that would ensue if Java did allow this. Someone might add a
> > method to the String class called "foo" to do X. Someone else adds a
> > method to the String class called "foo" to do Y. Then someone tries to
> > use both pieces of code together in the same project and kaboom!
>
> > The only way out looks like adding a whole 'nother system of package
> > namespaces *inside* *each and every class* for its methods.
>
> Well, it seems that Common Lisp has already solved that problem.
How? Conforming implementations come with a free crate of aspirin?
> They have namespaces (called "packages" in Lisp terminology) that take
> care of this problem for you.
>
> So this is absolutely not a headache.
Nothing is if you're on the right drugs when it happens. :)
> > Even then you get dependency headaches. Code calling someString.foo()
> > won't compile if you don't have the right non-standard String
> > extension in your classpath somewhere.
>
> Hmmm. Classpath. Lisp doesn't have classpaths. Of course, you do have
> the headache of making sure that even code containing such a call, even
> if it never executes, won't compile. So you can't do early testing of
> partial implementations.
You can if you comment out the not-yet-reachable bits that refer to
the not-yet-written bits.
> And if you want to defend Java, I wouldn't get started on library
> dependencies. I've experienced software combinations where one had to
> have multiple versions of a particular library available, and in exactly
> the right order in the classpath so that the code would run.
Sounds like what you'll even more easily get with Lisp. Order
dependency among various (deffoo bar baz quux) lines and therefore
files full of such lines. Name clashes. Multiple implementations or
versions of something. Probably, no language can completely avoid such
issues though.
> But again, this isn't really a problem in Lisp. I don't know why you
> think it would be.
Maybe because it is inevitable?
> The language just works differently.
Yeah. Keep on saying that. Maybe wishes DO come true. :)
> > It's one thing if you have
> > instanceOfSomeUnfamiliarClass.foo() and obviously need a library
> > installed, but when code calls non-existent methods on standard
> > library classes like String, who you gonna call? A google search for
> > "SomeUnfamiliarClass" might turn up the needed library; a google
> > search for "String" isn't likely to help much.
>
> [raw flamage]
Ah, and now we get to the crux of the matter: not static vs. dynamic
typing or Lisp vs. Java, but man against man, keyboard clashing
against keyboard. En garde!
> In CLOS, objects just encapsulate data. Period.
Let's set the wayback machine to 1967 shall we, when the shortcomings
of keeping all the data in structs or similar entities, and all the
behavior elsewhere, were becoming painfully apparent as ever-larger
systems were developed, with attendant scaling problems and growing
pains. Then, Ole-Johan Dahl and Kristen Nygaard said "Let there by
classes!" and there was Simula 67...
Lispers are a very interesting clan, it seems. Their main development
tool is a thirty-year-old terminal-mode text editor. Their notion of
an object system appears of an era with peaceniks and Woodstock and "I
Have A Dream". I have to wonder what's in their medicine cabinets, and
whether much of it is legal. :)
Now for the wakeup call.
The year is now 2009. The seeds planted by Martin Luther's speech took
root decades ago, and we now have an honest-to-god black President
sitting in the Oval Office. Marijuana is still illegal. There's still
a war going badly of dubious morality and motive, but it's not in
Vietnam, it's in Iraq. We have these nifty things called graphics
cards and IDEs now, and the economy is imploding, with climatological
catastrophe looming on the horizon.
I bet to those of you still living in the sixties and seventies, the
above sounds like an opening narration at the start of a bad science-
fiction movie or something, but it's actually real, believe it or
not...
> Methods DO NOT BELONG TO CLASSES. Instead they are organized base on
> the function they perform. Each such "generic function" is a particular
> operation. Methods are added to the generic function to handle
> particular argument types (via dynamic multiple dispatch). So the
> methods really belong to the generic function.
Adding methods might be a problem then, if the generic function you
need to edit is in library code you don't control.
> And if no such generic function is defined, your lisp compiler will
> complain about it.
What? Surely not -- surely it blithely compiles your code, then your
program chokes on some sort of "message not understood" run-time
exception.
> Being able to create generic functions that work with objects created by
> others (say in some library code you are using) is a nice way to add
> functionality that the library authors didn't anticipate.
I'm more concerned with being able to create objects that work with
generic functions created by others. The English language has seven
times as many nouns as it does verbs, and my own experience suggests
that it's much more common to want to add new objects than to add new
methods to a software system, likewise.
> Suppose one manufactured hammers in the manner of an object model where
> methods belonged directly to classes. In that case, there would be a
> set of operations anticipated by the library designer for these new
> hammer objects. Typical operations would involve things like driving
> nails and pulling them out. Very functional.
>
> Now, suppose we are laying out a picnic blanket on a windy day. We
> might decide that we would like to use a hammer to help hold it down.
> But we can't do that with an ordinary hammer, because it doesn't have a
> method for anchoring a blanket. We could only do that if we created our
> own specialized hammer-that-can-anchor-blankets subclass, or else if we
> put the hammer inside a special anchoring-objects bag first. The plain,
> ordinary hammer can't fulfill this new purpose, because it wasn't
> anticipated.
Software systems are very different. You would not try to make a
construction tool function as a weight or similarly; indeed it's hard
to even make the analogy. The need for a hammer above stems from
lacking a dedicated purpose weight optimized for that task, and a
desire not to drive all the way to the hardware store, or home, or
whatever, and back to get one. In a software system, no such
considerations apply: if you need some simple thing like that you can
typically build it or download it without driving anywhere.
> And without access to the source code, you can't change this.
You've just made an argument in favor of open source, not one in favor
of Lisp over Java.
> Now the real irony in this discussion is that often the most outrageous
> claims are made about Lisp, based on ignorance of the basics of the
> language design and philosophy.
That's funny, because it seems the most outrageous claims are being
made about Java, based on ignorance. Not only was mention made of
Java's supposed lack of any dynamic features (and of course
reflection, classloaders, the compiler API, and generic containers
were promptly pointed out by Java partisans) but even of its supposed
slowness. Java hasn't been slow for donkey's years, and people like
you are part of why it is having such a hard time living down its no-
longer-deserved bad reputation in that area.
> On the other hand, almost all of the Lisp programmers are a lot more
> familiar and often do program in other languages like Java.
You wouldn't think so, to hear the howlers some of them have written
about Java here lately. I think one even insinuated that it wasn't
even Turing-complete?
> I suppose one could adopt the view that the Common Lisp advocates have
> somehow had their brains warped by the experience, and inexplicably
> cling to the view that Common Lisp is nicer to use for many things. But
> perhaps a more rational view is that those people most familiar with
> both languages prefer Lisp. Those people who don't really know anything
> about Lisp are the ones that don't like it. So what unifying theory
> could explain such facts. I wonder.
What unifying theory would also explain that the majority of practical
desktop and server applications are not written in Lisp? Desktop apps
are mainly written in C, C++, Delphi, and Pascal, with a smattering of
Java; server applications tend to have a C++ core and quite a lot of
Java, along with glue scripts in shell, perl, python, and ruby, with a
smattering of Lisp. Lisp (and Fortran) only become reasonably common
when you look at scientific, engineering, and comp.sci research apps.
> In any case, there are lots of objections that just display a
> fundamental ignorance of the Lisp language.
In any case, there are lots of objections that just display a
fundamental ignorance of the Java language.
> It makes it hard to take the critics seriously when they complain
> about perceived problems that JUST DO NOT EXIST in Common Lisp
> programming practice.
It makes it hard to take the critics seriously when they complain
about perceived slowness that JUST DOES NOT EXIST in Java programming
practice.
> And we'll ignore the delusion that strongly typed languages which
> compile are therefore bug-free.
I don't think anybody but you ever employed that particular straw-man.
But nobody can deny that there's a big difference between catching 100
bugs after hours of bug-hunting, dozens of debugging prints, and lots
of poring over stack traces and watched-variable logs, and catching 50
bugs that way and 50 instantly when you click "build" (or even when
you write the separate buggy lines of code!).
Series Expansion <·······@gmail.com> writes:
> What unifying theory would also explain that the majority of practical
> desktop and server applications are not written in Lisp? Desktop apps
> are mainly written in C, C++, Delphi, and Pascal, with a smattering of
> Java; server applications tend to have a C++ core and quite a lot of
> Java, along with glue scripts in shell, perl, python, and ruby, with a
> smattering of Lisp. Lisp (and Fortran) only become reasonably common
> when you look at scientific, engineering, and comp.sci research apps.
The Law of the mean.
It's explained in Jean-Fran�ois Geneste's "Ainsi marchait l'humanit�"
(ed. B�n�vent, ISBN 978-2-7563-1103-6).
--
__Pascal Bourguignon__
On May 16, 11:27 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > What unifying theory would also explain that the majority of practical
> > desktop and server applications are not written in Lisp? Desktop apps
> > are mainly written in C, C++, Delphi, and Pascal, with a smattering of
> > Java; server applications tend to have a C++ core and quite a lot of
> > Java, along with glue scripts in shell, perl, python, and ruby, with a
> > smattering of Lisp. Lisp (and Fortran) only become reasonably common
> > when you look at scientific, engineering, and comp.sci research apps.
>
> 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 <·······@gmail.com> writes:
> On May 15, 4:07 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> The year is now 2009. The seeds planted by Martin Luther's speech took
> root decades ago, and we now have an honest-to-god black President
> sitting in the Oval Office.
Considering his opinions on Jews, I'm surprised he liked blacks much
better (if he was even aware of them).
>> Methods DO NOT BELONG TO CLASSES. Instead they are organized base on
>> the function they perform. Each such "generic function" is a particular
>> operation. Methods are added to the generic function to handle
>> particular argument types (via dynamic multiple dispatch). So the
>> methods really belong to the generic function.
>
> Adding methods might be a problem then, if the generic function you
> need to edit is in library code you don't control.
Then it's a good thing it's not necessary to edit any generic functions
to add methods, isn't it? That would indeed be a problem, if it were
ever necessary.
>> And if no such generic function is defined, your lisp compiler will
>> complain about it.
>
> What? Surely not -- surely it blithely compiles your code, then your
> program chokes on some sort of "message not understood" run-time
> exception.
But that would be terrible! Please stay out of language design. I'd feel
uncomfortable even using a library written by someone who thought that
behaviour was reasonable.
>> Being able to create generic functions that work with objects created by
>> others (say in some library code you are using) is a nice way to add
>> functionality that the library authors didn't anticipate.
>
> I'm more concerned with being able to create objects that work with
> generic functions created by others.
Be concerned no longer. What would stop you from doing that?
> You wouldn't think so, to hear the howlers some of them have written
> about Java here lately. I think one even insinuated that it wasn't
> even Turing-complete?
Oh, will you come off it? Do you intentionally adopt the most patently
absurd interpretation of every statement? I'm sure that person (Kenny?)
never believed such a thing, and I have no idea why you think they did.
> But nobody can deny that there's a big difference between catching 100
> bugs after hours of bug-hunting, dozens of debugging prints, and lots
> of poring over stack traces and watched-variable logs, and catching 50
> bugs that way and 50 instantly when you click "build" (or even when
> you write the separate buggy lines of code!).
One could deny that 50% of all bugs are stealthy type errors, but since
we already did static typing these last few weeks, I won't get involved.
On May 17, 3:15 am, Paul Donnelly <·············@sbcglobal.net> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 4:07 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > The year is now 2009. The seeds planted by Martin Luther's speech took
> > root decades ago, and we now have an honest-to-god black President
> > sitting in the Oval Office.
>
> 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? :P
Adlai wrote:
> 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? :P
Ahh, he's a troll and a maroon. He also doesn't know the meaning of the word
"law"; he confused scientific law with legislative.
--
Lew
On May 17, 12:49 pm, Lew <·····@lewscanon.com> wrote:
> Adlai wrote:
> > I'm pretty sure that our dear Mr Expansion is unaware of
>
> > Series, go read about some history before you go read about Lisp
>
> Ahh, he's a troll and a maroon. He also doesn't know the meaning of the word
> "law"; he confused scientific law with legislative.
Incorrect.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Adlai.
On May 17, 1:30 am, Adlai <·········@gmail.com> wrote:
> On May 17, 3:15 am, Paul Donnelly <·············@sbcglobal.net> wrote:
> > 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
None of these personal attacks have any bearing on Java *or* Lisp.
Please endeavor to stick to the topic at hand.
On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> Considering his opinions on Jews
By some standards, the pro-Java side just won the debate right there.
> Series Expansion <·······@gmail.com> writes:
[an attribution is missing here, but it was obviously a Lisp partisan]
> >> Methods DO NOT BELONG TO CLASSES. Instead they are organized base on
> >> the function they perform. Each such "generic function" is a particular
> >> operation. Methods are added to the generic function to handle
> >> particular argument types (via dynamic multiple dispatch). So the
> >> methods really belong to the generic function.
>
> > Adding methods might be a problem then, if the generic function you
> > need to edit is in library code you don't control.
>
> Then it's a good thing it's not necessary to edit any generic functions
> to add methods, isn't it?
This statement contradicts an earlier statement that the means by
which methods are dispatched is through generic functions, which
contain dispatch tables that reference all of the methods that they
can dispatch.
In <····································@n8g2000vbb.googlegroups.com>
anonymous_c_lisper posted an example of a generic function:
(defgeneric frobnobdicate (a b)
(:method ((foo foo) (bar bar)) ;;arguments
.. body)
(:method ((foo foo) (baz baz))
..body))
It seems quite obvious that adding another method, this one with a new
class quux as a second argument type, would require editing that code
to:
(defgeneric frobnobdicate (a b)
(:method ((foo foo) (bar bar)) ;;arguments
.. body)
(:method ((foo foo) (baz baz))
.. body)
(:method ((foo foo) (quux quux))
..body))
The problem arises if it is not your code to edit. Then you cannot add
a frobnobdicate method to your quux class.
There appear to be only three alternatives here:
1. The problem arises;
2. anonymous_c_lisper was wrong about something; or
3. You are wrong about something.
The suggestion floated recently that code like the above be generated
by automation does not materially alter the parameters of this debate.
The above alteration, whether automated or not, poses a problem if the
code is not yours to modify, and an even larger problem if conflicting
modifications are made by different developers whose code will
eventually be combined, granting the assumption that
(defgeneric frobnobdicate (a b)
(:method ((foo foo) (bar bar)) ;;arguments
.. body)
(:method ((foo foo) (baz baz))
.. body)
(:method ((foo foo) (quux quux))
.. body)
(:method ((foo foo) (quux quux))
..different body))
will fail in some manner or another.
This particular corner of the debate is but one of many where evidence
has surfaced that strongly suggests that Lisp is centered around a
lone-wolf development model and, in particular, that in its present
form as described by you it is unsuited to use by a large team. Pair
programming may well be the largest team size up to which it will
scale given the numerous issues that have come to light.
Even supposing that one were to have dispatch tables like the above,
widely-used macros, and similar constructs gate-kept by "owners"
within a larger development team, all requests to for instance add a
new dispatch to a generic function would have to go through the
appropriate gatekeepers. Whereupon the scaling problems described in
__The_Mythical_Man_Month__ come into play full-force; the volume of
such requests will tend to grow as the square of the number of
developers, and the number received by the owner of a particular piece
of such code will tend to grow linearly, soon overwhelming them. The
encapsulation and modularity of code offered by OO languages like Java
reduces this problem enormously, as only defining and changing widely-
used interfaces requires that level of coordination, and everyone can
work within the encapsulation walls of their classes as if alone
without fear that they will tread upon any toes. Even if they wish to
put a frobnobdicate method into a class named quux that they use to
implement their piece of the program, and other frobnobdicate methods
already exist.
Imagine the chaos if there was a master list of all classes that
implemented "Comparable" for example and for anyone to add
comparability to a class in their corner of the codebase had to get it
approved so the owner of the comparable-classes list could add it to
the list, this list being needed by the JVM to dispatch compare()
method invocations. Fortunately Java was not designed this way, but if
we replace compare() with frobnobdicate, we see that we have precisely
the described situation in Lisp, at least according to what
anonymous_c_lisper wrote and making some obvious inferences therefrom.
Probably this is why multiple dispatch is generally not found in
languages that are used to develop large, professional software
projects. It seems that multiple dispatch in general cannot be
implemented without requiring more explicit management of dispatch
tables than occurs typically in single dispatch languages, and then
those dispatch tables become bottlenecks in the development process,
in turn placing an upper bound on effective team size and thus on
effective project size.
> > What? Surely not -- surely it blithely compiles your code, then your
> > program chokes on some sort of "message not understood" run-time
> > exception.
>
> But that would be terrible!
That, however, is precisely what happens in dynamically-typed object-
oriented systems, since without static types the compiler cannot know
the types of the objects receiving particular messages.
It follows from your emotional outburst above that dynamically-typed
object-oriented systems are terrible. Interestingly, that category
appears to include CLOS.
Your outburst is rather puzzling given that you were formerly arguing
the other side.
> >> Being able to create generic functions that work with objects created by
> >> others (say in some library code you are using) is a nice way to add
> >> functionality that the library authors didn't anticipate.
>
> > I'm more concerned with being able to create objects that work with
> > generic functions created by others.
>
> Be concerned no longer. What would stop you from doing that?
I believe the concerns I have were adequately outlined above, with
code examples and a detailed explanation of the scaling problems,
supported by mathematical calculations and a reference. If you find
that insufficient, I am not sure that I can be of further assistance
to you in understanding the matter.
> > You wouldn't think so, to hear the howlers some of them have written
> > about Java here lately. I think one even insinuated that it wasn't
> > even Turing-complete?
>
> Oh, will you come off it? Do you intentionally adopt the most patently
> absurd interpretation of every statement?
No, I merely take them at face value and derive what logical
conclusions I can. Note also that I did not specifically accuse you,
personally, of making the particular absurd insinuation referenced
above.
> I'm sure that person (Kenny?) never believed such a thing, and I have no
> idea why you think they did.
Because they expressed such a belief in their writing.
> > But nobody can deny that there's a big difference between catching 100
> > bugs after hours of bug-hunting, dozens of debugging prints, and lots
> > of poring over stack traces and watched-variable logs, and catching 50
> > bugs that way and 50 instantly when you click "build" (or even when
> > you write the separate buggy lines of code!).
>
> One could deny that 50% of all bugs are stealthy type errors, but since
> we already did static typing these last few weeks, I won't get involved.
Type errors are only stealthy if one eschews the use of a language
with static type checking, of course.
For now, I leave you with another reference, an academic paper whose
conclusion, to my mind, indicates that implicitly-typed languages,
even statically-typed ones like OCaml, exhibit scaling problems caused
by supralinear growth with project size of type-error debugging
effort:
http://portal.acm.org/citation.cfm?id=176454.176460
On May 18, 12:41 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>
> > Considering his opinions on Jews
>
> By some standards, the pro-Java side just won the debate right there.
You should have included the message he was replying to there. He was
talking about Martin Luther, not you or MLK Jr.
>
> > Series Expansion <·······@gmail.com> writes:
>
> [an attribution is missing here, but it was obviously a Lisp partisan]
>
> > >> Methods DO NOT BELONG TO CLASSES. Instead they are organized base on
> > >> the function they perform. Each such "generic function" is a particular
> > >> operation. Methods are added to the generic function to handle
> > >> particular argument types (via dynamic multiple dispatch). So the
> > >> methods really belong to the generic function.
>
> > > Adding methods might be a problem then, if the generic function you
> > > need to edit is in library code you don't control.
>
> > Then it's a good thing it's not necessary to edit any generic functions
> > to add methods, isn't it?
>
> This statement contradicts an earlier statement that the means by
> which methods are dispatched is through generic functions, which
> contain dispatch tables that reference all of the methods that they
> can dispatch.
>
> In <····································@n8g2000vbb.googlegroups.com>
> anonymous_c_lisper posted an example of a generic function:
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> ..body))
>
> It seems quite obvious that adding another method, this one with a new
> class quux as a second argument type, would require editing that code
> to:
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> .. body)
> (:method ((foo foo) (quux quux))
> ..body))
>
> The problem arises if it is not your code to edit. Then you cannot add
> a frobnobdicate method to your quux class.
Actually, you can, just nobody pointed it out yet. There's a defmethod
macro that allows you to do something along the lines of:
(defmethod frobnobdicate ((foo a) (quux b))
body-form*)
BTW, the syntax for the parameter lists for a generic fn is different
from that of a method -- in a generic fn, you just specify the number
of arguments, and names you give them mainly serve for clarification
of purpose. In methods, the first name is a class or more rarely
specific object, and the second name is the name you want bound to the
corresponding argument to the method.
>
> There appear to be only three alternatives here:
> 1. The problem arises;
> 2. anonymous_c_lisper was wrong about something; or
> 3. You are wrong about something.
>
> The suggestion floated recently that code like the above be generated
> by automation does not materially alter the parameters of this debate.
> The above alteration, whether automated or not, poses a problem if the
> code is not yours to modify, and an even larger problem if conflicting
> modifications are made by different developers whose code will
> eventually be combined, granting the assumption that
A few things:
- The code is never yours to modify unless it's open-source; however,
the definitions of specific methods within a generic function that
your code uses are ALWAYS yours to modify, either by adding a :method
form to a defgeneric form in your source code, or by writing a
defmethod form yourself to supplant an existing generic fn.
- defgeneric and defmethod are both examples of machine-generated
code, in a very similar way to how the JVM bytecode generated by
Java's class definition syntax is "machine-generated". There are two
differences though -- 1) anyone could write a similar form to
defgeneric that would look and feel like Lisp syntax, while Java's
class syntax is not available as an option to user-defined object
systems, and 2) Lisp's object system is implemented all in "normal"
non-OO Lisp; it was originally just a library that a bunch of people
wrote when OO became popular.
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> .. body)
> (:method ((foo foo) (quux quux))
> .. body)
> (:method ((foo foo) (quux quux))
> ..different body))
>
> will fail in some manner or another.
I don't think it'll "fail"; just the first method for (frobnobdicate a-
foo a-quux) will be overwritten by the second method.
>
> This particular corner of the debate is but one of many where evidence
> has surfaced that strongly suggests that Lisp is centered around a
> lone-wolf development model and, in particular, that in its present
> form as described by you it is unsuited to use by a large team. Pair
> programming may well be the largest team size up to which it will
> scale given the numerous issues that have come to light.
Not necessarily. A defmethod form overriding or supplanting a generic
fn's capabilities will only apply to code within the package that
defmethod form appears in. Not making it external means that other
programmers could :use the package that has useful code which
internally uses the new method, but they wouldn't have to worry about
the original functionality of the same generic function, and could use
the original version in their code. It's possible that I'm wrong about
the details, but I hope that if I am, somebody who uses CLOS often can
correct me.
>
> Even supposing that one were to have dispatch tables like the above,
> widely-used macros, and similar constructs gate-kept by "owners"
> within a larger development team, all requests to for instance add a
> new dispatch to a generic function would have to go through the
> appropriate gatekeepers. Whereupon the scaling problems described in
> __The_Mythical_Man_Month__ come into play full-force; the volume of
> such requests will tend to grow as the square of the number of
> developers, and the number received by the owner of a particular piece
> of such code will tend to grow linearly, soon overwhelming them. The
> encapsulation and modularity of code offered by OO languages like Java
> reduces this problem enormously, as only defining and changing widely-
> used interfaces requires that level of coordination, and everyone can
> work within the encapsulation walls of their classes as if alone
> without fear that they will tread upon any toes. Even if they wish to
> put a frobnobdicate method into a class named quux that they use to
> implement their piece of the program, and other frobnobdicate methods
> already exist.
You don't have to have access to the source code with the defgeneric
form to add a method.
> > >> Being able to create generic functions that work with objects created by
> > >> others (say in some library code you are using) is a nice way to add
> > >> functionality that the library authors didn't anticipate.
>
> > > I'm more concerned with being able to create objects that work with
> > > generic functions created by others.
>
> > Be concerned no longer. What would stop you from doing that?
>
> I believe the concerns I have were adequately outlined above, with
> code examples and a detailed explanation of the scaling problems,
> supported by mathematical calculations and a reference. If you find
> that insufficient, I am not sure that I can be of further assistance
> to you in understanding the matter.
Once you created your object, you'd just add a few more lines after
the class definition (as opposed to in the class definition for the
Comparable stuff, if I understood your Java example correctly). These
lines would consist of a defmethod for the generic fn you were
interested in extending to support your object -- for example,
(defmethod compare ((my-obj x) (my-obj y)) code-goes-here). This would
not break any previous functionality of the COMPARE generic fn, except
for overwriting any previous method when both arguments are my-objs --
but in this example that wouldn't be the case because you're making a
new class.
>
> > > You wouldn't think so, to hear the howlers some of them have written
> > > about Java here lately. I think one even insinuated that it wasn't
> > > even Turing-complete?
>
> > Oh, will you come off it? Do you intentionally adopt the most patently
> > absurd interpretation of every statement?
>
> No, I merely take them at face value and derive what logical
> conclusions I can. Note also that I did not specifically accuse you,
> personally, of making the particular absurd insinuation referenced
> above.
>
> > I'm sure that person (Kenny?) never believed such a thing, and I have no
> > idea why you think they did.
>
> Because they expressed such a belief in their writing.
>
No. They said something along the lines of what I referred to as the
bastardization of Orwell's "All animals are equal, but some animals
are more equal than others."
x86 is Turing-complete, along with Ruby, B, BrainFork, Java, Haskell,
Perl, and FORTRAN. But that goes to show that just being T-c doesn't
go very far to show the capabilities or special powers of a language.
Here's an example in Java's favor -- Java and Lisp are both T-c, but I
don't think you can easily, or at all, write Applet-style code in
Lisp, but it's one of the things Java was designed for. So you see,
people weren't saying Java isn't T-c, they were saying that just being
T-c isn't that big a deal anymore.
> > > But nobody can deny that there's a big difference between catching 100
> > > bugs after hours of bug-hunting, dozens of debugging prints, and lots
> > > of poring over stack traces and watched-variable logs, and catching 50
> > > bugs that way and 50 instantly when you click "build" (or even when
> > > you write the separate buggy lines of code!).
>
> > One could deny that 50% of all bugs are stealthy type errors, but since
> > we already did static typing these last few weeks, I won't get involved.
>
> Type errors are only stealthy if one eschews the use of a language
> with static type checking, of course.
>
> For now, I leave you with another reference, an academic paper whose
> conclusion, to my mind, indicates that implicitly-typed languages,
> even statically-typed ones like OCaml, exhibit scaling problems caused
> by supralinear growth with project size of type-error debugging
> effort:
>
> http://portal.acm.org/citation.cfm?id=176454.176460
I don't have enough experience under my belt to debate type systems.
However, I do know that using a good Lisp system -- and there are free
ones -- gets you the best of both worlds in type systems. If a Lisp
programmer decides one day that static typing is as good as you say it
is, it's trivial for them to write type-safe code in CL.
Please read and consider what I've said here. I'm really trying to
understand what it is that you're interested in finding out. I'm sorry
about a few posts where I behaved my age (skateboards and spraypaint).
- Adlai
Adlai <·········@gmail.com> writes:
> (defmethod frobnobdicate ((foo a) (quux b))
> body-form*)
> BTW, the syntax for the parameter lists for a generic fn is different
> from that of a method -- in a generic fn, you just specify the number
> of arguments, and names you give them mainly serve for clarification
> of purpose. In methods, the first name is a class or more rarely
> specific object, and the second name is the name you want bound to the
> corresponding argument to the method.
No, this is not C. We put the parameter and the type in the normal order.
--
__Pascal Bourguignon__
On May 18, 1:32 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Adlai <·········@gmail.com> writes:
> > (defmethod frobnobdicate ((foo a) (quux b))
> > body-form*)
> > BTW, the syntax for the parameter lists for a generic fn is different
> > from that of a method -- in a generic fn, you just specify the number
> > of arguments, and names you give them mainly serve for clarification
> > of purpose. In methods, the first name is a class or more rarely
> > specific object, and the second name is the name you want bound to the
> > corresponding argument to the method.
>
> No, this is not C. We put the parameter and the type in the normal order.
>
> --
> __Pascal Bourguignon__
Thank you for the correction... I'm out for tonight now.
On May 17, 6:28 pm, Adlai <·········@gmail.com> wrote:
> On May 18, 12:41 am, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>
> > > Considering his opinions on Jews
>
> > By some standards, the pro-Java side just won the debate right there.
>
> You should have
You are in no position to be telling others what they should or should
not do.
> > > Then it's a good thing it's not necessary to edit any generic functions
> > > to add methods, isn't it?
>
> > This statement contradicts an earlier statement that the means by
> > which methods are dispatched is through generic functions, which
> > contain dispatch tables that reference all of the methods that they
> > can dispatch.
>
> > In <····································@n8g2000vbb.googlegroups.com>
> > anonymous_c_lisper posted an example of a generic function:
>
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > ..body))
>
> > It seems quite obvious that adding another method, this one with a new
> > class quux as a second argument type, would require editing that code
> > to:
>
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > .. body)
> > (:method ((foo foo) (quux quux))
> > ..body))
>
> > The problem arises if it is not your code to edit. Then you cannot add
> > a frobnobdicate method to your quux class.
>
> Actually, you can, just nobody pointed it out yet. There's a defmethod
> macro
Altering the behavior of that not-yours code via macro is hardly a
successful evasion of my point. In fact it compounds it, for not only
are you still effectively altering the behavior of that code, but
furthermore, you are causing changes at remote locations in the code
base via macro use, which I previously contended was a hazard of Lisp
macros and which your group repeatedly denied could happen. Yet now,
when it suits you, you admit that it can, indeed, happen.
> > There appear to be only three alternatives here:
> > 1. The problem arises;
> > 2. anonymous_c_lisper was wrong about something; or
> > 3. You are wrong about something.
>
> > The suggestion floated recently that code like the above be generated
> > by automation does not materially alter the parameters of this debate.
> > The above alteration, whether automated or not, poses a problem if the
> > code is not yours to modify, and an even larger problem if conflicting
> > modifications are made by different developers whose code will
> > eventually be combined, granting the assumption that
>
> A few things:
> - The code is never yours to modify unless it's open-source; however,
> the definitions of specific methods within a generic function that
> your code uses are ALWAYS yours to modify, either by adding a :method
> form to a defgeneric form in your source code, or by writing a
> defmethod form yourself to supplant an existing generic fn.
Supplanting others' code is one of the capabilities that I had
previously noted to be fraught with hazard.
Furthermore, being able to define a method, but not append a dispatch
for it to a generic function, would not address the issue in which
such dispatch was essential to your plan.
It seems that it is not possible in Lisp to simultaneously avoid both
of the above issues.
> - defgeneric and defmethod are both examples of machine-generated
> code, in a very similar way to how the JVM bytecode generated by
> Java's class definition syntax is "machine-generated".
The implication had been made that not only were tables like in
anonymous_c_lisper's code snippet compiled, like other Lisp source
code, to bytecode, but that those tables were themselves created or
modified by automated tools.
> Lisp's object system is implemented all in "normal" non-OO Lisp
This has already been mentioned elsewhere, and while it does not help
you on the generic function modification issue, it actively hurts you
on the type-safety issue, since it corroborates my claim there that
the compiler cannot type-check CLOS code since it cannot safely make
assumptions about the presence or nature of any object systems in the
code.
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > .. body)
> > (:method ((foo foo) (quux quux))
> > .. body)
> > (:method ((foo foo) (quux quux))
> > ..different body))
>
> > will fail in some manner or another.
>
> I don't think it'll "fail"; just the first method for (frobnobdicate a-
> foo a-quux) will be overwritten by the second method.
That would constitute perhaps the worst possible failure: it silently
works incorrectly, neither alerting anyone to the conflict nor
satisfying everyone's requirements.
> > This particular corner of the debate is but one of many where evidence
> > has surfaced that strongly suggests that Lisp is centered around a
> > lone-wolf development model and, in particular, that in its present
> > form as described by you it is unsuited to use by a large team. Pair
> > programming may well be the largest team size up to which it will
> > scale given the numerous issues that have come to light.
>
> Not necessarily. A defmethod form overriding or supplanting a generic
> fn's capabilities will only apply to code within the package that
> defmethod form appears in.
That is not possible. The defmethod body itself may be local to that
package, but the added dispatch table entry/ies will be local to the
package containing the generic function of which it is the newest
method-member.
Indeed, this raises the possibility that a reference to an object of a
type defined in the former package, and to which the method in
question applies, will escape into the system to eventually be
referenced by a variable in code defined in a different package.
Presumably the generic function is visible there, including the
dispatch entry for that particular type. However, you claim the method
body is inaccessible there. It follows that if that code invokes that
method on that variable, while it is holding that object, the dispatch
table entry will effectively be pointing nowhere.
In C, invoking a dangling function pointer tends to result in a crash.
Whereas I expect Lisp to be somewhat better behaved in a certain
sense, a run-time exception or similar occurrence seems likely.
This would also make it difficult to use polymorphic objects widely in
a system without importing a large number of packages just about
everywhere in the code base, effectively somewhat diluting the name-
collision-avoiding capabilities of the package system.
> Not making it external means that other
> programmers could :use the package that has useful code which
> internally uses the new method, but they wouldn't have to worry about
> the original functionality of the same generic function, and could use
> the original version in their code.
But problems will arise if they invoke that generic function on an
object of a type for which that package had added a "private" version
of the method, as noted above.
> It's possible that I'm wrong about the details
This seems likely, given the extreme dubiousness of the design
decision of enabling a public generic function to have dispatches to
private methods when called with certain combinations of public
classes.
> > Even supposing that one were to have dispatch tables like the above,
> > widely-used macros, and similar constructs gate-kept by "owners"
> > within a larger development team, all requests to for instance add a
> > new dispatch to a generic function would have to go through the
> > appropriate gatekeepers. Whereupon the scaling problems described in
> > __The_Mythical_Man_Month__ come into play full-force; the volume of
> > such requests will tend to grow as the square of the number of
> > developers, and the number received by the owner of a particular piece
> > of such code will tend to grow linearly, soon overwhelming them. The
> > encapsulation and modularity of code offered by OO languages like Java
> > reduces this problem enormously, as only defining and changing widely-
> > used interfaces requires that level of coordination, and everyone can
> > work within the encapsulation walls of their classes as if alone
> > without fear that they will tread upon any toes. Even if they wish to
> > put a frobnobdicate method into a class named quux that they use to
> > implement their piece of the program, and other frobnobdicate methods
> > already exist.
>
> You don't have to have access to the source code with the defgeneric
> form to add a method.
No, just to add a dispatch entry to call that method.
> > > >> Being able to create generic functions that work with objects created by
> > > >> others (say in some library code you are using) is a nice way to add
> > > >> functionality that the library authors didn't anticipate.
>
> > > > I'm more concerned with being able to create objects that work with
> > > > generic functions created by others.
>
> > > Be concerned no longer. What would stop you from doing that?
>
> > I believe the concerns I have were adequately outlined above, with
> > code examples and a detailed explanation of the scaling problems,
> > supported by mathematical calculations and a reference. If you find
> > that insufficient, I am not sure that I can be of further assistance
> > to you in understanding the matter.
>
> Once you created your object, you'd just add a few more lines after
> the class definition (as opposed to in the class definition for the
> Comparable stuff, if I understood your Java example correctly). These
> lines would consist of a defmethod for the generic fn you were
> interested in extending to support your object -- for example,
> (defmethod compare ((my-obj x) (my-obj y)) code-goes-here). This would
> not break any previous functionality of the COMPARE generic fn, except
> for overwriting any previous method when both arguments are my-objs --
> but in this example that wouldn't be the case because you're making a
> new class.
You omit to mention adding a dispatch to the generic function that
invokes your new method. Somewhere in the code base the generic
function's dispatch table lives, resembling anonymous_c_lisper's
example for a generic function named "frobnobdicate". This dispatch
table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
obj) to call your new method when both arguments are my-objs. How is
this entry to be added?
> > > > You wouldn't think so, to hear the howlers some of them have written
> > > > about Java here lately. I think one even insinuated that it wasn't
> > > > even Turing-complete?
>
> > > I'm sure that person (Kenny?) never believed such a thing, and I have no
> > > idea why you think they did.
>
> > Because they expressed such a belief in their writing.
>
> No.
Yes. The post in question appears to be here:
http://groups.google.com/group/comp.lang.lisp/msg/0b8faad0d5e6dd1b
It is by gugamilare, not Kenneth Tilton, but it says, and I quote:
3) Java doesn't have macros.
Macros not only provide a way to make your applications
shorter or more readable, but they also make it possible
to do somethings that otherwise couldn't be done.
If there are computations that Lisp can perform using macros that Java
cannot perform, then either Java is not Turing-complete or Lisp
contains an oracle, and, by implication, the oracle is accessed
through a macro.
To the best of my ability to determine, an oracle would require
specialized hardware, which is not something a computer system would
magically grow inside its case as a consequence of the writing or
execution of any conceivable macro.
From this it follows that the insinuation by gugamilare was that Java
was not Turing complete.
I find it interesting that when one of you says something, I repeat
it, and another of you contradicts it, it frequently proves to have
originated with gugamilare. Perhaps you should settle your internal
disagreements first, rather than debate comp.lang.java.programmer with
a disunited front?
> x86 ... [a long digression about hardware]
> > > > But nobody can deny that there's a big difference between catching 100
> > > > bugs after hours of bug-hunting, dozens of debugging prints, and lots
> > > > of poring over stack traces and watched-variable logs, and catching 50
> > > > bugs that way and 50 instantly when you click "build" (or even when
> > > > you write the separate buggy lines of code!).
>
> > > One could deny that 50% of all bugs are stealthy type errors, but since
> > > we already did static typing these last few weeks, I won't get involved.
>
> > Type errors are only stealthy if one eschews the use of a language
> > with static type checking, of course.
>
> > For now, I leave you with another reference, an academic paper whose
> > conclusion, to my mind, indicates that implicitly-typed languages,
> > even statically-typed ones like OCaml, exhibit scaling problems caused
> > by supralinear growth with project size of type-error debugging
> > effort:
>
> >http://portal.acm.org/citation.cfm?id=176454.176460
>
> I don't have enough experience under my belt to debate type systems.
> However,
let me guess: you're going to do it anyway? And make some utterly
preposterous claim?
> I do know that using a good Lisp system -- and there are free
> ones -- gets you the best of both worlds in type systems.
Yes, and yes. Particularly preposterous this time. It's
straightforward excluded middle: you can't simultaneously both have
and lack static type checking.
> If a Lisp programmer decides one day that static typing is as good as
> you say it is, it's trivial for them to write type-safe code in CL.
Without compiler type-checking, which Lisp lacks being dynamically
typed, it cannot be "trivial" to write type-safe code.
> Please read and consider what I've said here.
I have done so, aside from the lengthy digression about x86 hardware.
It has not changed my mind, but that does not mean I didn't consider
it. It just means that I didn't find it convincing. I have explained
why, above.
> I'm really trying to understand what it is that you're interested in
> finding out. I'm sorry about a few posts where I behaved my age
> (skateboards and spraypaint).
Fortunately, leaving your "mark" all over a usenet thread is not, in
most countries, going to get you arrested and sentenced to community
service.
Then again, for particularly egregious cases such as "Lew" perhaps a
form of "usenet community service" would not be an inappropriate form
of rehabilitation. We only lack a means of enforcing it.
On May 20, 6:32 pm, Series Expansion <·······@gmail.com> wrote:
> On May 17, 6:28 pm, Adlai <·········@gmail.com> wrote:
>
> > On May 18, 12:41 am, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>
> > > > Considering his opinions on Jews
>
> > > By some standards, the pro-Java side just won the debate right there.
>
> > You should have
>
> You are in no position to be telling others what they should or should
> not do.
>
> > > > Then it's a good thing it's not necessary to edit any generic functions
> > > > to add methods, isn't it?
>
> > > This statement contradicts an earlier statement that the means by
> > > which methods are dispatched is through generic functions, which
> > > contain dispatch tables that reference all of the methods that they
> > > can dispatch.
>
> > > In <····································@n8g2000vbb.googlegroups.com>
> > > anonymous_c_lisper posted an example of a generic function:
>
> > > (defgeneric frobnobdicate (a b)
> > > (:method ((foo foo) (bar bar)) ;;arguments
> > > .. body)
> > > (:method ((foo foo) (baz baz))
> > > ..body))
>
> > > It seems quite obvious that adding another method, this one with a new
> > > class quux as a second argument type, would require editing that code
> > > to:
>
> > > (defgeneric frobnobdicate (a b)
> > > (:method ((foo foo) (bar bar)) ;;arguments
> > > .. body)
> > > (:method ((foo foo) (baz baz))
> > > .. body)
> > > (:method ((foo foo) (quux quux))
> > > ..body))
>
> > > The problem arises if it is not your code to edit. Then you cannot add
> > > a frobnobdicate method to your quux class.
>
> > Actually, you can, just nobody pointed it out yet. There's a defmethod
> > macro
>
> Altering the behavior of that not-yours code via macro is hardly a
> successful evasion of my point. In fact it compounds it, for not only
> are you still effectively altering the behavior of that code, but
> furthermore, you are causing changes at remote locations in the code
> base via macro use, which I previously contended was a hazard of Lisp
> macros and which your group repeatedly denied could happen. Yet now,
> when it suits you, you admit that it can, indeed, happen.
No. The fact that defmethod is a macro does not mean it remotely
modifies any code. defgeneric is a macro too, and many other Lisp
operators are, and none I know of remotely alters any code whatsoever.
> > > There appear to be only three alternatives here:
> > > 1. The problem arises;
> > > 2. anonymous_c_lisper was wrong about something; or
> > > 3. You are wrong about something.
>
> > > The suggestion floated recently that code like the above be generated
> > > by automation does not materially alter the parameters of this debate.
> > > The above alteration, whether automated or not, poses a problem if the
> > > code is not yours to modify, and an even larger problem if conflicting
> > > modifications are made by different developers whose code will
> > > eventually be combined, granting the assumption that
>
> > A few things:
> > - The code is never yours to modify unless it's open-source; however,
> > the definitions of specific methods within a generic function that
> > your code uses are ALWAYS yours to modify, either by adding a :method
> > form to a defgeneric form in your source code, or by writing a
> > defmethod form yourself to supplant an existing generic fn.
>
> Supplanting others' code is one of the capabilities that I had
> previously noted to be fraught with hazard.
>
> Furthermore, being able to define a method, but not append a dispatch
> for it to a generic function, would not address the issue in which
> such dispatch was essential to your plan.
>
> It seems that it is not possible in Lisp to simultaneously avoid both
> of the above issues.
>
> > - defgeneric and defmethod are both examples of machine-generated
> > code, in a very similar way to how the JVM bytecode generated by
> > Java's class definition syntax is "machine-generated".
>
> The implication had been made that not only were tables like in
> anonymous_c_lisper's code snippet compiled, like other Lisp source
> code, to bytecode, but that those tables were themselves created or
> modified by automated tools.
What you mistakenly see as "tables" is really ONE way to define some
methods along with the generic function. It's totally optional.
You can write no such "table" as you name them, and write a bunch of
defmethod forms instead - it's the same. The real "dispatch tables"
are not apparent in source, like they are not in Java: they are state
maintained in the system's internals, just like in Java, C++ etc.
> > Lisp's object system is implemented all in "normal" non-OO Lisp
>
> This has already been mentioned elsewhere, and while it does not help
> you on the generic function modification issue, it actively hurts you
> on the type-safety issue, since it corroborates my claim there that
> the compiler cannot type-check CLOS code since it cannot safely make
> assumptions about the presence or nature of any object systems in the
> code.
>
> > > (defgeneric frobnobdicate (a b)
> > > (:method ((foo foo) (bar bar)) ;;arguments
> > > .. body)
> > > (:method ((foo foo) (baz baz))
> > > .. body)
> > > (:method ((foo foo) (quux quux))
> > > .. body)
> > > (:method ((foo foo) (quux quux))
> > > ..different body))
>
> > > will fail in some manner or another.
>
> > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > foo a-quux) will be overwritten by the second method.
>
> That would constitute perhaps the worst possible failure: it silently
> works incorrectly, neither alerting anyone to the conflict nor
> satisfying everyone's requirements.
Where is it written that it *silently* works incorrectly? All
implementations I know of warn the user in case of redefinition of a
method.
> > > This particular corner of the debate is but one of many where evidence
> > > has surfaced that strongly suggests that Lisp is centered around a
> > > lone-wolf development model and, in particular, that in its present
> > > form as described by you it is unsuited to use by a large team. Pair
> > > programming may well be the largest team size up to which it will
> > > scale given the numerous issues that have come to light.
>
> > Not necessarily. A defmethod form overriding or supplanting a generic
> > fn's capabilities will only apply to code within the package that
> > defmethod form appears in.
>
> That is not possible. The defmethod body itself may be local to that
> package, but the added dispatch table entry/ies will be local to the
> package containing the generic function of which it is the newest
> method-member.
>
> Indeed, this raises the possibility that a reference to an object of a
> type defined in the former package, and to which the method in
> question applies, will escape into the system to eventually be
> referenced by a variable in code defined in a different package.
> Presumably the generic function is visible there, including the
> dispatch entry for that particular type. However, you claim the method
> body is inaccessible there. It follows that if that code invokes that
> method on that variable, while it is holding that object, the dispatch
> table entry will effectively be pointing nowhere.
>
> In C, invoking a dangling function pointer tends to result in a crash.
> Whereas I expect Lisp to be somewhat better behaved in a certain
> sense, a run-time exception or similar occurrence seems likely.
>
> This would also make it difficult to use polymorphic objects widely in
> a system without importing a large number of packages just about
> everywhere in the code base, effectively somewhat diluting the name-
> collision-avoiding capabilities of the package system.
I make no sense of this. I'm only able to understand that your notion
of "package" is something that has no resemblance to what a package is
in Lisp. A package is a container of symbols, period. I repeat myself:
a package does not concern itself with functions, classes, variables,
methods, etc. etc. etc.
> > Not making it external means that other
> > programmers could :use the package that has useful code which
> > internally uses the new method, but they wouldn't have to worry about
> > the original functionality of the same generic function, and could use
> > the original version in their code.
>
> But problems will arise if they invoke that generic function on an
> object of a type for which that package had added a "private" version
> of the method, as noted above.
Still makes no sense to me... packages have no methods.
> > It's possible that I'm wrong about the details
>
> This seems likely, given the extreme dubiousness of the design
> decision of enabling a public generic function to have dispatches to
> private methods when called with certain combinations of public
> classes.
What is a public generic function? What is a public class? What is a
private method? This is not Java. *symbols* in a package can be
internal ("private") or exported ("public"). No other kind of Lisp
object I know of, besides symbols, bears the concept of
"public"/"private".
> > > Even supposing that one were to have dispatch tables like the above,
> > > widely-used macros, and similar constructs gate-kept by "owners"
> > > within a larger development team, all requests to for instance add a
> > > new dispatch to a generic function would have to go through the
> > > appropriate gatekeepers. Whereupon the scaling problems described in
> > > __The_Mythical_Man_Month__ come into play full-force; the volume of
> > > such requests will tend to grow as the square of the number of
> > > developers, and the number received by the owner of a particular piece
> > > of such code will tend to grow linearly, soon overwhelming them. The
> > > encapsulation and modularity of code offered by OO languages like Java
> > > reduces this problem enormously, as only defining and changing widely-
> > > used interfaces requires that level of coordination, and everyone can
> > > work within the encapsulation walls of their classes as if alone
> > > without fear that they will tread upon any toes. Even if they wish to
> > > put a frobnobdicate method into a class named quux that they use to
> > > implement their piece of the program, and other frobnobdicate methods
> > > already exist.
>
> > You don't have to have access to the source code with the defgeneric
> > form to add a method.
>
> No, just to add a dispatch entry to call that method.
No. To add a method you call defmethod, period. No access to source
required.
> > > > >> Being able to create generic functions that work with objects created by
> > > > >> others (say in some library code you are using) is a nice way to add
> > > > >> functionality that the library authors didn't anticipate.
>
> > > > > I'm more concerned with being able to create objects that work with
> > > > > generic functions created by others.
>
> > > > Be concerned no longer. What would stop you from doing that?
>
> > > I believe the concerns I have were adequately outlined above, with
> > > code examples and a detailed explanation of the scaling problems,
> > > supported by mathematical calculations and a reference. If you find
> > > that insufficient, I am not sure that I can be of further assistance
> > > to you in understanding the matter.
>
> > Once you created your object, you'd just add a few more lines after
> > the class definition (as opposed to in the class definition for the
> > Comparable stuff, if I understood your Java example correctly). These
> > lines would consist of a defmethod for the generic fn you were
> > interested in extending to support your object -- for example,
> > (defmethod compare ((my-obj x) (my-obj y)) code-goes-here). This would
> > not break any previous functionality of the COMPARE generic fn, except
> > for overwriting any previous method when both arguments are my-objs --
> > but in this example that wouldn't be the case because you're making a
> > new class.
>
> You omit to mention adding a dispatch to the generic function that
> invokes your new method. Somewhere in the code base the generic
> function's dispatch table lives, resembling anonymous_c_lisper's
> example for a generic function named "frobnobdicate". This dispatch
> table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
> obj) to call your new method when both arguments are my-objs. How is
> this entry to be added?
Again, no such table exists in source.
> > > > > You wouldn't think so, to hear the howlers some of them have written
> > > > > about Java here lately. I think one even insinuated that it wasn't
> > > > > even Turing-complete?
>
> > > > I'm sure that person (Kenny?) never believed such a thing, and I have no
> > > > idea why you think they did.
>
> > > Because they expressed such a belief in their writing.
>
> > No.
>
> Yes. The post in question appears to be here:
>
> http://groups.google.com/group/comp.lang.lisp/msg/0b8faad0d5e6dd1b
>
> It is by gugamilare, not Kenneth Tilton, but it says, and I quote:
>
> 3) Java doesn't have macros.
>
> Macros not only provide a way to make your applications
> shorter or more readable, but they also make it possible
> to do somethings that otherwise couldn't be done.
>
> If there are computations that Lisp can perform using macros that Java
> cannot perform, then either Java is not Turing-complete or Lisp
> contains an oracle, and, by implication, the oracle is accessed
> through a macro.
>
> To the best of my ability to determine, an oracle would require
> specialized hardware, which is not something a computer system would
> magically grow inside its case as a consequence of the writing or
> execution of any conceivable macro.
>
> From this it follows that the insinuation by gugamilare was that Java
> was not Turing complete.
"to do something that otherwise couldn't be done" is not to be taken
literally. It couldn't be done with limited resources by a reasonable
number of human beings. Of course being both Java and Lisp Turing-
complete, everything you can do with one you can do with the other, at
worst by emulation: I can theoretically rewrite the whole Java in
Lisp, or the whole Lisp in Java.
> I find it interesting that when one of you says something, I repeat
> it, and another of you contradicts it, it frequently proves to have
> originated with gugamilare. Perhaps you should settle your internal
> disagreements first, rather than debate comp.lang.java.programmer with
> a disunited front?
No offense intended, but haven't you thought that maybe the
contradictions are between your assumptions and what other people say
to you?
> > x86 ... [a long digression about hardware]
> > > > > But nobody can deny that there's a big difference between catching 100
> > > > > bugs after hours of bug-hunting, dozens of debugging prints, and lots
> > > > > of poring over stack traces and watched-variable logs, and catching 50
> > > > > bugs that way and 50 instantly when you click "build" (or even when
> > > > > you write the separate buggy lines of code!).
>
> > > > One could deny that 50% of all bugs are stealthy type errors, but since
> > > > we already did static typing these last few weeks, I won't get involved.
>
> > > Type errors are only stealthy if one eschews the use of a language
> > > with static type checking, of course.
>
> > > For now, I leave you with another reference, an academic paper whose
> > > conclusion, to my mind, indicates that implicitly-typed languages,
> > > even statically-typed ones like OCaml, exhibit scaling problems caused
> > > by supralinear growth with project size of type-error debugging
> > > effort:
>
> > >http://portal.acm.org/citation.cfm?id=176454.176460
>
> > I don't have enough experience under my belt to debate type systems.
> > However,
>
> let me guess: you're going to do it anyway? And make some utterly
> preposterous claim?
>
> > I do know that using a good Lisp system -- and there are free
> > ones -- gets you the best of both worlds in type systems.
>
> Yes, and yes. Particularly preposterous this time. It's
> straightforward excluded middle: you can't simultaneously both have
> and lack static type checking.
>
> > If a Lisp programmer decides one day that static typing is as good as
> > you say it is, it's trivial for them to write type-safe code in CL.
>
> Without compiler type-checking, which Lisp lacks being dynamically
> typed, it cannot be "trivial" to write type-safe code.
>
> > Please read and consider what I've said here.
>
> I have done so, aside from the lengthy digression about x86 hardware.
> It has not changed my mind, but that does not mean I didn't consider
> it. It just means that I didn't find it convincing. I have explained
> why, above.
>
> > I'm really trying to understand what it is that you're interested in
> > finding out. I'm sorry about a few posts where I behaved my age
> > (skateboards and spraypaint).
>
> Fortunately, leaving your "mark" all over a usenet thread is not, in
> most countries, going to get you arrested and sentenced to community
> service.
>
> Then again, for particularly egregious cases such as "Lew" perhaps a
> form of "usenet community service" would not be an inappropriate form
> of rehabilitation. We only lack a means of enforcing it.
On May 20, 1:01 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 20, 6:32 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 17, 6:28 pm, Adlai <·········@gmail.com> wrote:
> > > On May 18, 12:41 am, Series Expansion <·······@gmail.com> wrote:
> > > > On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> > > > > Then it's a good thing it's not necessary to edit any generic functions
> > > > > to add methods, isn't it?
>
> > > > This statement contradicts an earlier statement that the means by
> > > > which methods are dispatched is through generic functions, which
> > > > contain dispatch tables that reference all of the methods that they
> > > > can dispatch.
>
> > > > In <····································@n8g2000vbb.googlegroups.com>
> > > > anonymous_c_lisper posted an example of a generic function:
>
> > > > (defgeneric frobnobdicate (a b)
> > > > (:method ((foo foo) (bar bar)) ;;arguments
> > > > .. body)
> > > > (:method ((foo foo) (baz baz))
> > > > ..body))
>
> > > > It seems quite obvious that adding another method, this one with a new
> > > > class quux as a second argument type, would require editing that code
> > > > to:
>
> > > > (defgeneric frobnobdicate (a b)
> > > > (:method ((foo foo) (bar bar)) ;;arguments
> > > > .. body)
> > > > (:method ((foo foo) (baz baz))
> > > > .. body)
> > > > (:method ((foo foo) (quux quux))
> > > > ..body))
>
> > > > The problem arises if it is not your code to edit. Then you cannot add
> > > > a frobnobdicate method to your quux class.
>
> > > Actually, you can, just nobody pointed it out yet. There's a defmethod
> > > macro
>
> > Altering the behavior of that not-yours code via macro is hardly a
> > successful evasion of my point. In fact it compounds it, for not only
> > are you still effectively altering the behavior of that code, but
> > furthermore, you are causing changes at remote locations in the code
> > base via macro use, which I previously contended was a hazard of Lisp
> > macros and which your group repeatedly denied could happen. Yet now,
> > when it suits you, you admit that it can, indeed, happen.
>
> No.
Yes.
> The fact that defmethod is a macro does not mean it remotely
> modifies any code.
In and of itself, you are correct: it does not. However, I did not
base my remarks solely upon its being a macro. I also used your own
statement that it could be used to add more dispatches to the dispatch
table from anonymous.c.lisper. Taken together, those statements imply
that this particular macro can and does modify code.
So either it can, or you are incorrect about it adding more
dispatches, or you are incorrect about it being a macro.
> > > - defgeneric and defmethod are both examples of machine-generated
> > > code, in a very similar way to how the JVM bytecode generated by
> > > Java's class definition syntax is "machine-generated".
>
> > The implication had been made that not only were tables like in
> > anonymous_c_lisper's code snippet compiled, like other Lisp source
> > code, to bytecode, but that those tables were themselves created or
> > modified by automated tools.
>
> What you mistakenly see as "tables"
I do not. I correctly see them as tables.
The code at issue is:
> > > > (defgeneric frobnobdicate (a b)
> > > > (:method ((foo foo) (bar bar)) ;;arguments
> > > > .. body)
> > > > (:method ((foo foo) (baz baz))
> > > > .. body)
> > > > (:method ((foo foo) (quux quux))
> > > > ..body))
This is quite clearly tabular data and anonymous.c.lisper himself
stated that it controls the dispatch of frobnobdicate method calls.
These observations, taken together, suffice to imply that it is a
dispatch table.
> You can write no such "table" as you name them, and write a bunch of
> defmethod forms instead - it's the same.
If you did that, then where would the macro put the dispatches?
> The real "dispatch tables" are not apparent in source, like they
> are not in Java: they are state maintained in the system's
> internals, just like in Java, C++ etc.
If this were true, then the defmethod macro could not function in the
manner claimed. The macro can only replace source code with other
source code at compile time. For it to modify a dispatch table,
therefore, that dispatch table must be located in the source code. Its
only alternative is to generate run-time instructions to allocate and
construct dispatch tables, which has two consequences:
1. How are many uses of the same macro with the same method name
throughout the code base to coordinate? They must create and use a
single dispatch table, not one each, for that sort of scheme to
work.
2. The dispatch tables are then being "faked" using ordinary
user-accessible run-time data structures, rather than being true
dispatch tables analogous to Java's or C++'s, which the compiler
and runtime generate and use and which are not user-accessible,
except, in C++, via unwise pointer manipulation. In particular,
the Lisp dispatch tables would not be "state maintained in the
system's internals, just like in Java, C++ etc."
> > > > (defgeneric frobnobdicate (a b)
> > > > (:method ((foo foo) (bar bar)) ;;arguments
> > > > .. body)
> > > > (:method ((foo foo) (baz baz))
> > > > .. body)
> > > > (:method ((foo foo) (quux quux))
> > > > .. body)
> > > > (:method ((foo foo) (quux quux))
> > > > ..different body))
>
> > > > will fail in some manner or another.
>
> > > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > > foo a-quux) will be overwritten by the second method.
>
> > That would constitute perhaps the worst possible failure: it silently
> > works incorrectly, neither alerting anyone to the conflict nor
> > satisfying everyone's requirements.
>
> Where is it written that it *silently* works incorrectly?
Two levels above:
> > > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > > foo a-quux) will be overwritten by the second method.
This implies that it will quietly do what is unlikely to be what the
programmers intended, without generating any overt warning or error
message. This is commonly called "failing silently". Instead of a
prompt diagnostic, the result is a logic error in the program, and a
greater amount of effort needed subsequently to debug this error.
> All implementations I know of warn the user in case of redefinition of a
> method.
That contradicts the previous, quoted statement about it "just"
overwriting a method.
> > > > This particular corner of the debate is but one of many where evidence
> > > > has surfaced that strongly suggests that Lisp is centered around a
> > > > lone-wolf development model and, in particular, that in its present
> > > > form as described by you it is unsuited to use by a large team. Pair
> > > > programming may well be the largest team size up to which it will
> > > > scale given the numerous issues that have come to light.
>
> > > Not necessarily. A defmethod form overriding or supplanting a generic
> > > fn's capabilities will only apply to code within the package that
> > > defmethod form appears in.
>
> > That is not possible. The defmethod body itself may be local to that
> > package, but the added dispatch table entry/ies will be local to the
> > package containing the generic function of which it is the newest
> > method-member.
>
> > Indeed, this raises the possibility that a reference to an object of a
> > type defined in the former package, and to which the method in
> > question applies, will escape into the system to eventually be
> > referenced by a variable in code defined in a different package.
> > Presumably the generic function is visible there, including the
> > dispatch entry for that particular type. However, you claim the method
> > body is inaccessible there. It follows that if that code invokes that
> > method on that variable, while it is holding that object, the dispatch
> > table entry will effectively be pointing nowhere.
>
> > In C, invoking a dangling function pointer tends to result in a crash.
> > Whereas I expect Lisp to be somewhat better behaved in a certain
> > sense, a run-time exception or similar occurrence seems likely.
>
> > This would also make it difficult to use polymorphic objects widely in
> > a system without importing a large number of packages just about
> > everywhere in the code base, effectively somewhat diluting the name-
> > collision-avoiding capabilities of the package system.
>
> I make no sense of this. I'm only able to understand that your notion
> of "package" is something that has no resemblance to what a package is
> in Lisp.
If that is the case, it can only be because Adlai was inaccurate in
describing packages to me.
> A package is a container of symbols, period. I repeat myself:
> a package does not concern itself with functions, classes, variables,
> methods, etc. etc. etc.
This is contradicted by statements made elsewhere by yourself and
others, particularly, one claiming that a function and a class in the
same package can share the same name. If the package did not
distinguish among these, then that could not be the case.
> > > Not making it external means that other
> > > programmers could :use the package that has useful code which
> > > internally uses the new method, but they wouldn't have to worry about
> > > the original functionality of the same generic function, and could use
> > > the original version in their code.
>
> > But problems will arise if they invoke that generic function on an
> > object of a type for which that package had added a "private" version
> > of the method, as noted above.
>
> Still makes no sense to me...
Since that is based on a description of Common Lisp package behavior
that Adlai posted, you should endeavor to figure out which one of you
is apparently mistaken about packages. At this time I have no basis
for choosing either of your interpretations over the other.
> > > It's possible that I'm wrong about the details
>
> > This seems likely, given the extreme dubiousness of the design
> > decision of enabling a public generic function to have dispatches to
> > private methods when called with certain combinations of public
> > classes.
>
> What is a public generic function? What is a public class? What is a
> private method?
Public = exported. Private = not exported.
> This is not Java.
I did not state otherwise.
> *symbols* in a package can be internal ("private") or exported
> ("public"). No other kind of Lisp object I know of, besides
> symbols, bears the concept of "public"/"private".
Perhaps not directly. But to make a distinction between a method being
private or its name being private seems to be to make a distinction
without a difference. There is a Java analogue:
private static final Integer ANSWER = Integer.valueOf(42);
One would say that the name ANSWER is private, but also that the field
was private. Which it is. It is true that one could get a reference to
the Integer object passed around, so the object itself is not private,
but the field is.
With a private method and methods as first class objects, one would
expect that the method could not be gotten from outside via its name,
but could be via direct reference if one were to obtain one.
Furthermore, in
private class Foo implements Runnable {
public void run () { ... }
}
it may possible to get ahold of a reference to an instance of this
class, though it is private, into a variable of type Runnable. From
there, the run method could be called. The class being private, the
run method is effectively not exported, but it's still callable,
through polymorphic dispatch.
So whereas there is arguably a distinction to be made, in practice
it's a pointless one: "the method is private" is more or less
synonymous with "the method's name is private".
> > > You don't have to have access to the source code with the defgeneric
> > > form to add a method.
>
> > No, just to add a dispatch entry to call that method.
>
> No. To add a method you call defmethod, period. No access to source
> required.
You're forgetting that, by your own prior testimony, the defmethod
macro in turn adds the dispatch entry. So whether you do it by hand,
or have the macro do it for you, the dispatch table must be accessible
to you.
> > You omit to mention adding a dispatch to the generic function that
> > invokes your new method. Somewhere in the code base the generic
> > function's dispatch table lives, resembling anonymous_c_lisper's
> > example for a generic function named "frobnobdicate". This dispatch
> > table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
> > obj) to call your new method when both arguments are my-objs. How is
> > this entry to be added?
>
> Again, no such table exists in source.
Again, macros operate by transforming source, so if this were true,
the defmethod macro could not function in the manner you have claimed.
> > > > > > You wouldn't think so, to hear the howlers some of them have written
> > > > > > about Java here lately. I think one even insinuated that it wasn't
> > > > > > even Turing-complete?
>
> > > > > I'm sure that person (Kenny?) never believed such a thing, and I have no
> > > > > idea why you think they did.
>
> > > > Because they expressed such a belief in their writing.
>
> > > No.
>
> > Yes. The post in question appears to be here:
>
> >http://groups.google.com/group/comp.lang.lisp/msg/0b8faad0d5e6dd1b
>
> > It is by gugamilare, not Kenneth Tilton, but it says, and I quote:
>
> > 3) Java doesn't have macros.
>
> > Macros not only provide a way to make your applications
> > shorter or more readable, but they also make it possible
> > to do somethings that otherwise couldn't be done.
>
> > If there are computations that Lisp can perform using macros that Java
> > cannot perform, then either Java is not Turing-complete or Lisp
> > contains an oracle, and, by implication, the oracle is accessed
> > through a macro.
>
> > To the best of my ability to determine, an oracle would require
> > specialized hardware, which is not something a computer system would
> > magically grow inside its case as a consequence of the writing or
> > execution of any conceivable macro.
>
> > From this it follows that the insinuation by gugamilare was that Java
> > was not Turing complete.
>
> "to do something that otherwise couldn't be done" is not to be taken
> literally.
That is not a valid argument against my reasoning. It is, rather, a
"cop-out". It is also an arrogant presumption on your part, purporting
to be able to speak for gugamilare as you have just done.
> > I find it interesting that when one of you says something, I repeat
> > it, and another of you contradicts it, it frequently proves to have
> > originated with gugamilare. Perhaps you should settle your internal
> > disagreements first, rather than debate comp.lang.java.programmer with
> > a disunited front?
>
> No offense intended, but haven't you thought that maybe the
> contradictions are between your assumptions and what other people say
> to you?
Of course not, since the contradictions in question are contradictions
between a statement made by one of you and a statement made by another
of you. No assumption that I made could alter either statement in any
such case -- you each said whatever you said.
For instance, supposing you were to say that the sky was green, and
gugamilare that it was blue, these statements would contradict,
independently of my own personal opinion on the matter or of any
assumptions on my part.
> > > I'm really trying to understand what it is that you're interested in
> > > finding out. I'm sorry about a few posts where I behaved my age
> > > (skateboards and spraypaint).
>
> > Fortunately, leaving your "mark" all over a usenet thread is not, in
> > most countries, going to get you arrested and sentenced to community
> > service.
>
> > Then again, for particularly egregious cases such as "Lew" perhaps a
> > form of "usenet community service" would not be an inappropriate form
> > of rehabilitation. We only lack a means of enforcing it.
I took the liberty of trimming a large volume of quoted material that
was left unaddressed, but untrimmed, leaving only a small portion. Was
a part of your post mistakenly omitted?
On May 23, 11:34 am, Series Expansion <·······@gmail.com> wrote:
> On May 20, 1:01 pm, Alessio Stalla <·············@gmail.com> wrote:
> > On May 20, 6:32 pm, Series Expansion <·······@gmail.com> wrote:
> > > On May 17, 6:28 pm, Adlai <·········@gmail.com> wrote:
> > > > On May 18, 12:41 am, Series Expansion <·······@gmail.com> wrote:
> > > > > On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
[snip]
> > The fact that defmethod is a macro does not mean it remotely
> > modifies any code.
>
> In and of itself, you are correct: it does not. However, I did not
> base my remarks solely upon its being a macro. I also used your own
> statement that it could be used to add more dispatches to the dispatch
> table from anonymous.c.lisper. Taken together, those statements imply
> that this particular macro can and does modify code.
>
> So either it can, or you are incorrect about it adding more
> dispatches, or you are incorrect about it being a macro.
The answer is, it doesn't modify any existing code.
> The code at issue is:
>
> > > > > (defgeneric frobnobdicate (a b)
> > > > > (:method ((foo foo) (bar bar)) ;;arguments
> > > > > .. body)
> > > > > (:method ((foo foo) (baz baz))
> > > > > .. body)
> > > > > (:method ((foo foo) (quux quux))
> > > > > ..body))
>
> This is quite clearly tabular data and anonymous.c.lisper himself
> stated that it controls the dispatch of frobnobdicate method calls.
> These observations, taken together, suffice to imply that it is a
> dispatch table.
It's not tabular data -- it's a bunch of forms that have parallel
structure, and seem tabular because you're looking at nicely indented
code rather than this:
(defgeneric frobnobdicate(a b)(:method((foo foo)(bar bar)).body)
(:method((foo foo)(baz baz)).body)(:method((foo foo)(quux
quux)).body))
The resemlance to a table is only to illustrate to a human reader the
behaviour of the dispatch table generated by that code.
> > You can write no such "table" as you name them, and write a bunch of
> > defmethod forms instead - it's the same.
>
> If you did that, then where would the macro put the dispatches?
In the running Lisp image. Lisp programs aren't just executed one
statement at a time -- there's an "image" of all the symbols, classes,
functions, closures, methods, etc that are in use at the time. This
(along with consing) does tend to slow down a lot of Lisp code, but
there are techniques for writing efficient code despite this (well-
optimized Lisp runs at a comparable speed to C).
> > The real "dispatch tables" are not apparent in source, like they
> > are not in Java: they are state maintained in the system's
> > internals, just like in Java, C++ etc.
>
> If this were true, then the defmethod macro could not function in the
> manner claimed. The macro can only replace source code with other
> source code at compile time. For it to modify a dispatch table,
> therefore, that dispatch table must be located in the source code. Its
> only alternative is to generate run-time instructions to allocate and
> construct dispatch tables, which has two consequences:
Again, it's not in the source code -- it's in the Lisp image. Lisp
source just includes macros, which modify the Lisp image to update (or
generate, if you're creating a new generic fn) the dispatch tables /in
the Lisp image/.
> 1. How are many uses of the same macro with the same method name
> throughout the code base to coordinate? They must create and use a
> single dispatch table, not one each, for that sort of scheme to
> work.
They don't have to coordinate, because the generated code deals with
the dispatch table.
> 2. The dispatch tables are then being "faked" using ordinary
> user-accessible run-time data structures, rather than being true
> dispatch tables analogous to Java's or C++'s, which the compiler
> and runtime generate and use and which are not user-accessible,
> except, in C++, via unwise pointer manipulation. In particular,
> the Lisp dispatch tables would not be "state maintained in the
> system's internals, just like in Java, C++ etc."
Well, they are "state maintained in the system's internals". It's just
state that can be generated by code, the same way that code in Java or
C++ generates some state in the system's internals.
> > > > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > > > foo a-quux) will be overwritten by the second method.
>
> This implies that it will quietly do what is unlikely to be what the
> programmers intended, without generating any overt warning or error
> message. This is commonly called "failing silently". Instead of a
> prompt diagnostic, the result is a logic error in the program, and a
> greater amount of effort needed subsequently to debug this error.
The compiler will give a warning. Although LITERALLY it's silent,
there is quite the visual cue when little red underlines start
appearing in your code, and the compiler says that there are warnings.
Also the compiler will tell you precisely where the errors were
encountered, so you can find them quite easily.
> > All implementations I know of warn the user in case of redefinition of a
> > method.
>
> That contradicts the previous, quoted statement about it "just"
> overwriting a method.
OK, that's reading too much meaning into what I said. I meant "just
override ..." in the sense that it would generate valid code rather
than failing to compile at all.
> > > > Not necessarily. A defmethod form overriding or supplanting a generic
> > > > fn's capabilities will only apply to code within the package that
> > > > defmethod form appears in.
I've actually been corrected about that. However, it would still apply
only to the currently running Lisp image. So if, for example, you were
using a library, and a DEFMETHOD form in your code extended the
library, somebody else working in a project with you could still use
the same library code, from the same file, as you and the DEFMETHOD
form in /your/ code would not affect them.
> If that is the case, it can only be because Adlai was inaccurate in
> describing packages to me.
See what I just wrote in teh previous paragraph.
>
> > A package is a container of symbols, period. I repeat myself:
> > a package does not concern itself with functions, classes, variables,
> > methods, etc. etc. etc.
>
> This is contradicted by statements made elsewhere by yourself and
> others, particularly, one claiming that a function and a class in the
> same package can share the same name. If the package did not
> distinguish among these, then that could not be the case.
They do share the same name. A package doesn't know the difference
between them. However, when EVAL hits a name, it knows the difference /
in context/ between a variable, function call, etc. The package
doesn't have to know.
>
> > > > Not making it external means that other
> > > > programmers could :use the package that has useful code which
> > > > internally uses the new method, but they wouldn't have to worry about
> > > > the original functionality of the same generic function, and could use
> > > > the original version in their code.
>
> > > But problems will arise if they invoke that generic function on an
> > > object of a type for which that package had added a "private" version
> > > of the method, as noted above.
>
> > Still makes no sense to me...
>
> Since that is based on a description of Common Lisp package behavior
> that Adlai posted, you should endeavor to figure out which one of you
> is apparently mistaken about packages. At this time I have no basis
> for choosing either of your interpretations over the other.
I was mistaken, but not in the way that you thought.
> > > > It's possible that I'm wrong about the details
>
> > > This seems likely, given the extreme dubiousness of the design
> > > decision of enabling a public generic function to have dispatches to
> > > private methods when called with certain combinations of public
> > > classes.
>
> > What is a public generic function? What is a public class? What is a
> > private method?
>
> Public = exported. Private = not exported.
These ideas don't translate so cleanly between Lisp and Java, because
only symbols are "public" or "private". The code itself is still
accessible to anybody who has the symbol reference.
> So whereas there is arguably a distinction to be made, in practice
> it's a pointless one: "the method is private" is more or less
> synonymous with "the method's name is private".
Firstly, Lisp has a lot more freedom, in the sense that "private"
stuff is not inaccessible; this does mean that you have to rely on
people not to use private things in a way that will cause them to
break. However, multimethod dispatch is done in a very safe and
predictable way, so it's not a risk to allow user-defined code do
"call-next-method" to something which could be considered "private" to
an imported package.
> You're forgetting that, by your own prior testimony, the defmethod
> macro in turn adds the dispatch entry. So whether you do it by hand,
> or have the macro do it for you, the dispatch table must be accessible
> to you.
Yes, I could get to the dispatch table. I have no clue how to do it,
although I could find out by examining the macroexpansion of
DEFGENERIC and DEFMETHOD, and then essentially writing that code by
hand. However, this is not done, unless somebody wants to create their
own object system; it would be like editing the Java compiler by hand,
yourself.
> > > You omit to mention adding a dispatch to the generic function that
> > > invokes your new method. Somewhere in the code base the generic
> > > function's dispatch table lives, resembling anonymous_c_lisper's
> > > example for a generic function named "frobnobdicate". This dispatch
> > > table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
> > > obj) to call your new method when both arguments are my-objs. How is
> > > this entry to be added?
>
> > Again, no such table exists in source.
>
> Again, macros operate by transforming source, so if this were true,
> the defmethod macro could not function in the manner you have claimed.
Lisp image != source. I've gone over this already.
> That is not a valid argument against my reasoning. It is, rather, a
> "cop-out". It is also an arrogant presumption on your part, purporting
> to be able to speak for gugamilare as you have just done.
We assume (and I think I speak for others who have posted in response
to you and Seamus) that when somebody else says something that seems
wrong, it's a "thinko", rather than a real mistake. A thinko is like a
typo, but on the scale of ideas -- it's an easily identifiable
MISTAKE, that the person who made probably didn't intend that way.
gugamilare seems, from other things he's said in this group in the
past, to be more knowledgeable in Lisp than I am. If he writes
something that could be read a bit ambiguously, I'm assuming it's
because of a) the fact that English doesn't seem to be his first
language (which is NO PROBLEM WHATSOEVER, you just have to THINK), and
b) he's assuming that the people reading his comments are familiar
with basic Common Lisp concepts.
>
> > > I find it interesting that when one of you says something, I repeat
> > > it, and another of you contradicts it, it frequently proves to have
> > > originated with gugamilare. Perhaps you should settle your internal
> > > disagreements first, rather than debate comp.lang.java.programmer with
> > > a disunited front?
>
> > No offense intended, but haven't you thought that maybe the
> > contradictions are between your assumptions and what other people say
> > to you?
>
> Of course not, since the contradictions in question are contradictions
> between a statement made by one of you and a statement made by another
> of you. No assumption that I made could alter either statement in any
> such case -- you each said whatever you said.
>
> For instance, supposing you were to say that the sky was green, and
> gugamilare that it was blue, these statements would contradict,
> independently of my own personal opinion on the matter or of any
> assumptions on my part.
See what I said in my previous paragraph, it applies here too. By the
way, I would assume that somebody saying that the sky was green would
also be a THINKO -- maybe they meant to type blue, or meant to talk
about grass. These things happen when people are multitasking, as we
all often have to. I would assume that the person I'm talking with has
made a thinko unless they repeat the same mistake several times, in
different phrasings, and defend it when somebody tries to correct
them.
- Adlai
On May 23, 1:56 pm, Adlai <·········@gmail.com> wrote:
> On May 23, 11:34 am, Series Expansion <·······@gmail.com> wrote:
> > On May 20, 1:01 pm, Alessio Stalla <·············@gmail.com> wrote:
> > > The fact that defmethod is a macro does not mean it remotely
> > > modifies any code.
>
> > In and of itself, you are correct: it does not. However, I did not
> > base my remarks solely upon its being a macro. I also used your own
> > statement that it could be used to add more dispatches to the dispatch
> > table from anonymous.c.lisper. Taken together, those statements imply
> > that this particular macro can and does modify code.
>
> > So either it can, or you are incorrect about it adding more
> > dispatches, or you are incorrect about it being a macro.
>
> The answer is, it doesn't modify any existing code.
It follows, then, that you were incorrect about it adding more
dispatches.
> > > > > > (defgeneric frobnobdicate (a b)
> > > > > > (:method ((foo foo) (bar bar)) ;;arguments
> > > > > > .. body)
> > > > > > (:method ((foo foo) (baz baz))
> > > > > > .. body)
> > > > > > (:method ((foo foo) (quux quux))
> > > > > > ..body))
>
> > This is quite clearly tabular data and anonymous.c.lisper himself
> > stated that it controls the dispatch of frobnobdicate method calls.
> > These observations, taken together, suffice to imply that it is a
> > dispatch table.
>
> It's not tabular data
It clearly is, by inspection.
> The resemlance to a table is only to illustrate to a human reader the
> behaviour of the dispatch table
It is structured as a table, and it manages dispatch. It is therefore,
by definition, a dispatch table.
Regardless, this is a mere quibble over terminology. Whether or not
you call it a "dispatch table" or, for that matter, a "frobulator", it
is the thing to which more dispatches are added to add more methods to
the generic function. "A rose by any other name" and so forth.
> > > You can write no such "table" as you name them, and write a bunch of
> > > defmethod forms instead - it's the same.
>
> > If you did that, then where would the macro put the dispatches?
>
> In the running Lisp image.
Certainly not -- the macro runs at compile time, not at run time. It
therefore cannot "put" anything anywhere, except into the code that
replaces its invocation.
> Lisp programs aren't just executed one
> statement at a time -- there's an "image" of all the symbols, classes,
> functions, closures, methods, etc that are in use at the time.
This is true of any running computer program; a running C program will
contain the main method, other functions, and assorted data in memory
at any given time (albeit the functions and the like will not be first-
class objects, though pointers to functions can be manipulated in C).
It is irrelevant, though, to the dispatch-table issue, since no such
image has yet been instantiated if the program has not yet been run
and therefore particularly if it has not yet even been compiled.
> > > The real "dispatch tables" are not apparent in source, like they
> > > are not in Java: they are state maintained in the system's
> > > internals, just like in Java, C++ etc.
>
> > If this were true, then the defmethod macro could not function in the
> > manner claimed. The macro can only replace source code with other
> > source code at compile time. For it to modify a dispatch table,
> > therefore, that dispatch table must be located in the source code. Its
> > only alternative is to generate run-time instructions to allocate and
> > construct dispatch tables, which has two consequences:
>
> Again, it's not in the source code -- it's in the Lisp image. Lisp
> source just includes macros, which modify the Lisp image to update (or
> generate, if you're creating a new generic fn) the dispatch tables /in
> the Lisp image/.
This is incoherent. Macros may still exist at run time as first-class
objects, but they are only evaluated at compile time. At compile time,
obviously, the program does not yet exist in a runnable form.
Therefore it cannot be running, and no such image exists. Therefore,
the macro cannot store anything into that image, since it does not
exist yet.
The most it can do is generate, in its output, instructions that, when
subsequently executed when the program is run, will attempt to
construct a dispatch table in main memory. This runs into difficulties
if there is no "central clearinghouse" (e.g. created by the defgeneric
macro's output, with that output having run before any of the
defmethod macro outputs) around which to coordinate the effort. There
is a problem of symmetry breaking here, and the possibility of a data
race.
> > 1. How are many uses of the same macro with the same method name
> > throughout the code base to coordinate? They must create and use a
> > single dispatch table, not one each, for that sort of scheme to
> > work.
>
> They don't have to coordinate, because the generated code deals with
> the dispatch table.
The generated code is what would have to directly do the coordinating,
of course.
> > 2. The dispatch tables are then being "faked" using ordinary
> > user-accessible run-time data structures, rather than being true
> > dispatch tables analogous to Java's or C++'s, which the compiler
> > and runtime generate and use and which are not user-accessible,
> > except, in C++, via unwise pointer manipulation. In particular,
> > the Lisp dispatch tables would not be "state maintained in the
> > system's internals, just like in Java, C++ etc."
>
> Well, they are "state maintained in the system's internals". It's just
> state that can be generated by code, the same way that code in Java or
> C++ generates some state in the system's internals.
The distinction at issue is between "low-level internals not directly
user-accessible, but which the compiler and runtime can therefore
consider trusted" and "program data generated and maintained by user-
written code, which the compiler and runtime cannot therefore consider
trusted". It is a shame that our communication difficulties apparently
force the use of such long and cumbersome ways of referring to
concepts that are understood by much shorter names within most groups
of computer programmers.
> > > > > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > > > > foo a-quux) will be overwritten by the second method.
>
> > This implies that it will quietly do what is unlikely to be what the
> > programmers intended, without generating any overt warning or error
> > message. This is commonly called "failing silently". Instead of a
> > prompt diagnostic, the result is a logic error in the program, and a
> > greater amount of effort needed subsequently to debug this error.
>
> The compiler will give a warning.
That contradicts the use of the word "just" in the lines quoted above
that are five levels deeper than this line.
> Although LITERALLY it's silent, there is quite the visual cue when little
> red underlines start appearing in your code
So, someone does use Cusp rather than emacs. Interesting.
> > > All implementations I know of warn the user in case of redefinition of a
> > > method.
>
> > That contradicts the previous, quoted statement about it "just"
> > overwriting a method.
>
> OK, that's reading too much meaning into what I said.
It is reading only what was there. If you did not intend the meaning
of the word "just", then you should not have used that word there to
begin with.
> > > > > Not necessarily. A defmethod form overriding or supplanting a generic
> > > > > fn's capabilities will only apply to code within the package that
> > > > > defmethod form appears in.
>
> I've actually been corrected about that. However, it would still apply
> only to the currently running Lisp image. So if, for example, you were
> using a library, and a DEFMETHOD form in your code extended the
> library, somebody else working in a project with you could still use
> the same library code, from the same file, as you and the DEFMETHOD
> form in /your/ code would not affect them.
Until your respective pieces of code were combined, as seems likely
given your hypothesis that the both of you were working on the same
project.
> > > A package is a container of symbols, period. I repeat myself:
> > > a package does not concern itself with functions, classes, variables,
> > > methods, etc. etc. etc.
>
> > This is contradicted by statements made elsewhere by yourself and
> > others, particularly, one claiming that a function and a class in the
> > same package can share the same name. If the package did not
> > distinguish among these, then that could not be the case.
>
> They do share the same name. A package doesn't know the difference
> between them.
These statements inherently contradict one another. If the package
didn't know the difference between them, then the result would be
this:
add package:name -> some function definition
add package:name -> some class definition
<overwrites, since package doesn't tell functions and classes apart>
Output:
package:name -> some class definition
For this to be avoided, the package has to not merely associate a
symbol with a pointer of some kind to its referent, but it also has to
key those associations not on the symbol alone but also on some sort
of type tag:
add package:name(function) -> some function definition
add package:name(class) -> some class definition
<does not overwrite>
Output:
package:name(function) -> some function definition
package:name(class) -> some class definition
> However, when EVAL hits a name, it knows the difference /
> in context/ between a variable, function call, etc. The package
> doesn't have to know.
It does, if only implicitly. If EVAL changes the name "name" to a
symbol using whatever scope-resolution rules, and then changes the
symbol "package:name" to a symbol/type-tag pair "package:name(class)"
that is then the lookup key in the package system for the referent
pointer, then you may be technically correct, in that the package
system may consider the type-tag in this hypothetical implementation
to be a "magic cookie" without meaning to it other than with respect
to equality comparisons (and, under the hood, probably hash codes).
However, it could then be fairly stated that the package system knows
something about classes, functions, and the like -- it just doesn't
know that it knows.
> > > > > Not making it external means that other
> > > > > programmers could :use the package that has useful code which
> > > > > internally uses the new method, but they wouldn't have to worry about
> > > > > the original functionality of the same generic function, and could use
> > > > > the original version in their code.
>
> > > > But problems will arise if they invoke that generic function on an
> > > > object of a type for which that package had added a "private" version
> > > > of the method, as noted above.
>
> > > Still makes no sense to me...
>
> > Since that is based on a description of Common Lisp package behavior
> > that Adlai posted, you should endeavor to figure out which one of you
> > is apparently mistaken about packages. At this time I have no basis
> > for choosing either of your interpretations over the other.
>
> I was mistaken
Ah.
> but not in the way that you thought.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Adlai.
> > > > > It's possible that I'm wrong about the details
>
> > > > This seems likely, given the extreme dubiousness of the design
> > > > decision of enabling a public generic function to have dispatches to
> > > > private methods when called with certain combinations of public
> > > > classes.
>
> > > What is a public generic function? What is a public class? What is a
> > > private method?
>
> > Public = exported. Private = not exported.
>
> These ideas don't translate so cleanly between Lisp and Java, because
> only symbols are "public" or "private". The code itself is still
> accessible to anybody who has the symbol reference.
The same is true in Java, in a certain sense:
public class Foo {
private static class X implements Runnable () {
public void run () {
System.out.println("Hello, world!");
}
}
public static Runnable getRunnable () {
return new X();
}
}
public class Main {
public static void main (String[] args) {
Foo.getRunnable().run();
}
}
=> "Hello, world!"
You can think of "Foo" as a package within which "getRunnable" is an
exported symbol and "X" is not, and therefore "X.run" is also not.
However, "getRunnable" provides access to an instance of X, and thus
(indirectly) to a reference to X.run, by means of polymorphic
dispatch. This is what allows Main's main method to invoke the run()
method.
A similar situation exists with reflection used in combination with
setAccessible(true).
Perhaps in this particular regard Java and Lisp are not so different
after all, aside from the very obvious syntax differences.
> > So whereas there is arguably a distinction to be made, in practice
> > it's a pointless one: "the method is private" is more or less
> > synonymous with "the method's name is private".
>
> Firstly, Lisp has a lot more freedom, in the sense that "private"
> stuff is not inaccessible; this does mean that you have to rely on
> people not to use private things in a way that will cause them to
> break.
The issue was that Lisp also does less to discourage this practice
than Java does, and apparently completely lacks a security model for
situations such as browsers running untrusted code, though admittedly
the latter scenario could not even have been envisioned in 1956, when
the closest anyone had come to guessing the future existence of
anything like the Web was Vannevar Bush with his concept of a "memex".
Which would have been mechanical, to the Web as a Babbage analytical
engine would have been to a computer.
> However, multimethod dispatch is done in a very safe and
> predictable way, so it's not a risk to allow user-defined code do
> "call-next-method" to something which could be considered "private" to
> an imported package.
This does not parse, but it nonetheless emits the distinctive odor of
handwavium, a notoriously dangerous and unstable substance, especially
when introduced into a high-temperature usenet thread such as this
one.
> > You're forgetting that, by your own prior testimony, the defmethod
> > macro in turn adds the dispatch entry. So whether you do it by hand,
> > or have the macro do it for you, the dispatch table must be accessible
> > to you.
>
> Yes, I could get to the dispatch table. I have no clue how to do it,
> although I could find out by examining the macroexpansion of
> DEFGENERIC and DEFMETHOD, and then essentially writing that code by
> hand. However, this is not done, unless somebody wants to create their
> own object system; it would be like editing the Java compiler by hand,
> yourself.
Intermediate, I should say, closer to editing the source code for
java.lang.ClassLoader, or maybe even to simply subclassing that.
> > > > You omit to mention adding a dispatch to the generic function that
> > > > invokes your new method. Somewhere in the code base the generic
> > > > function's dispatch table lives, resembling anonymous_c_lisper's
> > > > example for a generic function named "frobnobdicate". This dispatch
> > > > table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
> > > > obj) to call your new method when both arguments are my-objs. How is
> > > > this entry to be added?
>
> > > Again, no such table exists in source.
>
> > Again, macros operate by transforming source, so if this were true,
> > the defmethod macro could not function in the manner you have claimed.
>
> Lisp image != source.
The Lisp image is the program state when running. Macros operate at
compile time, before (that build of) the program can possibly have
run.
> > That is not a valid argument against my reasoning. It is, rather, a
> > "cop-out". It is also an arrogant presumption on your part, purporting
> > to be able to speak for gugamilare as you have just done.
>
> We assume (and I think I speak for others who have posted in response
> to you and Seamus) that when somebody else says something that seems
> wrong, it's a "thinko", rather than a real mistake.
I fail to see the distinction, though I note that you are once again
presuming to speak for other people -- this time a large number of
them.
> A thinko is like a typo, but on the scale of ideas -- it's an easily
> identifiable MISTAKE
This statement directly contradicts the preceding one, which implied
some sort of distinction existed between a "thinko" and a "mistake".
> gugamilare seems, from other things he's said in this group in the
> past, to be more knowledgeable in Lisp than I am. If he writes
> something that could be read a bit ambiguously, I'm assuming it's
> because of a) the fact that English doesn't seem to be his first
> language (which is NO PROBLEM WHATSOEVER, you just have to THINK), and
This might be interpreted in two ways itself: one, that English not
being one's first language is not a problem for a budding Lisp
programmer; or two, as a personal attack. I do sincerely hope your
intended meaning was not the latter.
> b) he's assuming that the people reading his comments are familiar
> with basic Common Lisp concepts.
Given that the comments in question have been crossposted to
comp.lang.java.programmer, such an assumption would appear to be
rather suspect.
> > > > I find it interesting that when one of you says something, I repeat
> > > > it, and another of you contradicts it, it frequently proves to have
> > > > originated with gugamilare. Perhaps you should settle your internal
> > > > disagreements first, rather than debate comp.lang.java.programmer with
> > > > a disunited front?
>
> > > No offense intended, but haven't you thought that maybe the
> > > contradictions are between your assumptions and what other people say
> > > to you?
>
> > Of course not, since the contradictions in question are contradictions
> > between a statement made by one of you and a statement made by another
> > of you. No assumption that I made could alter either statement in any
> > such case -- you each said whatever you said.
>
> > For instance, supposing you were to say that the sky was green, and
> > gugamilare that it was blue, these statements would contradict,
> > independently of my own personal opinion on the matter or of any
> > assumptions on my part.
>
> See what I said in my previous paragraph, it applies here too. By the
> way, I would assume that somebody saying that the sky was green would
> also be a THINKO -- maybe they meant to type blue, or meant to talk
> about grass. These things happen when people are multitasking, as we
> all often have to. I would assume that the person I'm talking with has
> made a thinko unless they repeat the same mistake several times, in
> different phrasings, and defend it when somebody tries to correct
> them.
Your paragraph above seems to consist partly of excuse-making. The
more serious problem, however, is that it presupposes that all readers
of such contradictory pairs of posts will have some easy means of
deciding which statement, if either, was accurate. That is quite
evidently not the case when the posts at issue are crossposted to a
newsgroup whose population cannot, by and large, be expected to have
the necessary knowledge to make that judgment, and can therefore only
go by what people have said.
Particularly, when a statement is made that will participate in such a
contradiction, but is the first such statement made so that the others
do not yet exist, and that first statement is an erroneous one, there
is not, as yet, even a contradiction to call that statement into
question. Of course, the statement may lead immediately to an
illogical conclusion, and in some cases here that has happened. In
other cases, however, it is only when a large group of statements is
taken together than they collectively imply something preposterous,
and then until one of those statements is contradicted, it is possible
for none of them to stand out as particularly suspect, at least as
judged by a lay person.
In a way, it is similar to how lack of static typing can obfuscate the
source of a problem that is caused by a type error in the code. All
statements that touch the problem data are viable suspects, and one
must start with the point where something finally blew up, a clash of
some sort between an expected and an actual type, and then work one's
way backwards to find out which was in error, the expectation or the
actual type, and where this error initially occurred.
Perhaps you should solve this the way dynamic-typing advocates like
you so often do, by unit-testing everything to death. Proofreading one
another's usenet posts might be a good way to start. You might also
use such a mechanism as a means of dispassionate review and a source
of a "cooling off" delay, to reduce the amount of personal attacks and
other illogical, emotional, and unwanted noise that currently leaks
unproductively into both newsgroups.
On May 20, 7:32 pm, Series Expansion <·······@gmail.com> wrote:
> On May 17, 6:28 pm, Adlai <·········@gmail.com> wrote:
> Altering the behavior of that not-yours code via macro is hardly a
> successful evasion of my point. In fact it compounds it, for not only
> are you still effectively altering the behavior of that code, but
> furthermore, you are causing changes at remote locations in the code
> base via macro use, which I previously contended was a hazard of Lisp
> macros and which your group repeatedly denied could happen. Yet now,
> when it suits you, you admit that it can, indeed, happen.
Macros never change the code itself. A defmethod form would add to the
generic function as it existed in the currently running Lisp image,
when the defmethod form was evaluated. However, it would NEVER alter
the code itself.
> Furthermore, being able to define a method, but not append a dispatch
> for it to a generic function, would not address the issue in which
> such dispatch was essential to your plan.
The expansion code generated by a defmethod form deals with adding it
to the generic function's dispatch. It even creates the generic
function if none exists yet.
> > > (defgeneric frobnobdicate (a b)
> > > (:method ((foo foo) (bar bar)) ;;arguments
> > > .. body)
> > > (:method ((foo foo) (baz baz))
> > > .. body)
> > > (:method ((foo foo) (quux quux))
> > > .. body)
> > > (:method ((foo foo) (quux quux))
> > > ..different body))
>
> > > will fail in some manner or another.
>
> > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > foo a-quux) will be overwritten by the second method.
>
> That would constitute perhaps the worst possible failure: it silently
> works incorrectly, neither alerting anyone to the conflict nor
> satisfying everyone's requirements.
The compiler emits warnings when things get redefined unexpectadly.
Also -- writing code like that is not a good idea, and I doubt would
ever be done in practice. That code is almost like writing x = 1 / 0.
If you're thinking of what happens when you override an existing
method with a defmethod form in your code -- the compiler will emit a
warning in that situation.
> That is not possible. The defmethod body itself may be local to that
> package, but the added dispatch table entry/ies will be local to the
> package containing the generic function of which it is the newest
> method-member.
Packages don't contain dispatch tables, they contain symbols. A
dispatch table for a generic fn only exists within the Lisp image
after some code has created a generic fn -- not local to any package.
This is why you need to understand the Lisp package system to critique
various aspects of the language that interact with it.
> This would also make it difficult to use polymorphic objects widely in
> a system without importing a large number of packages just about
> everywhere in the code base, effectively somewhat diluting the name-
> collision-avoiding capabilities of the package system.
If you've compiled some code, the definitions in it are reflected in
the running Lisp image. Packages control symbol references, however,
you don't have to import a package for references to symbols in that
package to work in code that the Lisp image is already running.
> > It's possible that I'm wrong about the details
>
> This seems likely, given the extreme dubiousness of the design
> decision of enabling a public generic function to have dispatches to
> private methods when called with certain combinations of public
> classes.
There's not really a public/private distinction in Lisp packages.
There are just uninterned symbols (gensyms go here), and symbols
interned in packages.
> > You don't have to have access to the source code with the defgeneric
> > form to add a method.
>
> No, just to add a dispatch entry to call that method.
Nope. DEFMETHOD takes care of that.
> You omit to mention adding a dispatch to the generic function that
> invokes your new method. Somewhere in the code base the generic
> function's dispatch table lives, resembling anonymous_c_lisper's
> example for a generic function named "frobnobdicate". This dispatch
> table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
> obj) to call your new method when both arguments are my-objs. How is
> this entry to be added?
DEFMETHOD does it. I couldn't for the life of me tell you exactly how,
but when CLOS was written 20-some years ago, they designed it well.
DEFMETHOD forms add to the dispatch table of a generic function,
without messing with source code, just by updating the Lisp image.
> let me guess: you're going to do it anyway? And make some utterly
> preposterous claim?
>
> > I do know that using a good Lisp system -- and there are free
> > ones -- gets you the best of both worlds in type systems.
>
> Yes, and yes. Particularly preposterous this time. It's
> straightforward excluded middle: you can't simultaneously both have
> and lack static type checking.
You have static type checking on variables for which you declare
types, and you don't have it for undeclared variables.
Since it rubs you the wrong way when I say "should", I'll put it this
way: Please read up (either in these posts, or elsewhere aka here
http://www.flownet.com/ron/packages.pdf about the Lisp package system)
- Adlai
PS -- Ignore the name of the package tutorial. It's not intended to be
an insult.
On May 20, 1:40 pm, Adlai <·········@gmail.com> wrote:
> Macros never change the code itself. A defmethod form would add to the
> generic function as it existed in the currently running Lisp image,
> when the defmethod form was evaluated. However, it would NEVER alter
> the code itself.
That IS "the code itself", albeit the object code itself rather than
the source code itself.
> > Furthermore, being able to define a method, but not append a dispatch
> > for it to a generic function, would not address the issue in which
> > such dispatch was essential to your plan.
>
> The expansion code generated by a defmethod form deals with adding it
> to the generic function's dispatch. It even creates the generic
> function if none exists yet.
How can it do so, if, as you claim, it doesn't alter the code? Recall
that the dispatch appears to be explicit in source code, to judge by
the example code posted by anonymous.c.lisper previously in this
thread.
> > > > (defgeneric frobnobdicate (a b)
> > > > (:method ((foo foo) (bar bar)) ;;arguments
> > > > .. body)
> > > > (:method ((foo foo) (baz baz))
> > > > .. body)
> > > > (:method ((foo foo) (quux quux))
> > > > .. body)
> > > > (:method ((foo foo) (quux quux))
> > > > ..different body))
>
> > > > will fail in some manner or another.
>
> > > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > > foo a-quux) will be overwritten by the second method.
>
> > That would constitute perhaps the worst possible failure: it silently
> > works incorrectly, neither alerting anyone to the conflict nor
> > satisfying everyone's requirements.
>
> The compiler emits warnings when things get redefined unexpectadly.
This is inconsistent with your own previous claim that it wouldn't
fail; "just" a method would get overwritten. The word "just" implies
that no other effects would occur. A compiler warning would be an
additional effect.
> Also -- writing code like that is not a good idea, and I doubt would
> ever be done in practice. That code is almost like writing x = 1 / 0.
How fortunate that we have macros to write code like that for us,
then. A few defmethods in the right places could invisibly amount to
the same thing as that, without being anywhere near as easy to locate.
> If you're thinking of what happens when you override an existing
> method with a defmethod form in your code -- the compiler will emit a
> warning in that situation.
Again, we have now heard both statements that there will be a warning
and statements implying otherwise from you. It is not at all clear
which to believe.
> > That is not possible. The defmethod body itself may be local to that
> > package, but the added dispatch table entry/ies will be local to the
> > package containing the generic function of which it is the newest
> > method-member.
>
> Packages don't contain dispatch tables, they contain symbols.
This again. The point is that the dispatch table belongs to a generic
function, and that function's name is in some particular package. The
dispatch table thus effectively belongs to that package.
Most computer programmers consider the things named to belong to
namespaces however their names belong, as a convenient shorthand. Why
you Lispers apparently feel the need to remind people constantly that
only the names technically and directly do, I do not know, but it
complicates and slows down communication to eschew the useful
shorthand.
> A dispatch table for a generic fn only exists within the Lisp image
This contradicts an earlier posting by anonymous.c.lisper.
> This is why you need to understand the Lisp package system to critique
> various aspects of the language that interact with it.
This is condescending. Moreover, it seems to try to impute blame to me
for supposedly not understanding something that you have done a
remarkably poor job of explaining coherently. I believe a remark about
stones and glass houses might be apropos; the inconsistencies in your
own side's position imply that you are misunderstanding things
yourselves. I on the other hand am understanding you perfectly, but
what you say you yourself sometimes subsequently disagree with.
> > This would also make it difficult to use polymorphic objects widely in
> > a system without importing a large number of packages just about
> > everywhere in the code base, effectively somewhat diluting the name-
> > collision-avoiding capabilities of the package system.
>
> If you've compiled some code, the definitions in it are reflected in
> the running Lisp image. Packages control symbol references, however,
> you don't have to import a package for references to symbols in that
> package to work in code that the Lisp image is already running.
So some of this stuff only works if you load part of the program,
start that running, and then load the rest? That sounds like a recipe
for trouble, and for install and configuration headaches for end-users
even.
> > > It's possible that I'm wrong about the details
>
> > This seems likely, given the extreme dubiousness of the design
> > decision of enabling a public generic function to have dispatches to
> > private methods when called with certain combinations of public
> > classes.
>
> There's not really a public/private distinction in Lisp packages.
Exported/non-exported, public/private ... differences of terminology
only. This is no more cogent an argument against what I said than a
spelling flame would be.
> > > You don't have to have access to the source code with the defgeneric
> > > form to add a method.
>
> > No, just to add a dispatch entry to call that method.
>
> Nope. DEFMETHOD takes care of that.
Whether you do it manually or you do it by employing automation, you
still do it.
> > You omit to mention adding a dispatch to the generic function that
> > invokes your new method. Somewhere in the code base the generic
> > function's dispatch table lives, resembling anonymous_c_lisper's
> > example for a generic function named "frobnobdicate". This dispatch
> > table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
> > obj) to call your new method when both arguments are my-objs. How is
> > this entry to be added?
>
> DEFMETHOD does it. I couldn't for the life of me tell you exactly how,
> but when CLOS was written 20-some years ago, they designed it well.
I have, as yet, seen precious little evidence to support that claim.
> DEFMETHOD forms add to the dispatch table of a generic function,
> without messing with source code, just by updating the Lisp image.
Macros are compile-time. How can one alter the running code, if it no
longer exists by the time that code begins to actually run?
> > let me guess: you're going to do it anyway? And make some utterly
> > preposterous claim?
>
> > > I do know that using a good Lisp system -- and there are free
> > > ones -- gets you the best of both worlds in type systems.
>
> > Yes, and yes. Particularly preposterous this time. It's
> > straightforward excluded middle: you can't simultaneously both have
> > and lack static type checking.
>
> You have static type checking on variables for which you declare
> types, and you don't have it for undeclared variables.
That would mean that you have it. But it was stated previously that
Lisp is dynamically typed. The contradiction remains unresolved.
On May 23, 12:47 pm, Series Expansion <·······@gmail.com> wrote:
> On May 20, 1:40 pm, Adlai <·········@gmail.com> wrote:
[a missing attribution goes here]
> > > That is not possible. The defmethod body itself may be local to that
> > > package, but the added dispatch table entry/ies will be local to the
> > > package containing the generic function of which it is the newest
> > > method-member.
>
> > Packages don't contain dispatch tables, they contain symbols.
>
> This again. The point is that the dispatch table belongs to a generic
> function, and that function's name is in some particular package. The
> dispatch table thus effectively belongs to that package.
>
> Most computer programmers consider the things named to belong to
> namespaces however their names belong, as a convenient shorthand. Why
> you Lispers apparently feel the need to remind people constantly that
> only the names technically and directly do, I do not know, but it
> complicates and slows down communication to eschew the useful
> shorthand.
Because names and symbols are different things in Lisp. Names are
symbol's printed representations. If a symbol is within the current
package, there's no need to distinguish between its name and the
symbol itself. If the symbol is not internet in ANY package then
they're distinct, and in fact a one-way connection -- the name doesn't
help you one bit in locating the symbol.
- Adlai
On May 23, 2:22 pm, Adlai <·········@gmail.com> wrote:
> On May 23, 12:47 pm, Series Expansion <·······@gmail.com> wrote:> On May 20, 1:40 pm, Adlai <·········@gmail.com> wrote:
> [a missing attribution goes here]
More than one, I'd wager.
> > > > That is not possible. The defmethod body itself may be local to that
> > > > package, but the added dispatch table entry/ies will be local to the
> > > > package containing the generic function of which it is the newest
> > > > method-member.
>
> > > Packages don't contain dispatch tables, they contain symbols.
>
> > This again. The point is that the dispatch table belongs to a generic
> > function, and that function's name is in some particular package. The
> > dispatch table thus effectively belongs to that package.
>
> > Most computer programmers consider the things named to belong to
> > namespaces however their names belong, as a convenient shorthand. Why
> > you Lispers apparently feel the need to remind people constantly that
> > only the names technically and directly do, I do not know, but it
> > complicates and slows down communication to eschew the useful
> > shorthand.
>
> Because names and symbols are different things in Lisp. Names are
> symbol's printed representations. If a symbol is within the current
> package, there's no need to distinguish between its name and the
> symbol itself.
This is silly. You use "names" and "symbols" the way we use "names"
and "fully-qualified names", and then use this terminology difference
as a basis for arguing in favor of much more terminological pedantry?
This does nothing useful; it just impedes clear communication, and
provides you a handy excuse to ignore a detailed critique without
seeming to do so by lobbing grenades at superficial terminology
quibbles, use of (unambiguous) short-hand, and the like without
addressing the meat of that critique. Such an argument, however, has
the same problem as the following syllogism, though it may appear
otherwise if done cleverly enough:
A: The syk is blue.
B: A misspelled the word "sky" when attempting to state that it was
blue; therefore the sky is green.
On May 20, 11:32 am, Series Expansion <·······@gmail.com> wrote:
[ Lot's of snipping ]
> > > It seems quite obvious that adding another method, this one with a new
> > > class quux as a second argument type, would require editing that code
> > > to:
>
> > > (defgeneric frobnobdicate (a b)
> > > (:method ((foo foo) (bar bar)) ;;arguments
> > > .. body)
> > > (:method ((foo foo) (baz baz))
> > > .. body)
> > > (:method ((foo foo) (quux quux))
> > > ..body))
>
> > > The problem arises if it is not your code to edit. Then you cannot add
> > > a frobnobdicate method to your quux class.
>
> > Actually, you can, just nobody pointed it out yet. There's a defmethod
> > macro
>
> Altering the behavior of that not-yours code via macro is hardly a
> successful evasion of my point. In fact it compounds it, for not only
> are you still effectively altering the behavior of that code, but
> furthermore, you are causing changes at remote locations in the code
> base via macro use, which I previously contended was a hazard of Lisp
> macros and which your group repeatedly denied could happen. Yet now,
> when it suits you, you admit that it can, indeed, happen.
Actually, the DEFMETHOD macro does not alter the behavior directly, it
macro-expands to an ENSURE-METHOD function call. ENSURE-METHOD creates
a new method metaobject and adds it to the generic function with ADD-
METHOD. ADD-METHOD adds the method to the generic function's list of
methods and to each of the specializers' list of direct methods. This
is verbatim text I've assembled from "The Art of the Metaobject
Protocol".
So, the hazard of changing the behavior of an existing method is not
really associated with macros, it is just the hazard of redefining the
behavior of an existing function. That's why a good Common Lisp
implementation warns you when you do it. Furthermore, you can set
*BREAK-ON-SIGNALS* to an appropriate level to invoke the debugger when
it occurs so that your input is immediately required before the
program proceeds, or not if it suites you.
> Supplanting others' code is one of the capabilities that I had
> previously noted to be fraught with hazard.
A good(most, at least all that I have used) Common Lisp implementation
warns you when this occurs so that you may take the appropriate action
and mitigate the hazard.
> Furthermore, being able to define a method, but not append a dispatch
> for it to a generic function, would not address the issue in which
> such dispatch was essential to your plan.
Fortunately, the ADD-METHOD function does just that.
> It seems that it is not possible in Lisp to simultaneously avoid both
> of the above issues.
It is possible to avoid both of the above issues.
> > - defgeneric and defmethod are both examples of machine-generated
> > code, in a very similar way to how the JVM bytecode generated by
> > Java's class definition syntax is "machine-generated".
>
> The implication had been made that not only were tables like in
> anonymous_c_lisper's code snippet compiled, like other Lisp source
> code, to bytecode, but that those tables were themselves created or
> modified by automated tools.
If by automated tools, you mean the ENSURE-METHOD and ADD-METHOD
functions, I suppose that's correct. How the internals of these
functions actually operate is an implementation detail that is only of
concern to the implementers.
> > Lisp's object system is implemented all in "normal" non-OO Lisp
>
> This has already been mentioned elsewhere, and while it does not help
> you on the generic function modification issue, it actively hurts you
> on the type-safety issue, since it corroborates my claim there that
> the compiler cannot type-check CLOS code since it cannot safely make
> assumptions about the presence or nature of any object systems in the
> code.
If you'll expand on this statement or direct me to a previous post
that expands on it, I'll attempt to address it. The point you are
trying to make is not clear from the above information.
>
> > > (defgeneric frobnobdicate (a b)
> > > (:method ((foo foo) (bar bar)) ;;arguments
> > > .. body)
> > > (:method ((foo foo) (baz baz))
> > > .. body)
> > > (:method ((foo foo) (quux quux))
> > > .. body)
> > > (:method ((foo foo) (quux quux))
> > > ..different body))
>
> > > will fail in some manner or another.
>
> > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > foo a-quux) will be overwritten by the second method.
>
> That would constitute perhaps the worst possible failure: it silently
> works incorrectly, neither alerting anyone to the conflict nor
> satisfying everyone's requirements.
I was unable to find the specified behavior for a duplicate
specialized lambda list passed to the :METHOD option of DEFGENERIC. I
performed a little experiment in the implementation that I use and the
second method was ignored. It should be stressed, though, that
the :METHOD option has limited utility and most times methods are
added to a generic function with DEFMETHOD. If you are using
the :METHOD option to add methods to a generic function, then they
will necessarily be collected in one place, so when you test your
methods and observe the incorrect behavior, you will know exactly
where to look to correct the problem. Otherwise, you will have defined
the method with DEFMETHOD and the implementation will have given you a
warning that there was a redefinition.
> > > This particular corner of the debate is but one of many where evidence
> > > has surfaced that strongly suggests that Lisp is centered around a
> > > lone-wolf development model and, in particular, that in its present
> > > form as described by you it is unsuited to use by a large team. Pair
> > > programming may well be the largest team size up to which it will
> > > scale given the numerous issues that have come to light.
>
> > Not necessarily. A defmethod form overriding or supplanting a generic
> > fn's capabilities will only apply to code within the package that
> > defmethod form appears in.
>
> That is not possible. The defmethod body itself may be local to that
> package, but the added dispatch table entry/ies will be local to the
> package containing the generic function of which it is the newest
> method-member.
>
> Indeed, this raises the possibility that a reference to an object of a
> type defined in the former package, and to which the method in
> question applies, will escape into the system to eventually be
> referenced by a variable in code defined in a different package.
> Presumably the generic function is visible there, including the
> dispatch entry for that particular type. However, you claim the method
> body is inaccessible there. It follows that if that code invokes that
> method on that variable, while it is holding that object, the dispatch
> table entry will effectively be pointing nowhere.
>
> In C, invoking a dangling function pointer tends to result in a crash.
> Whereas I expect Lisp to be somewhat better behaved in a certain
> sense, a run-time exception or similar occurrence seems likely.
>
> This would also make it difficult to use polymorphic objects widely in
> a system without importing a large number of packages just about
> everywhere in the code base, effectively somewhat diluting the name-
> collision-avoiding capabilities of the package system.
>
> > Not making it external means that other
> > programmers could :use the package that has useful code which
> > internally uses the new method, but they wouldn't have to worry about
> > the original functionality of the same generic function, and could use
> > the original version in their code.
>
> But problems will arise if they invoke that generic function on an
> object of a type for which that package had added a "private" version
> of the method, as noted above.
>
> > It's possible that I'm wrong about the details
Adlai, you were wrong about the details and therefore the response by
SE is not addressable.
> This seems likely, given the extreme dubiousness of the design
> decision of enabling a public generic function to have dispatches to
> private methods when called with certain combinations of public
> classes.
In the CLOS, there are no such things as a private or public methods,
so this statement is not addressable.
> > > Even supposing that one were to have dispatch tables like the above,
> > > widely-used macros, and similar constructs gate-kept by "owners"
> > > within a larger development team, all requests to for instance add a
> > > new dispatch to a generic function would have to go through the
> > > appropriate gatekeepers. Whereupon the scaling problems described in
> > > __The_Mythical_Man_Month__ come into play full-force; the volume of
> > > such requests will tend to grow as the square of the number of
> > > developers, and the number received by the owner of a particular piece
> > > of such code will tend to grow linearly, soon overwhelming them. The
> > > encapsulation and modularity of code offered by OO languages like Java
> > > reduces this problem enormously, as only defining and changing widely-
> > > used interfaces requires that level of coordination, and everyone can
> > > work within the encapsulation walls of their classes as if alone
> > > without fear that they will tread upon any toes. Even if they wish to
> > > put a frobnobdicate method into a class named quux that they use to
> > > implement their piece of the program, and other frobnobdicate methods
> > > already exist.
>
> > You don't have to have access to the source code with the defgeneric
> > form to add a method.
>
> No, just to add a dispatch entry to call that method.
There is no need to manually add a dispatch entry, this is handled by
ADD-METHOD.
>
> > > > >> Being able to create generic functions that work with objects created by
> > > > >> others (say in some library code you are using) is a nice way to add
> > > > >> functionality that the library authors didn't anticipate.
>
> > > > > I'm more concerned with being able to create objects that work with
> > > > > generic functions created by others.
>
> > > > Be concerned no longer. What would stop you from doing that?
>
> > > I believe the concerns I have were adequately outlined above, with
> > > code examples and a detailed explanation of the scaling problems,
> > > supported by mathematical calculations and a reference. If you find
> > > that insufficient, I am not sure that I can be of further assistance
> > > to you in understanding the matter.
>
> > Once you created your object, you'd just add a few more lines after
> > the class definition (as opposed to in the class definition for the
> > Comparable stuff, if I understood your Java example correctly). These
> > lines would consist of a defmethod for the generic fn you were
> > interested in extending to support your object -- for example,
> > (defmethod compare ((my-obj x) (my-obj y)) code-goes-here). This would
> > not break any previous functionality of the COMPARE generic fn, except
> > for overwriting any previous method when both arguments are my-objs --
> > but in this example that wouldn't be the case because you're making a
> > new class.
>
> You omit to mention adding a dispatch to the generic function that
> invokes your new method. Somewhere in the code base the generic
> function's dispatch table lives, resembling anonymous_c_lisper's
> example for a generic function named "frobnobdicate". This dispatch
> table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
> obj) to call your new method when both arguments are my-objs. How is
> this entry to be added?
This entry is added by ADD-METHOD. Details can be found in "The Art of
the Metaobject Protocol".
[ Snipped text that contained nothing addressable. ]
Hope that helps,
Tom
On May 20, 9:44 pm, "Thomas M. Hermann" <··········@gmail.com> wrote:
> Adlai, you were wrong about the details and therefore the response by
> SE is not addressable.
Thank you for correcting me, Thomas.
- Adlai
On May 20, 2:44 pm, "Thomas M. Hermann" <··········@gmail.com> wrote:
> On May 20, 11:32 am, Series Expansion <·······@gmail.com> wrote:
[an attribution is missing here]
> > > Actually, you can, just nobody pointed it out yet. There's a defmethod
> > > macro
>
> > Altering the behavior of that not-yours code via macro is hardly a
> > successful evasion of my point. In fact it compounds it, for not only
> > are you still effectively altering the behavior of that code, but
> > furthermore, you are causing changes at remote locations in the code
> > base via macro use, which I previously contended was a hazard of Lisp
> > macros and which your group repeatedly denied could happen. Yet now,
> > when it suits you, you admit that it can, indeed, happen.
>
> Actually, the DEFMETHOD macro does not alter the behavior directly, it
> macro-expands to an ENSURE-METHOD function call. [rest of irrelevant
> technical details deleted]
Whether it does it directly or indirectly, and how it does so, has no
bearing on the matter at hand.
> So, the hazard of changing the behavior of an existing method is not
> really associated with macros, it is just the hazard of redefining the
> behavior of an existing function.
The hazard still exists. My complaints about macros were centered
around variable capture, not around function redefinition.
> > Supplanting others' code is one of the capabilities that I had
> > previously noted to be fraught with hazard.
>
> A good(most, at least all that I have used) Common Lisp implementation
> warns you when this occurs so that you may take the appropriate action
> and mitigate the hazard.
How will this work in a large-team development effort? Collisions in
team members' code and naming may cause this, without it being easy to
determine what should be changed or which calls are supposed to refer
to which version of the method.
> > Furthermore, being able to define a method, but not append a dispatch
> > for it to a generic function, would not address the issue in which
> > such dispatch was essential to your plan.
>
> Fortunately, the ADD-METHOD function does just that.
The issue then raised is the original one, regarding modifications
that "draw outside the box". Whether these modifications are carried
out by hand (as in anonymous.c.lisper's example code) or via macro or
via function does not materially alter the cause for concern.
> > It seems that it is not possible in Lisp to simultaneously avoid both
> > of the above issues.
>
> It is possible to avoid both of the above issues.
No, it is not. Your argument that "'twasn't me that done it, 'twas the
macro I invoked!" would not hold up in a murder trial and it does not
hold up here.
> > > - defgeneric and defmethod are both examples of machine-generated
> > > code, in a very similar way to how the JVM bytecode generated by
> > > Java's class definition syntax is "machine-generated".
>
> > The implication had been made that not only were tables like in
> > anonymous_c_lisper's code snippet compiled, like other Lisp source
> > code, to bytecode, but that those tables were themselves created or
> > modified by automated tools.
>
> If by automated tools, you mean the ENSURE-METHOD and ADD-METHOD
> functions, I suppose that's correct.
And there it is.
> How the internals of these functions actually operate is an
> implementation detail that is only of concern to the implementers.
Not when it's scribbling all over my code, it's not.
> > > Lisp's object system is implemented all in "normal" non-OO Lisp
>
> > This has already been mentioned elsewhere, and while it does not help
> > you on the generic function modification issue, it actively hurts you
> > on the type-safety issue, since it corroborates my claim there that
> > the compiler cannot type-check CLOS code since it cannot safely make
> > assumptions about the presence or nature of any object systems in the
> > code.
>
> If you'll expand on this statement or direct me to a previous post
> that expands on it, I'll attempt to address it. The point you are
> trying to make is not clear from the above information.
It was in reference to another branch of this debate, where the perils
of lacking static type checking were at issue. There have been recent
posts to that branch.
> > > > (defgeneric frobnobdicate (a b)
> > > > (:method ((foo foo) (bar bar)) ;;arguments
> > > > .. body)
> > > > (:method ((foo foo) (baz baz))
> > > > .. body)
> > > > (:method ((foo foo) (quux quux))
> > > > .. body)
> > > > (:method ((foo foo) (quux quux))
> > > > ..different body))
>
> > > > will fail in some manner or another.
>
> > > I don't think it'll "fail"; just the first method for (frobnobdicate a-
> > > foo a-quux) will be overwritten by the second method.
>
> > That would constitute perhaps the worst possible failure: it silently
> > works incorrectly, neither alerting anyone to the conflict nor
> > satisfying everyone's requirements.
>
> I was unable to find the specified behavior for a duplicate
> specialized lambda list passed to the :METHOD option of DEFGENERIC. I
> performed a little experiment in the implementation that I use and the
> second method was ignored.
Silent failure confirmed. Thanks.
> If you are using the :METHOD option to add methods to a generic
> function, then they will necessarily be collected in one place, so
> when you test your methods and observe the incorrect behavior, you will
> know exactly where to look to correct the problem.
That presumes that the cause of the incorrect behavior will be readily
apparent. It may initially present as subtle logic errors, however,
that could conceivably result from any of a myriad of causes. This is
especially likely as a name collision like the hypothetical one
probably results from an attempt to create two distict, but very
similar methods. The effect of all intended calls to one going to the
other could therefore be quite small, though perhaps cumulative,
depending on how nonlinear the effects are.
> > This seems likely, given the extreme dubiousness of the design
> > decision of enabling a public generic function to have dispatches to
> > private methods when called with certain combinations of public
> > classes.
>
> In the CLOS, there are no such things as a private or public methods
This degree of pedantry is unproductive. But if you prefer, I shall
say a generic function whose name is exported, dispatching to methods
whose names are not, when called with certain combinations of classes
whose names are exported. Although from the length and cumbersome
structure of the preceding sentence I hope you will understand why
programmers of most other languages prefer the brevity of the terms
"private" and "public".
> > > > Even supposing that one were to have dispatch tables like the above,
> > > > widely-used macros, and similar constructs gate-kept by "owners"
> > > > within a larger development team, all requests to for instance add a
> > > > new dispatch to a generic function would have to go through the
> > > > appropriate gatekeepers. Whereupon the scaling problems described in
> > > > __The_Mythical_Man_Month__ come into play full-force; the volume of
> > > > such requests will tend to grow as the square of the number of
> > > > developers, and the number received by the owner of a particular piece
> > > > of such code will tend to grow linearly, soon overwhelming them. The
> > > > encapsulation and modularity of code offered by OO languages like Java
> > > > reduces this problem enormously, as only defining and changing widely-
> > > > used interfaces requires that level of coordination, and everyone can
> > > > work within the encapsulation walls of their classes as if alone
> > > > without fear that they will tread upon any toes. Even if they wish to
> > > > put a frobnobdicate method into a class named quux that they use to
> > > > implement their piece of the program, and other frobnobdicate methods
> > > > already exist.
>
> > > You don't have to have access to the source code with the defgeneric
> > > form to add a method.
>
> > No, just to add a dispatch entry to call that method.
>
> There is no need to manually add a dispatch entry, this is handled by
> ADD-METHOD.
Who said anything about "manually"?
> > You omit to mention adding a dispatch to the generic function that
> > invokes your new method. Somewhere in the code base the generic
> > function's dispatch table lives, resembling anonymous_c_lisper's
> > example for a generic function named "frobnobdicate". This dispatch
> > table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
> > obj) to call your new method when both arguments are my-objs. How is
> > this entry to be added?
>
> This entry is added by ADD-METHOD.
Automation is irrelevant to the issue at hand.
> [ Snipped text that contained nothing addressable. ]
I suspect this is intended to imply a personal attack. That would
constitute shameful conduct on your part, however.
(I'm only replying in C.L.L to this, as I don't see how this is of
interest to java programmers... I am reluctant to reply at all.)
On May 17, 5:41 pm, Series Expansion <·······@gmail.com> wrote:
> On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>
> > Considering his opinions on Jews
>
> By some standards, the pro-Java side just won the debate right there.
>
> > Series Expansion <·······@gmail.com> writes:
>
> [an attribution is missing here, but it was obviously a Lisp partisan]
>
> > >> Methods DO NOT BELONG TO CLASSES. Instead they are organized base on
> > >> the function they perform. Each such "generic function" is a particular
> > >> operation. Methods are added to the generic function to handle
> > >> particular argument types (via dynamic multiple dispatch). So the
> > >> methods really belong to the generic function.
>
> > > Adding methods might be a problem then, if the generic function you
> > > need to edit is in library code you don't control.
>
> > Then it's a good thing it's not necessary to edit any generic functions
> > to add methods, isn't it?
>
> This statement contradicts an earlier statement that the means by
> which methods are dispatched is through generic functions, which
> contain dispatch tables that reference all of the methods that they
> can dispatch.
>
not really :-)
> In <····································@n8g2000vbb.googlegroups.com>
> anonymous_c_lisper posted an example of a generic function:
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> ..body))
>
> It seems quite obvious that adding another method, this one with a new
> class quux as a second argument type, would require editing that code
> to:
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> .. body)
> (:method ((foo foo) (quux quux))
> ..body))
>
> The problem arises if it is not your code to edit. Then you cannot add
> a frobnobdicate method to your quux class.
>
> There appear to be only three alternatives here:
> 1. The problem arises;
> 2. anonymous_c_lisper was wrong about something; or
> 3. You are wrong about something.
>
Or neither of us is wrong because there is more than one way to define
a generic function method. :-)
> The suggestion floated recently that code like the above be generated
> by automation does not materially alter the parameters of this debate.
> The above alteration, whether automated or not, poses a problem if the
> code is not yours to modify, and an even larger problem if conflicting
> modifications are made by different developers whose code will
> eventually be combined, granting the assumption that
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> .. body)
> (:method ((foo foo) (quux quux))
> .. body)
> (:method ((foo foo) (quux quux))
> ..different body))
>
> will fail in some manner or another.
>
The second method would overwrite the first.
> Imagine the chaos if there was a master list of all classes that
> implemented "Comparable" for example and for anyone to add
> comparability to a class in their corner of the codebase had to get it
> approved so the owner of the comparable-classes list could add it to
> the list, this list being needed by the JVM to dispatch compare()
> method invocations. Fortunately Java was not designed this way, but if
> we replace compare() with frobnobdicate, we see that we have precisely
> the described situation in Lisp, at least according to what
> anonymous_c_lisper wrote and making some obvious inferences therefrom.
Obvious /incorrect/ inferences, unfortunately.
Sadly one can't explain the entire language through Usenet.
(And I believe I did mention defmethod in the original post, not that
it has meaning to you)
On May 17, 6:57 pm, ··················@gmail.com wrote:
> (I'm only replying in C.L.L to this, as I don't see how this is of
> interest to java programmers... I am reluctant to reply at all.)
Then perhaps you shouldn't have. However, replying but restricting the
post solely to a group I do not regularly read smacks of intellectual
dishonesty, where you consider it more important to get the last word
than to actually be right.
> On May 17, 5:41 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> > > Considering his opinions on Jews
>
> > By some standards, the pro-Java side just won the debate right there.
>
> > > Series Expansion <·······@gmail.com> writes:
> > [an attribution is missing here, but it was obviously a Lisp partisan]
> > > >> Methods DO NOT BELONG TO CLASSES. Instead they are organized base on
> > > >> the function they perform. Each such "generic function" is a particular
> > > >> operation. Methods are added to the generic function to handle
> > > >> particular argument types (via dynamic multiple dispatch). So the
> > > >> methods really belong to the generic function.
> > > > Adding methods might be a problem then, if the generic function you
> > > > need to edit is in library code you don't control.
> > > Then it's a good thing it's not necessary to edit any generic functions
> > > to add methods, isn't it?
> > This statement contradicts an earlier statement that the means by
> > which methods are dispatched is through generic functions, which
> > contain dispatch tables that reference all of the methods that they
> > can dispatch.
>
> not really :-)
Yes, really.
> > In <····································@n8g2000vbb.googlegroups.com>
> > anonymous_c_lisper posted an example of a generic function:
>
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > ..body))
>
> > It seems quite obvious that adding another method, this one with a new
> > class quux as a second argument type, would require editing that code
> > to:
>
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > .. body)
> > (:method ((foo foo) (quux quux))
> > ..body))
>
> > The problem arises if it is not your code to edit. Then you cannot add
> > a frobnobdicate method to your quux class.
>
> > There appear to be only three alternatives here:
> > 1. The problem arises;
> > 2. anonymous_c_lisper was wrong about something; or
> > 3. You are wrong about something.
>
> Or
But there was no fourth alternative.
> > The suggestion floated recently that code like the above be generated
> > by automation does not materially alter the parameters of this debate.
> > The above alteration, whether automated or not, poses a problem if the
> > code is not yours to modify, and an even larger problem if conflicting
> > modifications are made by different developers whose code will
> > eventually be combined, granting the assumption that
>
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > .. body)
> > (:method ((foo foo) (quux quux))
> > .. body)
> > (:method ((foo foo) (quux quux))
> > ..different body))
>
> > will fail in some manner or another.
>
> The second method would overwrite the first.
Now I know the precise failure mode. Not that I have much use for that
information.
> > Imagine the chaos if there was a master list of all classes that
> > implemented "Comparable" for example and for anyone to add
> > comparability to a class in their corner of the codebase had to get it
> > approved so the owner of the comparable-classes list could add it to
> > the list, this list being needed by the JVM to dispatch compare()
> > method invocations. Fortunately Java was not designed this way, but if
> > we replace compare() with frobnobdicate, we see that we have precisely
> > the described situation in Lisp, at least according to what
> > anonymous_c_lisper wrote and making some obvious inferences therefrom.
>
> Obvious /incorrect/ inferences, unfortunately.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, anonymous.c.lisper.
Series Expansion <·······@gmail.com> writes:
> On May 16, 8:15�pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>> Considering his opinions on Jews
>
> By some standards, the pro-Java side just won the debate right there.
>
>> Series Expansion <·······@gmail.com> writes:
> [an attribution is missing here, but it was obviously a Lisp partisan]
>> >> Methods DO NOT BELONG TO CLASSES. �Instead they are organized base on
>> >> the function they perform. �Each such "generic function" is a particular
>> >> operation. �Methods are added to the generic function to handle
>> >> particular argument types (via dynamic multiple dispatch). �So the
>> >> methods really belong to the generic function.
>>
>> > Adding methods might be a problem then, if the generic function you
>> > need to edit is in library code you don't control.
>>
>> Then it's a good thing it's not necessary to edit any generic functions
>> to add methods, isn't it?
>
> This statement contradicts an earlier statement that the means by
> which methods are dispatched is through generic functions, which
> contain dispatch tables that reference all of the methods that they
> can dispatch.
>
> In <····································@n8g2000vbb.googlegroups.com>
> anonymous_c_lisper posted an example of a generic function:
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> ..body))
>
> It seems quite obvious that adding another method, this one with a new
> class quux as a second argument type, would require editing that code
> to:
>
> (defgeneric frobnobdicate (a b)
> (:method ((foo foo) (bar bar)) ;;arguments
> .. body)
> (:method ((foo foo) (baz baz))
> .. body)
> (:method ((foo foo) (quux quux))
> ..body))
In the twenty years I read usenet, I never saw anybody as dumb as
Series Expansion. Even gavino makes some progress sometimes.
Series: you haven't noticed the numerous examples given in those posts
where defmethod was used to define additionnal methods to a generic
function.
--
__Pascal Bourguignon__
On May 17, 6:19 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 16, 8:15 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> >> Then it's a good thing it's not necessary to edit any generic functions
> >> to add methods, isn't it?
>
> > This statement contradicts an earlier statement that the means by
> > which methods are dispatched is through generic functions, which
> > contain dispatch tables that reference all of the methods that they
> > can dispatch.
>
> > In <····································@n8g2000vbb.googlegroups.com>
> > anonymous_c_lisper posted an example of a generic function:
>
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > ..body))
>
> > It seems quite obvious that adding another method, this one with a new
> > class quux as a second argument type, would require editing that code
> > to:
>
> > (defgeneric frobnobdicate (a b)
> > (:method ((foo foo) (bar bar)) ;;arguments
> > .. body)
> > (:method ((foo foo) (baz baz))
> > .. body)
> > (:method ((foo foo) (quux quux))
> > ..body))
>
> In the twenty years I read usenet, I never saw anybody as dumb as
> Series Expansion. Even gavino makes some progress sometimes.
Remarkable. A lucid and cogent argument is "rebutted" not with reason
but with a particularly uninspired and unimaginative ad hominem
argument.
> Series: you haven't noticed the numerous examples given in those posts
> where defmethod was used to define additionnal methods to a generic
> function.
Was not defmethod used to define individual polymorphic variations,
but defgeneric used to create the dispatch table that called one or
another version depending upon the argument types?
Regardless, explicitly managed dispatch tables appeared in the post by
anonymous_c_lisper, and their very presence inherently raises the
questions that I asked.
Series Expansion wrote:
> On May 15, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> (BTW, this is caused by the inability to add methods to a Java class
>> once it is defined. Another nice, flexible benefit of CLOS).
>
> Another potential source of headaches too, I'll warrant. Imagine the
> chaos that would ensue if Java did allow this. S
Language War! Language War!
--
Lew
making popcorn and settling in to watch
["Followup-To:" header set to comp.lang.lisp.]
On 2009-05-15, Lew <···@lewscanon.com> wrote:
> Stefan Ram wrote:
>> The same coded in Java without macros /is/ more verbose,
>> but also more readable to someone who knows Java:
>>
>> public static String getMultiValue( Object valueObject )
>> { String result = null;
>> if( valueObject == null )result = null;
>>
>> else if( valueObject instanceof StringValue )
>> { StringValue stringValue =( StringValue )valueObject;
>> result = getStringValue( stringValue ); }
>>
>> else if( valueObject instanceof SprayValue )
>> { SprayValue setValue =( SprayValue )valueObject;
>> result = getSetValue( setValue ); }
>>
>> return result; }
>
> An experienced Java programmer will see this series of 'instanceof'
> operators and look for a way to code the thing polymorphically.
>
> interface Multi<T>
> {
> public String getValue( T arg );
> }
This is cheating; you are redefining the object's type to suit the code.
Now valueObject must be a Multi<something> .
Can you make this gadget Just Work on the type Object?
Common Lisp:
(defmethod get-value ((obj string-value))
(get-string-value obj))
(defmethod get-value ((obj spray-value))
(get-spray-value obj))
Done; now we can juse use get-value to pull out the value of ither a
string-value or a spray-value.
> class StringVersion implements Multi<String>
> {
> public String getValue( String arg )
> {
> return getStringValue( arg );
> }
> }
Even worse, you are wrapping objects now, yuck.
God for job security in tough economic times, though.
On 15 maio, 10:47, ····@zedat.fu-berlin.de (Stefan Ram) wrote:
> ····@informatimago.com (Pascal J. Bourguignon) writes:
>
> >Well at that point I can only say that, well over here we're not (all)
> >raving maniacs, that we have useful tools that help solve or obviate a
> >lot of problems found with other programming languages, and point to
> >that tutorial:http://www.lisperati.com/casting.html
>
> Assume for a moment I had advanced macro capabilities in Java.
> I'd write:
>
> public static String getMultiValue( Object valueObject )
> { String result = null;
> if( valueObject == null )result = null;
>
> else if( StringValue stringValue =? valueObject )
> result = getStringValue( stringValue );
>
> else if( SprayValue sprayValue =? valueObject )
> result = getSetValue( setValue );
>
> return result; }
>
> The macro here is marked by the occurence of »=?«, which is
> not a regular Java operator, but part of my hypothetical macro
> call pattern.
>
> The problem here is readability:
>
> Can others know, what »=?« means in my macro package?
> Can they know how to immediately find its documentation?
>
May I say that your macro is very lame and useless? Here is a good
example of what a good macro can do. CL doesn't have a way to
serialize functions to a file. This library (I wrote it)
http://github.com/gugamilare/storable-functions/
makes this possible. It does not rely on any internal representation
of the functions by some implementation - this would make the code
unportable - but it provides a macro that retrieves the function's
body to be stored into a file and then restored back again. It is as
simple as this: instead of writing (lambda (...) ...) you write (st
(lambda (...) ...).
In Java I am pretty sure this isn't conceivable because
1) Java does not have dynamically created functions (or am I wrong?)
2) Java Code is not an easy manipulable data
3) Java doesn't have macros.
As you can see, macros not only provide a way to make your
applications shorter or more readable, but they also make it possible
to do somethings that otherwise couldn't be done.
On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
> It does not rely on any internal representation
> of the functions by some implementation - this would make the code
> unportable - but it provides a macro that retrieves the function's
> body to be stored into a file and then restored back again. It is as
> simple as this: instead of writing (lambda (...) ...) you write (st
> (lambda (...) ...).
Cool. But why store a function that's there in your code anyway?
Also, the commonplace lisp problem of short names. The name "st" in
particular isn't particularly clear in meaning, and moreover, you'll
quickly run out of short names to use in a big enough project anyway.
> In Java I am pretty sure this isn't conceivable because
>
> 1) Java does not have dynamically created functions (or am I wrong?)
> 2) Java Code is not an easy manipulable data
> 3) Java doesn't have macros.
>
> As you can see, macros not only provide a way to make your
> applications shorter or more readable, but they also make it possible
> to do somethings that otherwise couldn't be done.
Java is Turing-complete, so it can probably be done.
You can certainly implement an interpreter in Java that can save and
load its code. This also lets the function be created at run-time from
other data or user-input.
You can also monkey about with ClassLoader and byte arrays and
bytecode, or (since Java 6) with ClassLoader, Compiler, and Strings
full of Java source code, and make classes on the fly, save them to
disk (e.g. as .class files), load them, instantiate them (with
reflection), and invoke them (with reflection, or polymorphically
through a compile-time-known base class or interface).
So yeah, Java can do it, though it's clunky. And Java can do it with
"functions" created on the fly, not just some existing one like
Math.sin(double). In the case of using ClassLoader and eventually
calling the object via a base class or interface rather than
reflection, and using a JIT-enabled JVM, it can even run the new
function with performance rivaling compiled and optimized C code.
On 15 May, 19:30, Series Expansion <·······@gmail.com> wrote:
> On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
>
> > It does not rely on any internal representation
> > of the functions by some implementation - this would make the code
> > unportable - but it provides a macro that retrieves the function's
> > body to be stored into a file and then restored back again. It is as
> > simple as this: instead of writing (lambda (...) ...) you write (st
> > (lambda (...) ...).
>
> Cool. But why store a function that's there in your code anyway?
>
> Also, the commonplace lisp problem of short names. The name "st" in
> particular isn't particularly clear in meaning, and moreover, you'll
> quickly run out of short names to use in a big enough project anyway.
There is no "commonplace lisp problem of short names". If you want
to write long descriptive names in Lisp you can do it just fine.
On May 15, 2:42 pm, Spiros Bousbouras <······@gmail.com> wrote:
> On 15 May, 19:30, Series Expansion <·······@gmail.com> wrote:
> > Also, the commonplace lisp problem of short names. The name "st" in
> > particular isn't particularly clear in meaning, and moreover, you'll
> > quickly run out of short names to use in a big enough project anyway.
>
> There is no "commonplace lisp problem of short names". If you want
> to write long descriptive names in Lisp you can do it just fine.
That doesn't help you much when you have to use pre-existing code, or
implementation-standard names. ("car", anyone?)
On 15 May, 20:17, Series Expansion <·······@gmail.com> wrote:
> On May 15, 2:42 pm, Spiros Bousbouras <······@gmail.com> wrote:
>
> > On 15 May, 19:30, Series Expansion <·······@gmail.com> wrote:
> > > Also, the commonplace lisp problem of short names. The name "st" in
> > > particular isn't particularly clear in meaning, and moreover, you'll
> > > quickly run out of short names to use in a big enough project anyway.
>
> > There is no "commonplace lisp problem of short names". If you want
> > to write long descriptive names in Lisp you can do it just fine.
>
> That doesn't help you much when you have to use pre-existing code,
If someone decided to use short names in their code that may be
considered a problem with that particular piece of code but it's
certainly not a problem with Lisp. Lisp doesn't force anyone to
use short names.
> or implementation-standard names. ("car", anyone?)
If a name is part of the core language then every Lisp
programmer will know what it means , there's no need for long
descriptive names. Do you think it would be an improvement for
Lisp if car had a longer name?
--
Who's your mama?
Spiros Bousbouras wrote:
> If someone decided to use short names in their code that may be
> considered a problem with that particular piece of code but it's
> certainly not a problem with Lisp. Lisp doesn't force anyone to
> use short names.
>
>> or implementation-standard names. ("car", anyone?)
This really says it all, doesn't it? :)
From: Thomas A. Russ
Subject: Re: macros (was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <ymid4aann3g.fsf@blackcat.isi.edu>
Series Expansion <·······@gmail.com> writes:
> On May 15, 2:42��pm, Spiros Bousbouras <······@gmail.com> wrote:
> > On 15 May, 19:30, Series Expansion <·······@gmail.com> wrote:
> > > Also, the commonplace lisp problem of short names. The name "st" in
> > > particular isn't particularly clear in meaning, and moreover, you'll
> > > quickly run out of short names to use in a big enough project anyway.
> >
> > There is no "commonplace lisp problem of short names". If you want
> > to write long descriptive names in Lisp you can do it just fine.
>
> That doesn't help you much when you have to use pre-existing code, or
> implementation-standard names. ("car", anyone?)
"first"?
Are you being deliberately provocative, or just obtuse?
--
Thomas A. Russ, USC/Information Sciences Institute
On May 15, 4:10 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 2:42Ž pm, Spiros Bousbouras <······@gmail.com> wrote:
> > > On 15 May, 19:30, Series Expansion <·······@gmail.com> wrote:
> > > > Also, the commonplace lisp problem of short names. The name "st" in
> > > > particular isn't particularly clear in meaning, and moreover, you'll
> > > > quickly run out of short names to use in a big enough project anyway.
>
> > > There is no "commonplace lisp problem of short names". If you want
> > > to write long descriptive names in Lisp you can do it just fine.
>
> > That doesn't help you much when you have to use pre-existing code, or
> > implementation-standard names. ("car", anyone?)
>
> "first"?
I do not understand the question, unless it was to suggest a slightly-
longer but more-intuitive name for what they called "car".
(The rest I won't dignify with a response.)
Series Expansion <·······@gmail.com> writes:
> On May 15, 2:42�pm, Spiros Bousbouras <······@gmail.com> wrote:
>> On 15 May, 19:30, Series Expansion <·······@gmail.com> wrote:
>> > Also, the commonplace lisp problem of short names. The name "st" in
>> > particular isn't particularly clear in meaning, and moreover, you'll
>> > quickly run out of short names to use in a big enough project anyway.
>>
>> There is no "commonplace lisp problem of short names". If you want
>> to write long descriptive names in Lisp you can do it just fine.
>
> That doesn't help you much when you have to use pre-existing code, or
> implementation-standard names. ("car", anyone?)
And you don't HAVE to use implementation-standard names.
(defpackage "MY-LISP-WITHOUT-CAR"
(:nickname "MY-LISP")
(:use "CL")
(:export "CONTENT-OF-ADDRESS-PART-OF-REGISTER"
"CONTENT-OF-DECREMENT-PART-OF-REGISTER"))
(do-external-symbols (sym "CL")
(unless (member sym '(car cdr #|...|#))
(export sym "MY-LISP-WITHOUT-CAR")))
(setf (symbol-function 'my-lisp:content-of-address-part-of-register) (symbol-function 'car))
(setf (symbol-function 'my-lisp:content-of-decrement-part-of-register) (symbol-function 'cdr))
and now, in your programs instead of writing:
(defpackage "MY-PROGRAM" (:use "CL"))
you will write:
(defpackage "MY-PROGRAM" (:use "MY-LISP"))
(in-package "MY-PROGRAM")
(content-of-address-part-of-register (cons 1 2)) ; --> 1
(content-of-decrement-part-of-register (cons 1 2)) ; --> 2
What we've done here is to define a new language, one which is almost
like Common Lisp, but where car and cdr are actually named
content-of-address-part-of-register and
content-of-decrement-part-of-register.
--
__Pascal Bourguignon__
On May 15, 7:27 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 2:42 pm, Spiros Bousbouras <······@gmail.com> wrote:
> >> On 15 May, 19:30, Series Expansion <·······@gmail.com> wrote:
> >> > Also, the commonplace lisp problem of short names. The name "st" in
> >> > particular isn't particularly clear in meaning, and moreover, you'll
> >> > quickly run out of short names to use in a big enough project anyway.
>
> >> There is no "commonplace lisp problem of short names". If you want
> >> to write long descriptive names in Lisp you can do it just fine.
>
> > That doesn't help you much when you have to use pre-existing code, or
> > implementation-standard names. ("car", anyone?)
>
> And you don't HAVE to use implementation-standard names.
>
> (defpackage "MY-LISP-WITHOUT-CAR"
> (:nickname "MY-LISP")
> (:use "CL")
> (:export "CONTENT-OF-ADDRESS-PART-OF-REGISTER"
> "CONTENT-OF-DECREMENT-PART-OF-REGISTER"))
> (do-external-symbols (sym "CL")
> (unless (member sym '(car cdr #|...|#))
> (export sym "MY-LISP-WITHOUT-CAR")))
> (setf (symbol-function 'my-lisp:content-of-address-part-of-register) (symbol-function 'car))
> (setf (symbol-function 'my-lisp:content-of-decrement-part-of-register) (symbol-function 'cdr))
>
> and now, in your programs instead of writing:
>
> (defpackage "MY-PROGRAM" (:use "CL"))
>
> you will write:
>
> (defpackage "MY-PROGRAM" (:use "MY-LISP"))
> (in-package "MY-PROGRAM")
> (content-of-address-part-of-register (cons 1 2)) ; --> 1
> (content-of-decrement-part-of-register (cons 1 2)) ; --> 2
>
> What we've done here is to define a new language, one which is almost
> like Common Lisp, but where car and cdr are actually named
> content-of-address-part-of-register and
> content-of-decrement-part-of-register.
*breaks down and cries*
The horror, the horror...
You can't win. It's put up with short names, or put up with the
equivalent of the C code some dweebs write that starts with #define
BEGIN {.
Series Expansion <·······@gmail.com> writes:
> On May 15, 7:27�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > On May 15, 2:42�pm, Spiros Bousbouras <······@gmail.com> wrote:
>> >> On 15 May, 19:30, Series Expansion <·······@gmail.com> wrote:
>> >> > Also, the commonplace lisp problem of short names. The name "st" in
>> >> > particular isn't particularly clear in meaning, and moreover, you'll
>> >> > quickly run out of short names to use in a big enough project anyway.
>>
>> >> There is no "commonplace lisp problem of short names". If you want
>> >> to write long descriptive names in Lisp you can do it just fine.
>>
>> > That doesn't help you much when you have to use pre-existing code, or
>> > implementation-standard names. ("car", anyone?)
>>
>> And you don't HAVE to use implementation-standard names.
>>
>> (defpackage "MY-LISP-WITHOUT-CAR"
>> � �(:nickname "MY-LISP")
>> � �(:use "CL")
>> � �(:export "CONTENT-OF-ADDRESS-PART-OF-REGISTER"
>> � � � � � � "CONTENT-OF-DECREMENT-PART-OF-REGISTER"))
>> (do-external-symbols (sym "CL")
>> � (unless (member sym '(car cdr #|...|#))
>> � � (export sym "MY-LISP-WITHOUT-CAR")))
>> (setf (symbol-function 'my-lisp:content-of-address-part-of-register) � (symbol-function 'car))
>> (setf (symbol-function 'my-lisp:content-of-decrement-part-of-register) (symbol-function 'cdr))
>>
>> and now, in your programs instead of writing:
>>
>> � (defpackage "MY-PROGRAM" (:use "CL"))
>>
>> you will write:
>>
>> � (defpackage "MY-PROGRAM" (:use "MY-LISP"))
>> � (in-package "MY-PROGRAM")
>> � (content-of-address-part-of-register � (cons 1 2)) ; --> 1
>> � (content-of-decrement-part-of-register (cons 1 2)) ; --> 2
>>
>> What we've done here is to define a new language, one which is almost
>> like Common Lisp, but where car and cdr are actually named
>> content-of-address-part-of-register and
>> content-of-decrement-part-of-register.
>
> *breaks down and cries*
>
> The horror, the horror...
>
> You can't win. It's put up with short names, or put up with the
> equivalent of the C code some dweebs write that starts with #define
> BEGIN {.
Of course I won! 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.
And I did that easily and quickly in the course of a usenet discussion.
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.
If as a free lance I find it economically wise to invest in CL,
perhaps corportations could do some accounting and realize that it
might be worthwhile to avoid having to rewrite all their software all
the time, just because a new feature has been added or another removed
from Java (or Ruby or Python or Perl, etc).
--
__Pascal Bourguignon__
On May 16, 10:34 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 15, 7:27 pm, ····@informatimago.com (Pascal J. Bourguignon)
> >> What we've done here is to define a new language, one which is almost
> >> like Common Lisp, but where car and cdr are actually named
> >> content-of-address-part-of-register and
> >> content-of-decrement-part-of-register.
>
> > *breaks down and cries*
>
> > The horror, the horror...
>
> > You can't win. It's put up with short names, or put up with the
> > equivalent of the C code some dweebs write that starts with #define
> > BEGIN {.
>
> 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 <·······@gmail.com> writes:
> On May 16, 10:34 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>> 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.
Has Pascal gotten that much better at UI design since then (assuming the
had UIs)?
Paul Donnelly wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 16, 10:34 am, ····@informatimago.com (Pascal J. Bourguignon)
>> wrote:
>>
>>> 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.
>
> Has Pascal gotten that much better at UI design since then (assuming the
> had UIs)?
Portuguese is a better language than English.
--
Lew
On May 17, 12:50 pm, Lew <·····@lewscanon.com> wrote:
> Paul Donnelly wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> But they're just as obsolete. If nothing else, their user interfaces
> >> will be woefully subpar by modern standards.
>
> > Has Pascal gotten that much better at UI design since then (assuming the
> > had UIs)?
>
> Portuguese is a better language than English.
This racist non-sequitur does not constitute a rational argument in
favor of either Lisp or Java, "Lew".
Series Expansion <·······@gmail.com> writes:
> On May 16, 10:34�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > On May 15, 7:27�pm, ····@informatimago.com (Pascal J. Bourguignon)
>> >> What we've done here is to define a new language, one which is almost
>> >> like Common Lisp, but where car and cdr are actually named
>> >> content-of-address-part-of-register and
>> >> content-of-decrement-part-of-register.
>>
>> > *breaks down and cries*
>>
>> > The horror, the horror...
>>
>> > You can't win. It's put up with short names, or put up with the
>> > equivalent of the C code some dweebs write that starts with #define
>> > BEGIN {.
>>
>> 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.
Not at all. This is done every days by lisp programmers and no such
thing occurs.
>> 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.
You are not the one to say whether they'd be obsolete or not, only
their users.
And corporations may have something else to do, and something else to
finance, than to pay java programmers to follow the fashion of the day
in GUI for their mission critical software.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 16, 10:34 am, ····@informatimago.com (Pascal J. Bourguignon)
>> wrote:
>>> Series Expansion <·······@gmail.com> writes:
>>>> On May 15, 7:27 pm, ····@informatimago.com (Pascal J. Bourguignon)
>>>>> What we've done here is to define a new language, one which is almost
>>>>> like Common Lisp, but where car and cdr are actually named
>>>>> content-of-address-part-of-register and
>>>>> content-of-decrement-part-of-register.
>>>> *breaks down and cries*
>>>> The horror, the horror...
>>>> You can't win. It's put up with short names, or put up with the
>>>> equivalent of the C code some dweebs write that starts with #define
>>>> BEGIN {.
>>> 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.
>
> Not at all. This is done every days by lisp programmers and no such
> thing occurs.
>
>
>>> 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.
>
> You are not the one to say whether they'd be obsolete or not, only
> their users.
>
> And corporations may have something else to do, and something else to
> finance, than to pay java [sic] programmers to follow the fashion of the day
> in GUI for their mission critical software.
Spelling counts.
--
Lew
On May 17, 12:51 pm, Lew <·····@lewscanon.com> wrote:
> Pascal J. Bourguignon wrote:
> > You are not the one to say whether they'd be obsolete or not, only
> > their users.
>
> > And corporations may have something else to do, and something else to
> > finance, than to pay java [sic] programmers to follow the fashion of the day
> > in GUI for their mission critical software.
>
> Spelling counts.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Pascal.
On May 17, 8:39 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 16, 10:34 am, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> 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.
>
> Not at all.
Responding by simply calling your opponent a liar is rarely a viable
strategy for either a) winning a debate or b) making friends and
influencing people.
Particularly when anyone of normal intelligence would have recognized
the quoted passage as intentionally hyperbolic.
> >> 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.
>
> You are not the one to say whether they'd be obsolete or not, only
> their users.
How do you know I'm not one of the users of one of these applications?
Regardless, Lisp appears to have been designed for a simple line-
oriented-terminal model of interaction, much like bare-bones ANSI C,
actually, which requires third-party libraries to even do curses-type
stuff, let alone graphics and mouse support. Unlike C, it seems
difficult for such libraries to exist when Lisp, unlike C, compiles to
bytecode. Certainly third-party Java libraries cannot, unless they use
JNI, directly access hardware and thereby attain capabilities
involving interfacing with the hardware or the host OS that weren't
built into the JVM or the standard libraries. And I have not heard of
any Lisp facility analogous to JNI. So unless the LVM (or whatever you
want to call it) provides a particular form of host-system interface,
it is apparently unavailable to programs.
In my browsings around the net, the free Lisp implementations I've
come across seem to all be line-oriented. While it's possible that
I've missed something, it looks like the facilities required to create
a more capable UI are unavailable outside of expensive commercial
implementations.
However, even if those "programs you wrote twenty years ago" run on
such a commercial implementation, they can't use graphics facilities
or the like that did not yet exist twenty years ago. Their user
interfaces will be vintage 1989 user interfaces, which tended at best
to be curses-like ones.
> And corporations may have something else to do, and something else to
> finance, than to pay java programmers to follow the fashion of the day
> in GUI for their mission critical software.
It is not a matter of fashion, but of ergonomics. Making the software
easier to interact with could enormously boost productivity, unless
it's an infrequently-used batch-mode program or something similar.
Moreover, improving the software's ergonomics could reduce error rates
in its use. Ergonomic improvements in other aspects of workplace
technology have had all of the following effects in various times and
places:
* Increased productivity
* Reduced workplace accidents
* Improved job satisfaction
* Reduced the cost of training new hires
* Boosted comfort, in cases affecting posture and physical
activities of employees, and reduced stress, physical
strain, and repetitive stress injuries
and more.
Series Expansion <·······@gmail.com> writes:
> In my browsings around the net, the free Lisp implementations I've
> come across seem to all be line-oriented. While it's possible that
> I've missed something, it looks like the facilities required to create
> a more capable UI are unavailable outside of expensive commercial
> implementations.
http://www.inspiration.com/videos/InspireData
Done in Lisp.
Frank GOENNINGER wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> In my browsings around the net, the free Lisp implementations I've
>> come across seem to all be line-oriented. While it's possible that
>> I've missed something, it looks like the facilities required to create
>> a more capable UI are unavailable outside of expensive commercial
>> implementations.
>
> http://www.inspiration.com/videos/InspireData
>
> Done in Lisp.
Lisp is off-topic for a Java newsgroup.
--
Lew
Lew <·····@lewscanon.com> writes:
> Frank GOENNINGER wrote:
>> Series Expansion <·······@gmail.com> writes:
>>
>>> In my browsings around the net, the free Lisp implementations I've
>>> come across seem to all be line-oriented. While it's possible that
>>> I've missed something, it looks like the facilities required to create
>>> a more capable UI are unavailable outside of expensive commercial
>>> implementations.
>>
>> http://www.inspiration.com/videos/InspireData
>>
>> Done in Lisp.
>
> Lisp is off-topic for a Java newsgroup.
Your comment is off-topic for a any newsgroup.
Lew, you did better before...
Series, this is a brief attempt to explain to you how Lisp macros CAN
do what you say is impossible for a macro to do:
Firstly, a Lisp macro can run code, just like any function, which it
uses to produce its expansion code. Thus, the output of a Lisp macro
is not limited to just the characters you type in -- it can create
unique symbols, and thus avoid the variable capture/multiple
evaluation problems.
GENSYM generates a unique symbol. In Lisp, symbols have print names,
which is how they appear to you when you type them or print them out,
but the symbol itself is actually not completely defined by its print
name; it's defined by a location in memory, and all references to that
symbol are actually references to that location. GENSYM simply makes a
new symbol, by pointing to a place that isn't pointed to yet. This is
dun at run-time, so GENSYM never generates a duplicate reference. The
print name (#:G123 or something like that) is purely for
distinguishing between GENSYMmed symbols when you read code printouts,
and if you typed in #:G123 to your code, it would not refer to the
same symbol.
Additionally, GENSYMmed symbols belong to no package. It's thus
impossible to reference them, unless you already have a reference to
the symbol. Basically, the only ways to reference a GENSYMmed symbol
are if you created it, or if you were passed a reference to it by
something that could reference it.
So this leads in to how Lisp macros can do the things you said were
impossible.
The macro creates however many new symbols it needs using gensym,
storing the reference to these symbols under various human-friendly
names. These names will never appear in the expansion code, however,
the macro will use them to insert references to the gensymmed symbols
into the expansion code.
If the macro wants to evaluate an arg only once but use the value more
than once, it stores the result from evaluating it into a gensymmed
symbol, and then simply uses that symbol again where it needs to.
If you want to create a new variable to do stuff in the expansion
code, but you don't want it possible to "mess" with this from outside
the expansion code, you can use a gensym too. This is how, for
example, you can say (loop repeat 5 (do-stuff-with x y z)) -- the loop
macro would use a gensym to keep track of how many times it had
executed the loop.
hth
- Adlai
On May 19, 5:22 am, Adlai <·········@gmail.com> wrote:
> Series, this is a brief attempt to explain to you how Lisp macros CAN
> do what you say is impossible for a macro to do
Why spend a lot of time writing an elaborate work of fiction and
posting it where it is so certain to go unappreciated?
> Firstly, a Lisp macro can run code, just like any function, which it
> uses to produce its expansion code. Thus, the output of a Lisp macro
> is not limited to just the characters you type in -- it can create
> unique symbols, and thus avoid the variable capture/multiple
> evaluation problems.
However, it can only compute functions of its arguments. It cannot,
from those alone, compute a variable name that will collide with none
from any larger enclosing scope unless there exists no larger
enclosing scope. This could only occur if it was, to use a colorful
phrase, "the macro that ate Manhattan".
> [elaborate discussion of Lisp equivalent of "new" operator]
Irrelevant.
> The macro creates however many new symbols it needs using gensym,
> storing the reference to these symbols under various human-friendly
> names. These names will never appear in the expansion code, however,
> the macro will use them to insert references to the gensymmed symbols
> into the expansion code.
These references must be variable names that are legal Lisp
identifiers, however, if the result of the expansion is to be
compilable Lisp code. The storage location of the object is
irrelevant. It is the collision of variable names that is of concern
here. When the compiler compiles the code containing the expanded
macro and its surroundings, the resolution of variable names will
still encounter the problems previously described.
It is as if you argued that if you took this Java code:
t = object1;
t = object2;
with the latter line expanded from a macro and changed that expansion
to:
t = new Object();
instead, that this would somehow cause that assignment to no longer
clobber the previous t = object1 assignment.
Yet the code has still (after expansion) got two assignments with the
same variable name on the left hand side. When the compiler then turns
it into bytecodes it will make the pointer for t point first to
object1 and then to the new (gensymmed) storage location, where
previously it would have pointed first to object1 and then to object2.
Of course, object2 was really "whatever the macro ends up assigning to
t", so, in effect, all that has been accomplished is to move object2
around in memory, and possibly to waste some memory.
That the new Object() address is unknown to any of the other code, and
cannot be discovered, is also true in the Java case and is also
irrelevant. It would matter if the problem we were concerned with was
aliasing:
x = object1;
t = object2; t.setFoo(true);
where we would not wish the setFoo(true) call to alter object1.
Ensuring that object2 is separate and unknown to the rest of the
program does indeed prevent such an unwanted side effect. But it does
not prevent the local variable being overwritten if the name is the
same. If the compiler sees t = object1; t = object2; it will resolve
both "t"s to the same stack position and the second assignment will
overwrite the first. There is no avoiding this unless the compiler
resolves the same name in the same scope to a pointer in an
inconsistent way, and that way lies madness.
> If the macro wants to evaluate an arg only once but use the value more
> than once, it stores the result from evaluating it into a gensymmed
> symbol, and then simply uses that symbol again where it needs to.
The manner in which storage for the variable's referent is allocated
is irrelevant to the concern at issue here. The issue is that for the
result of expanding the macro to refer to the stored value at all, it
must do so using a name, and the macro cannot compute from its
arguments alone such a name that can be guaranteed not to collide with
any name in any enclosing scope.
This is the inescapable trap. No diversionary tactics such as trying
to change the subject to memory allocation from variable names is
going to do more than delay the inevitable, which is the realization
that your macros have unavoidable difficulties.
The peculiar thing is, these difficulties should be well known within
the Lisp community. There can be no logical gain in strenuously
denying that they exist when they provably do and their existence is a
matter of public record.
> If you want to create a new variable to do stuff in the expansion
> code, but you don't want it possible to "mess" with this from outside
> the expansion code, you can use a gensym too. This is how, for
> example, you can say (loop repeat 5 (do-stuff-with x y z)) -- the loop
> macro would use a gensym to keep track of how many times it had
> executed the loop.
That it allocates a new memory location to hold the loop counter is
hardly surprising, nor revolutionary, nor relevant. It is the variable
name used to refer to this memory location that is at issue, and if
that name happens to collide with one in an enclosing scope, there
will be trouble. That the loop counter won't overwrite something else
in memory is admirable, but the pointer TO the loop counter may still
end up doing so.
(I will refrain from commenting at length upon the inefficiency of
having indirection like this for a simple loop counter. It is
unavoidable in a system whose native integer type is a bignum, and
potentially represented either as a machine integer or as an array of
such or some other representation. Another tradeoff, among many.)
On May 22, 2:39 pm, Series Expansion <·······@gmail.com> wrote:
> On May 19, 5:22 am, Adlai <·········@gmail.com> wrote:
> > [elaborate discussion of Lisp equivalent of "new" operator]
>
> Irrelevant.
No, it's got all the relevance in the world. The way symbols work in
Lisp makes it possible to generate never-seen-before symbols. Also, a
symbol's printed representation is not it's entire representation --
perhaps this would be clearer if a symbol were printed as something
like
#<SYMBOL #:G321 @ 0x4f209ac42b>
GENSYM is not the equivalent of the new operator. It doesn't need to
look at the code where a macro is being called from to do its job. All
GENSYM needs to do is examine the Lisp image and grab an unused
reference. This is not a 100% analogy, but it's like generating a
pointer to an empty reference, that can then be filled in. Also, due
to the concerns of garbage-collecting and symbolic programming, Lisp
always knows which symbol references are in use, so generating an
unused symbol is simple.
You have to understand this, to understand safe CL macros. Scheme
macros (which were mentioned a few times) work in a different way, but
they completely bar you from making "unsafe" behaviour -- CL, however,
lets you have the cake and eat it by giving you GENSYM. If you don't
understand GENSYM, then you won't understand much of what anybody says
about CL macros.
- Adlai
On May 22, 7:56 am, Adlai <·········@gmail.com> wrote:
> On May 22, 2:39 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 19, 5:22 am, Adlai <·········@gmail.com> wrote:
> > > [elaborate discussion of Lisp equivalent of "new" operator]
>
> > Irrelevant.
>
> No, it's got all the relevance in the world.
It does not.
> The way symbols work in Lisp makes it possible to generate
> never-seen-before symbols.
At run-time. This does not help you much with your problems with
macros, which occur at compile time. The macro must replace
some code
macro invocation (arguments)
other code
with
some code
macro result
other code
subsequent to which the latter is compiled by the compiler. If the
macro result contains a local variable, that code must contain
something of the form "(let (name" etc. etc. (or some other form that
binds a name) and if that same name happens to occur in the "some
code" portion a collision has occurred. What is more, the names that
occur in the "some code" portion cannot in general be computed from
only the macro invocation's arguments. More generally, the list of
names to avoid cannot in general be computed from only the macro
invocation's arguments.
The "(let (name" or similar is the problem, and it cannot in general
be avoided without resort to either global variables or multiple
evaluation. Even if the macro outputs code that, at run-time later,
will create a novel symbol (using the symbol table that exists in
memory at run time to find an unused one), that same code, at compile
time, must refer to this somehow. It must create a local variable that
refers to that symbol, and that can be used elsewhere in the macro's
output to refer to it again at need, and that local variable must have
a name, and that name will then be the potential cause of a collision.
Adding one layer of indirection does not solve the problem, though it
may well impair efficiency.
> Also, a symbol's printed representation is not it's entire representation
Not relevant. The printed representation is all that is available to
the compiler at compile-time. You are apparently suggesting that it is
possible for a macro to take code like
(let (foo ... ))
(macro (argument))
and expand it to
(let (foo ... ))
((let (foo ... ))
...)
with the property that somehow the compiler will know to treat the two
foos as separate, and without variable hiding. But how can it?
More significantly, what you are saying would require as a consequence
that hand-replacing a macro invocation with its expansion could result
in different behavior at run-time than having the expansion done by
the preprocessor pass of the compiler. This would be a violation of
the broadest reasonable definition of a macro.
The nutshell is this: while your "gensym" might well be globally
unique, the code output by the macro, and later compiled by the
compiler, must reference it somehow. That reference must involve a
name, if it is to be referenced more than once. And that name cannot
be guaranteed to be unique, even if its referent can.
> GENSYM is not the equivalent of the new operator. It doesn't need to
> look at the code where a macro is being called from to do its job. All
> GENSYM needs to do is examine the Lisp image and grab an unused
> reference.
See above. This must occur at run-time. I am concerned with what
occurs at compile time.
> This is not a 100% analogy, but it's like generating a
> pointer to an empty reference, that can then be filled in.
This indirection is possible in Java and C as well.
In Java, it is as if you had
WeakReference<T> foo = new WeakReference<T>(someTInstance);
Although the T instance now has no name, and the WeakReference created
at runtime is guaranteed not to collide with any local or global
variables, the name "foo" of the reference TO that reference may
collide with or hide other variables with the name "foo" in that and
enclosing scopes. (Ignore for now the effect of WeakReference on
garbage collection.)
In C, it is as if you had
void *foo = malloc(sizeof(void *));
*foo = &my_obj;
Now, *(*foo) is my_obj and the direct pointer to my_obj is stored in
formerly unallocated space; that is a reference to my_obj that cannot
collide with any other reference in the system, barring bugs in
pointer arithmetic making malloc() stop working correctly (an
unfortunate problem sometimes in C, but a preventable one, by
debugging the pointer use that causes the corruption.)
However, the reference TO that reference again has a name, "foo",
which may collide with other names in the same scope.
Most significantly, C has macros, and one could have a C macro
generate code like the above, malloc'ing a pointer to refer to a
temporary. However, the pointer to this reference must itself be
referenced so that it can be DEreferenced and that temporary used. And
that pointer must have a name for the compiler to be able to do its
job. And a list of all potentially-colliding names in the scope could
not in general be computed as any function of the macro's arguments,
even were C macros to be like Lisp ones, able to replace themselves
with arbitrary computable functions of their arguments.
You have asserted that the Lisp macro's ability to become any function
of its arguments grants it extraordinary powers. I have demonstrated
that one particular and important power you have attributed to them
cannot possibly occur as a result of that trait, however.
On May 25, 4:44 pm, ········@gmail.com wrote:
> On 23 Mag, 22:06, Series Expansion <·······@gmail.com> wrote:
>
> > [brain fuck]
>
> 42
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, java.oke.
On 26 Mag, 07:50, Series Expansion <·······@gmail.com> wrote:
> On May 25, 4:44 pm, ········@gmail.com wrote:
>
> > On 23 Mag, 22:06, Series Expansion <·······@gmail.com> wrote:
>
> > > [brain fuck]
>
> > 42
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, java.oke.
OK, Sorry for the Worry.
Now it's your turn (I'd suggest: "Sorry for Cross-Posting to c.l.l."
-- and I'm sure you meant the Clojure list --- and the "common" is
invisible in "comp.lang. .lisp").
On May 26, 3:48 am, ········@gmail.com wrote:
> On 26 Mag, 07:50, Series Expansion <·······@gmail.com> wrote:
>
> > On May 25, 4:44 pm, ········@gmail.com wrote:
>
> > > On 23 Mag, 22:06, Series Expansion <·······@gmail.com> wrote:
>
> > > > [brain fuck]
>
> > > 42
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, java.oke.
>
> OK, Sorry for the Worry.
>
> Now it's your turn (I'd suggest: "Sorry for Cross-Posting to c.l.l."
> -- and I'm sure you meant the Clojure list --- and the "common" is
> invisible in "comp.lang. .lisp").
Incoherent.
On May 28, 3:06 am, ········@gmail.com wrote:
> On 28 Mag, 07:23, Series Expansion <·······@gmail.com> wrote:
>
> > Incoherent.
>
> Last One Wins!
>
> Your answer:
Incoherent.
On 29 Mag, 04:59, Series Expansion <·······@gmail.com> wrote:
> > Your answer:
>
> Incoherent.
Kindergarten really has been a great time!!
Thanks for reminding me :)
On May 29, 2:35 am, ········@gmail.com wrote:
> On 29 Mag, 04:59, Series Expansion <·······@gmail.com> wrote:
>
> > > Your answer:
>
> > Incoherent.
>
> Kindergarten really has been a great time!!
Well, now your incoherence is satisfactorily explained: you are
apparently far too young to have mastered coherence yet.
On 30 Mag, 05:59, Series Expansion <·······@gmail.com> wrote:
> > Kindergarten really has been a great time!!
>
> Well, now your incoherence is satisfactorily explained: you are
> apparently far too young to have mastered coherence yet.
(To the public, other than "Too Serious of an Expansion":)
You see, if somebody is so full of himself to ignore the possibility
of self-criticism, it's simply too easy to trap them in any kind of
self-revelatory naive trap.
Anyway, thanks go to "Serious Expansion" for allowing me to
demonstrate you this kind of lesson.
-JO
On May 31, 9:07 am, ········@gmail.com wrote:
> On 30 Mag, 05:59, Series Expansion <·······@gmail.com> wrote:
>
> > > Kindergarten really has been a great time!!
>
> > Well, now your incoherence is satisfactorily explained: you are
> > apparently far too young to have mastered coherence yet.
>
> You see, if somebody is so full of himself [rest of obviously
> off-topic post deleted unread]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, java.oke.
Series Expansion <·······@gmail.com> writes:
> On May 31, 9:07 am, ········@gmail.com wrote:
>> On 30 Mag, 05:59, Series Expansion <·······@gmail.com> wrote:
>>
>> > > Kindergarten really has been a great time!!
>>
>> > Well, now your incoherence is satisfactorily explained: you are
>> > apparently far too young to have mastered coherence yet.
>>
>> You see, if somebody is so full of himself [rest of obviously
>> off-topic post deleted unread]
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, java.oke.
Since you're impenetrable to rational arguments, I don't see why anyone
would continue to waste time constructing them. Really, they should just
put you in their killfile, like I'm about to do.
On May 31, 11:28 pm, Paul Donnelly <·············@sbcglobal.net>
wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 31, 9:07 am, ········@gmail.com wrote:
> >> On 30 Mag, 05:59, Series Expansion <·······@gmail.com> wrote:
>
> >> > > Kindergarten really has been a great time!!
>
> >> > Well, now your incoherence is satisfactorily explained: you are
> >> > apparently far too young to have mastered coherence yet.
>
> >> You see, if somebody is so full of himself [rest of obviously
> >> off-topic post deleted unread]
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, java.oke.
>
> Since you're impenetrable to rational arguments [rest of obviously
> off-topic post deleted unread]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul.
On May 23, 4:06 pm, Series Expansion <·······@gmail.com> wrote:
-see above-
Series Expansion, I think you raise a lot of great issues that I am
learning a lot from!
The thing about GYNSYM, and I confess I am not the one to answer, is
that somehow both the lifetime of the symbol in the symbol table
(internment) and the ability to reference it are _wierd_.
And, I didn't realize it until your post pointed out the issues
surrounding representation! Thanks!
Here's wierd: this works as expected:
----
>(eval (let ((c (gensym))) `(progn (setq ,c 'test)(print ,c)(terpri))))
TEST
NIL
----
But this does not work as I expected:
----
>(progn (setq #:G1801 'test)(print #:G1801)(terpri))
Error in PROGN [or a callee]: The variable #:G1801 is unbound.
----
I know you can't read and intern a symbol like #:<name>, but somehow
it is done in the context of back-quote processing...
Anybody?
On Jun 1, 12:22 pm, ··············@excite.com wrote:
-see above-
Now that I think about it, the output of a macro is not text, it is a
parse tree, which then goes straight to the compiler. Same as in my
example, the `() form is never represented as text, it goes to the
EVAL as a parse tree.
For code that comes from the user, it goes through the reader to
become a parse tree, [then macro substitutions], then to the compiler.
So the macro can put in references to symbols, the names of which do
not have valid represetations in user code. I think that partitions
user symbols apart from GENSYM symbols, so that's why GENSYM symbols
used in macros cannot collide with user written code.
Basically...
On Jun 1, 11:45 am, ··············@excite.com wrote:
> On Jun 1, 12:22 pm, ··············@excite.com wrote:
> -see above-
>
> Now that I think about it, the output of a macro is not text, it is a
> parse tree, which then goes straight to the compiler. Same as in my
> example, the `() form is never represented as text, it goes to the
> EVAL as a parse tree.
>
> For code that comes from the user, it goes through the reader to
> become a parse tree, [then macro substitutions], then to the compiler.
>
> So the macro can put in references to symbols, the names of which do
> not have valid represetations in user code. I think that partitions
> user symbols apart from GENSYM symbols, so that's why GENSYM symbols
> used in macros cannot collide with user written code.
>
> Basically...
This is mostly correct; because #:G1 is not interned, when #:G1 is
read again the reader returns a different symbol. Macros work on the
list structure of the code so they can easily put the same symbol in
multiple locations, which does as one expects. Because GENSYM creates
and returns a fresh, uninterned symbol, the symbol will be different
than all of the existing symbols, and will never[1] be returned from
READ as long as it is not interned.
I'll note that you can fix your code from a previous post:
(progn (setq #1=#:G1801 'test) (print #1#) (terpri))
By using the syntax for circular structures, you can the same #:G1801
symbol appear in both locations, and it works as expected (this is
essentially what macros do).
[1]: Well, if you have a reference to the symbol you could return it
using read time evaluation, but this is a non-issue as read time
precedes macroexpansion time, so the symbol generated by the macro
doesn't exist when the macro call is read in...
On Jun 1, 1:04 pm, Brian - qbg <··············@gmail.com> wrote:
> I'll note that you can fix your code from a previous post:
> (progn (setq #1=#:G1801 'test) (print #1#) (terpri))
> By using the syntax for circular structures...
I'll note here that one should not ordinarily need a "syntax for
circular structures" to describe a parse *tree* (emphasis on the
"tree").
On 2009-06-01, Series Expansion <·······@gmail.com> wrote:
> On Jun 1, 1:04 pm, Brian - qbg <··············@gmail.com> wrote:
>> I'll note that you can fix your code from a previous post:
>> (progn (setq #1=#:G1801 'test) (print #1#) (terpri))
>> By using the syntax for circular structures...
>
> I'll note here that one should not ordinarily need a "syntax for
> circular structures" to describe a parse *tree* (emphasis on the
> "tree").
But the above structure above isn't circular. We use the syntax for circular
structures because this tool also also handles the simpler case of substructure
sharing, which is what is going on above. In this case we don't need
that notation to be powerful enough to handle cycles. Cycles are
expressed by the occurence of a label reference like #1# inside
the object which is introduced under that label, e.g.:
;; ``bottomless'' (1 1 1 1 1 ...) cyclic list:
#1=(1 . #1#)
No such backreference occurs above. The expresion simply introduces one object
with #1 and then refer to it later.
Syntax trees may actually be dags with shared substructure.
For instance, see the Red Dragon Book:
_Compilers: Principles, Techniques and Tools_, Aho, Sethi, Ullman.
1988, Section 5.2, ``Construction of Syntax Trees''.
I value this book as a credible authority on the subject of compilers.
The chapter of the text shows how the same syntax-directed definition can
drive the construction of either a tree or dag:
``A dag is obtained if the function constructing a node
first checks to see whether an identical node already
exists. [ ... ] When the call mkleaf(id, a) is repeated on
line 2, the node constructed by the previous call
to mlkeaf(id, a) is returned.''
What is described here is practically identical to interning in the Lisp
reader.
On Jun 1, 11:06 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-06-01, Series Expansion <·······@gmail.com> wrote:
> > I'll note here that one should not ordinarily need a "syntax for
> > circular structures" to describe a parse *tree* (emphasis on the
> > "tree").
>
> But the above structure above isn't circular.
It is, in that it contains undirected cycles. It doesn't contain
directed cycles. Regardless, it isn't a tree.
> Syntax trees may actually be dags with shared substructure.
Ordinarily that would be as an optimization, without affecting
semantics!
Series Expansion <·······@gmail.com> writes:
> On Jun 1, 1:04��pm, Brian - qbg <··············@gmail.com> wrote:
> > I'll note that you can fix your code from a previous post:
> > (progn (setq #1=#:G1801 'test) (print #1#) (terpri))
> > By using the syntax for circular structures...
>
> I'll note here that one should not ordinarily need a "syntax for
> circular structures" to describe a parse *tree* (emphasis on the
> "tree").
Well, so Lisp operates on parse GRAPHs and not parse TREEs. Seems like
that gives it more generality. Score one for lisp. The particular
example above is an example of a parse LATTICE, since it isn't
circular. It just has shared substructure.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> Series Expansion <·······@gmail.com> writes:
>
>> On Jun 1, 1:04�pm, Brian - qbg <··············@gmail.com> wrote:
>> > I'll note that you can fix your code from a previous post:
>> > (progn (setq #1=#:G1801 'test) (print #1#) (terpri))
>> > By using the syntax for circular structures...
>>
>> I'll note here that one should not ordinarily need a "syntax for
>> circular structures" to describe a parse *tree* (emphasis on the
>> "tree").
>
> Well, so Lisp operates on parse GRAPHs and not parse TREEs. Seems like
> that gives it more generality. Score one for lisp. The particular
> example above is an example of a parse LATTICE, since it isn't
> circular. It just has shared substructure.
It's possible to evaluate or compile DAGs.
In some cases, it's even possible to evaluate or compile graphs with
cycle, but it's actually undefined what may happen in presence of
cycles.
--
__Pascal Bourguignon__
On Jun 2, 2:54 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> It's possible to evaluate or compile DAGs.
Irrelevant. By definition, source code is text and a parse tree is a
tree.
> In some cases, it's even possible to evaluate or compile graphs with
> cycle, but it's actually undefined what may happen in presence of
> cycles.
Most illogical.
On 2009-07-12 20:12:20 +0100, Series Expansion <·······@gmail.com> said:
> Irrelevant. By definition, source code is text and a parse tree is a
> tree.
Yes. However what the lisp reader produces is not a tree, it's a
general graph.
On Jul 12, 5:33 pm, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-12 20:12:20 +0100, Series Expansion <·······@gmail.com> said:
> > Irrelevant. By definition, source code is text and a parse tree is a
> > tree.
>
> Yes.
You agree? Then why are you still arguing?
In article
<····································@k20g2000vbp.googlegroups.com>,
Series Expansion <·······@gmail.com> wrote:
> On Jun 2, 2:54�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> > It's possible to evaluate or compile DAGs.
>
> Irrelevant. By definition, source code is text and a parse tree is a
> tree.
I'm coming into this a little late so I could be missing some context
(in which case I apologize for butting in), but I think it's important
to note that CL is unique among programming languages in that CL
programs are specifically *not* text, they are forms. Forms can be
produced by processing text through the reader, but they can also be
produced in other ways. So in CL, source code is not necessarily text.
rg
On Jul 13, 2:44 am, Ron Garret <·········@flownet.com> wrote:
> In article
> <····································@k20g2000vbp.googlegroups.com>,
> Series Expansion <·······@gmail.com> wrote:
> > On Jun 2, 2:54 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> > > It's possible to evaluate or compile DAGs.
>
> > Irrelevant. By definition, source code is text and a parse tree is a
> > tree.
>
> I'm coming into this a little late so I could be missing some context
> (in which case I apologize for butting in), but I think it's important
> to note that CL is unique among programming languages in that CL
> programs are specifically *not* text, they are forms. Forms can be
> produced by processing text through the reader, but they can also be
> produced in other ways. So in CL, source code is not necessarily text.
It is still text. It becomes a parse tree. Much as in other languages.
Unlike in other languages, this tree is accessible to user code, but
that cannot gift it with magical powers impossible to normal trees
(say, a magical ability to contain undirected cycles).
In article
<····································@r34g2000vba.googlegroups.com>,
Series Expansion <·······@gmail.com> wrote:
> On Jul 13, 2:44�am, Ron Garret <·········@flownet.com> wrote:
> > In article
> > <····································@k20g2000vbp.googlegroups.com>,
> > �Series Expansion <·······@gmail.com> wrote:
> > > On Jun 2, 2:54�pm, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > > > It's possible to evaluate or compile DAGs.
> >
> > > Irrelevant. By definition, source code is text and a parse tree is a
> > > tree.
> >
> > I'm coming into this a little late so I could be missing some context
> > (in which case I apologize for butting in), but I think it's important
> > to note that CL is unique among programming languages in that CL
> > programs are specifically *not* text, they are forms. �Forms can be
> > produced by processing text through the reader, but they can also be
> > produced in other ways. �So in CL, source code is not necessarily text.
>
> It is still text. It becomes a parse tree.
Not necessarily. It is *usually* text, but it need not be. For
example, it is in principle possible to create Lisp programs graphically.
> Much as in other languages.
Much as. But not exactly as.
> Unlike in other languages, this tree is accessible to user code,
It's not just *accessible*, it's *producible* by user code *ab initio*.
> but
> that cannot gift it with magical powers impossible to normal trees
> (say, a magical ability to contain undirected cycles).
I don't know about "magical", but it's pretty frickin' cool.
rg
On Jul 13, 12:22 pm, Ron Garret <·········@flownet.com> wrote:
> In article
> <····································@r34g2000vba.googlegroups.com>,
> Series Expansion <·······@gmail.com> wrote:
> > On Jul 13, 2:44 am, Ron Garret <·········@flownet.com> wrote:
> > > In article
> > > <····································@k20g2000vbp.googlegroups.com>,
> > > Series Expansion <·······@gmail.com> wrote:
> > > > On Jun 2, 2:54 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > > > wrote:
> > > > > It's possible to evaluate or compile DAGs.
>
> > > > Irrelevant. By definition, source code is text and a parse tree is a
> > > > tree.
>
> > > I'm coming into this a little late so I could be missing some context
> > > (in which case I apologize for butting in), but I think it's important
> > > to note that CL is unique among programming languages in that CL
> > > programs are specifically *not* text, they are forms. Forms can be
> > > produced by processing text through the reader, but they can also be
> > > produced in other ways. So in CL, source code is not necessarily text.
>
> > It is still text. It becomes a parse tree.
>
> No
Yes.
> > Much as in other languages.
>
> Much as.
Much as.
> > Unlike in other languages, this tree is accessible to user code,
>
> It's not just *accessible*, it's *producible*
That's part of accessibility.
> > but that cannot gift it with magical powers impossible to normal
> > trees (say, a magical ability to contain undirected cycles).
>
> I don't know about "magical", but it's pretty frickin' cool.
So you say. But "cool" doesn't add those bignums or put food on the
table, as a rule.
On 2009-07-13 15:43:36 +0100, Series Expansion <·······@gmail.com> said:
> It is still text. It becomes a parse tree.
It becomes a form...
> Much as in other languages.
> Unlike in other languages, this tree is accessible to user code, but
> that cannot gift it with magical powers impossible to normal trees
> (say, a magical ability to contain undirected cycles).
... which is not a tree but a general directed graph which may contain cycles.
On Jul 13, 3:31 pm, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-13 15:43:36 +0100, Series Expansion <·······@gmail.com> said:
>
> > It is still text. It becomes a parse tree.
>
> It becomes a form...
The Lispy term for a parse tree.
> > Much as in other languages.
> > Unlike in other languages, this tree is accessible to user code, but
> > that cannot gift it with magical powers impossible to normal trees
> > (say, a magical ability to contain undirected cycles).
>
> [calls me a liar]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim.
On 2009-07-13 22:14:46 +0100, Series Expansion <·······@gmail.com> said:
> The Lispy term for a parse tree.
So, since a form is a tree, clearly the following predicate could never
return true for any form:
(defun own-car-p (x)
(and (consp x)
(eq (car x) x)))
Because such a form could never exist, right?
? (defvar *x* '#1=(#1# . #1#)
*x*
? (own-car-p *x*_
t
So, not a tree then.
On Jun 2, 12:59 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On Jun 1, 1:04Ž pm, Brian - qbg <··············@gmail.com> wrote:
> > > I'll note that you can fix your code from a previous post:
> > > (progn (setq #1=#:G1801 'test) (print #1#) (terpri))
> > > By using the syntax for circular structures...
>
> > I'll note here that one should not ordinarily need a "syntax for
> > circular structures" to describe a parse *tree* (emphasis on the
> > "tree").
>
> Well, so Lisp operates on parse GRAPHs and not parse TREEs.
If true, that is extremely odd.
Please stop silently redirecting followups.
On Jun 1, 12:45 pm, ··············@excite.com wrote:
> On Jun 1, 12:22 pm, ··············@excite.com wrote:
> -see above-
>
> Now that I think about it, the output of a macro is not text, it is a
> parse tree, which then goes straight to the compiler. Same as in my
> example, the `() form is never represented as text, it goes to the
> EVAL as a parse tree.
>
> For code that comes from the user, it goes through the reader to
> become a parse tree, [then macro substitutions], then to the compiler.
>
> So the macro can put in references to symbols, the names of which do
> not have valid represetations in user code. I think that partitions
> user symbols apart from GENSYM symbols, so that's why GENSYM symbols
> used in macros cannot collide with user written code.
It can only work, though, if the parse "tree" is a directed acyclic
graph with an undirected cycle (e.g. (let (foo (gensym)) (x foo))
becomes a node with edges eventually to the (foo (gensym)) and the (x
foo) nodes, both of which have nodes to the SAME foo node, rather than
distinct-but-equal-as-strings nodes).
To get the effects the Lispers have claimed seems to require seriously
contorting the definitions of all of:
* macro (not operating on text?!)
* parse tree (contains undirected cycles?!)
* source code (not flat ASCII?!)
and possibly more.
On Jun 1, 6:06 pm, Series Expansion <·······@gmail.com> wrote:
> To get the effects the Lispers have claimed seems to require seriously
> contorting the definitions of all of:
> * macro (not operating on text?!)
> * parse tree (contains undirected cycles?!)
> * source code (not flat ASCII?!)
> and possibly more.
YES - the first one - that's the reason Lispers like the Lisp macro,
you got it exactly! Does _not_ operate on text, operates after lex
+parse phase! If you are simply trying to argue that a Lisp macro is
not what is usually called a macro - I agree with that! - then call
them L-macros.
So to get the similar benefit for C (or Pascal or whatever) type of
syntax, you'd add a new feature (maybe "C-macro" ??), not the same as
a macro pre-processor, but something that fits between the lexer
+parser and the code gen. And the C-macro usages that programmers
write would have to pass through the lexer+parser!
Try that with a new control flow structure C-macro, for instance. It
can be done, and I think some research groups are actually doing it.
But it's harder in non-Lisp like languages. In Lisp, the original
parsing system can already read "L-macro" usages.
On Jun 24, 1:51 pm, fortunatus <··············@excite.com> wrote:
> On Jun 1, 6:06 pm, Series Expansion <·······@gmail.com> wrote:
> > To get the effects the Lispers have claimed seems to require seriously
> > contorting the definitions of all of:
> > * macro (not operating on text?!)
> > * parse tree (contains undirected cycles?!)
> > * source code (not flat ASCII?!)
> > and possibly more.
>
> YES - the first one - that's the reason Lispers like the Lisp macro,
because it isn't one? How ridiculous. Redefining things and then
acting all shocked and flamey when people call you on it. Really now.
Series Expansion <·······@gmail.com> writes:
> On Jun 24, 1:51�pm, fortunatus <··············@excite.com> wrote:
> > YES - the first one - that's the reason Lispers like the Lisp macro,
>
> because it isn't one? How ridiculous. Redefining things and then
> acting all shocked and flamey when people call you on it. Really now.
Lisp has been calling them "macros" since they were originally proposed in
1963. In 45 years, nobody has ever objected that Lisp wasn't entitled to
use the word. In fact, the Free On-line Dictionary of Computing's
definition of the word "macro" notes:
"Nowadays the term is most often used in connection with the C
preprocessor, Lisp, or one of several special-purpose languages built
around a macro-expansion facility (such as TeX or Unix's troff suite)."
Another example: the Wikipedia article on the computer science meaning of
the word macro includes a (not very good) section titled "Lisp macros".
Looks to me like Lisp has a pretty good claim on the word at this point.
So when you came in here, people warned you multiple times that: "Lisp
macros aren't like the macros you are used to." But you weren't interested
in learning anything new, you were here to pick a fight and prove what a
bunch of wankers we are. Now that you've lost that argument, here you are
again whining that nobody told you that these weren't the macros you were
used to! Pathetic.
On 25 Jun 2009 00:40:17 -0400, Alan Bawden <····@shaggy.csail.mit.edu> said:
> Lisp has been calling them "macros" since they were originally proposed in
> 1963.
Which, by the way, is just four years after the time when the term
itself originated according to Merriam-Webster [*]. I notice that
the latter's definition is closer to Lisp macros than to cpp macros,
as it is only in for-evaluation positions that Lisp macros are
expanded by the language processor (whether compiler or
interpreter).
[*] <http://www.merriam-webster.com/dictionary/macro%5B2%5D>
---Vassil.
--
Vassil Nikolov <········@pobox.com>
(1) M(Gauss);
(2) M(a) if M(b) and declared(b, M(a)),
where M(x) := "x is a mathematician".
On Jun 25, 1:59 am, Vassil Nikolov <········@pobox.com> wrote:
> On 25 Jun 2009 00:40:17 -0400, Alan Bawden <····@shaggy.csail.mit.edu> said:
>
> > Lisp has been calling them "macros" since they were originally proposed in
> > 1963.
>
> Which, by the way, is just four years after the time when the term
> itself originated according to Merriam-Webster [*].
Irrelevant.
> I notice that the latter's definition is closer to Lisp macros than to
> cpp macros
Irrational.
> as it is only in for-evaluation positions that Lisp macros are
> expanded by the language processor (whether compiler or
> interpreter).
Illogical. That is not sufficient to make macros non-troublesome, so
it is not a salient difference with respect to this debate.
On Jun 25, 12:40 am, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On Jun 24, 1:51 pm, fortunatus <··············@excite.com> wrote:
> > > YES - the first one - that's the reason Lispers like the Lisp macro,
>
> > because it isn't one? How ridiculous. Redefining things and then
> > acting all shocked and flamey when people call you on it. Really now.
>
> Lisp has been calling them "macros" since they were originally proposed in
> 1963. [rest of irrelevant digression deleted]
>
> But you weren't interested in learning anything new
Not true.
> you were here to pick a fight and prove what a bunch of wankers we
> are.
Not true, but several of you *did* do a pretty nice job of proving
what a bunch of wankers they were.
> Now that you've lost that argument
I have not.
> here you are again whining
I am not.
> ... Pathetic.
I am not.
On 2009-06-30 03:02:12 +0100, Alan Bawden <····@shaggy.csail.mit.edu> said:
> This is not even effective trolling any more. Mr. Expansion is now flying
> randomly around the room like a rapidly deflating balloon. He'll
> eventually come to rest behind the sofa, where we'll find him when cleaning
> house next fall. "What the heck is this?", someone will say, holding up
> the scrap of limp shriveled rubber he has become. "Oh", someone else will
> answer, "that's what's left of Series Expansion. He wasn't fun for very
> long. Just throw it out."
I find this kind of article really grossly unacceptable. I am sure I
am not alone in now requiring a new keyboard as my current one is now
full of coffee. Much worse, some people may have been typing while
reading and may now have scalded their hands. It is only through long
experience of this kind of behaviour on the part of certain people that
I know always to wear my asbestos-lined gloves while reading news.
Usually, of course I also wrap my laptop in cellophane.
Please refrain from this in future. I will be invoicing you for the
keyboard by return.
Tim Bradshaw wrote:
> On 2009-06-30 03:02:12 +0100, Alan Bawden <····@shaggy.csail.mit.edu> said:
>
>> This is not even effective trolling any more. Mr. Expansion is now
>> flying
>> randomly around the room like a rapidly deflating balloon. He'll
>> eventually come to rest behind the sofa, where we'll find him when
>> cleaning
>> house next fall. "What the heck is this?", someone will say, holding up
>> the scrap of limp shriveled rubber he has become. "Oh", someone else
>> will
>> answer, "that's what's left of Series Expansion. He wasn't fun for very
>> long. Just throw it out."
>
> I find this kind of article really grossly unacceptable. I am sure I am
> not alone in now requiring a new keyboard as my current one is now full
> of coffee. Much worse, some people may have been typing while reading...
Really? I presume you are not referring to my hunt and peck typing
skills or you would have said reading while typing the former following
the latter for hunt and peckers. My presumption thus proved, we are left
with people writing while reading and I am concerned this suggests one
can talk while listening, the hard part there being listening in so much
as few people are capable of listening. Where was I?
hth, kt
ps. It took you dweebs this long to suss Expansion's uselessness? Our
skills are fading. k
On 2009-06-30 21:43:06 +0100, Kenneth Tilton <·········@gmail.com> said:
> ps. It took you dweebs this long to suss Expansion's uselessness? Our
> skills are fading. k
It's true. In the golden age of CLL he would have been a gibbering
wreck in some asylum by now. (But, may be, he is, who could tell?)
On Jun 30, 4:54 pm, Tim Bradshaw <····@tfeb.org> wrote:
> On 2009-06-30 21:43:06 +0100, Kenneth Tilton <·········@gmail.com> said:
>
> > ps. It took you dweebs this long to suss Expansion's uselessness? Our
> > skills are fading. k
>
> It's true. In the golden age of CLL he would have been a gibbering
> wreck in some asylum by now.
Is that a threat?
Regardless, I am not useless.
> (But, may be, he is, who could tell?)
Nor am I crazy.
On Jul 4, 2:53 am, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
>
> > Is that a threat?
>
> [calls me a liar]
How ridiculous of you.
On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
>>
>>> Is that a threat?
>>
>> [calls me a liar]
>
> How ridiculous of you.
Actually, the text you replaced above with "[calls me a liar]" was
"No, it's an elegy".
Tim Bradshaw wrote:
> On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
>
>>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
>>>
>>>> Is that a threat?
>>>
>>> [calls me a liar]
>>
>> How ridiculous of you.
>
> [falsely accuses me]
>
You will be hearing from my attorneys.
kenny
On Jul 11, 6:05 am, Kenneth Tilton <·········@gmail.com> wrote:
> Tim Bradshaw wrote:
> > On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
> >>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
> >>>> Is that a threat?
> >>> [calls me a liar]
> >> How ridiculous of you.
> [misquotes me]
> You will be hearing from my attorneys.
About what? You're the one that just misquoted me.
Series Expansion wrote:
> On Jul 11, 6:05 am, Kenneth Tilton <·········@gmail.com> wrote:
>> Tim Bradshaw wrote:
>>> On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
>>>>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
>>>>>> Is that a threat?
>>>>> [calls me a liar]
>>>> How ridiculous of you.
>> [misquotes me]
>> You will be hearing from my attorneys.
>
> About what? You're the one that just misquoted me.
Do I win?
kt
On Jul 11, 10:32 am, Kenneth Tilton <·········@gmail.com> wrote:
> Series Expansion wrote:
> > On Jul 11, 6:05 am, Kenneth Tilton <·········@gmail.com> wrote:
> >> Tim Bradshaw wrote:
> >>> On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
> >>>>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
> >>>>>> Is that a threat?
> >>>>> [calls me a liar]
> >>>> How ridiculous of you.
> >> [misquotes me]
> >> You will be hearing from my attorneys.
>
> > About what? You're the one that just misquoted me.
>
> Do I win?
Yep -- the Non-Sequitur of the Month Award. Congratulations.
On Jul 11, 5:00 am, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
> >> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
> >>> Is that a threat?
> >> [calls me a liar]
> > How ridiculous of you.
>
> Actually, the text you replaced above with "[calls me a liar]" was
> "No, ...".
Exactly.
Tim Bradshaw wrote:
> On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
>>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
>>>
>>>> Is that a threat?
>>>
>>> [calls me a liar]
>>
>> How ridiculous of you.
>
> Actually, the text you replaced above with "[calls me a liar]" was "No,
> it's an elegy".
I would assume that it was a parody.
Arne
On Sat, 11 Jul 2009 14:15:21 -0400, Arne Vajh�j <····@vajhoej.dk> said:
> Tim Bradshaw wrote:
>> On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
>>>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
>>>>
>>>>> Is that a threat?
>>>>
>>>> [calls me a liar]
>>>
>>> How ridiculous of you.
>>
>> Actually, the text you replaced above with "[calls me a liar]" was
>> "No, it's an elegy".
> I would assume that it was a parody.
Somewhere on the lyrical-tragic-comic line anyway...
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
On Jul 11, 2:15 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Tim Bradshaw wrote:
> > On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
> >>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
>
> >>>> Is that a threat?
>
> >>> [calls me a liar]
>
> >> How ridiculous of you.
>
> > Actually, the text you replaced above with "[calls me a liar]" was "No,
> > it's an elegy".
>
> I would assume that it was a parody.
Then you would be wrong.
Series Expansion wrote:
> On Jul 11, 2:15 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>> Tim Bradshaw wrote:
>>> On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
>>>>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
>>>>>> Is that a threat?
>>>>> [calls me a liar]
>>>> How ridiculous of you.
>>> Actually, the text you replaced above with "[calls me a liar]" was "No,
>>> it's an elegy".
>> I would assume that it was a parody.
>
> Then you would be wrong.
Are you Kenneth Tilton?
If not then how would know that it was not a parody?
Arne
On Jul 12, 10:02 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On Jul 11, 2:15 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Tim Bradshaw wrote:
> >>> On 2009-07-11 04:01:32 +0100, Series Expansion <·······@gmail.com> said:
> >>>>> On 2009-07-03 20:45:43 +0100, Series Expansion <·······@gmail.com> said:
> >>>>>> Is that a threat?
> >>>>> [calls me a liar]
> >>>> How ridiculous of you.
> >>> Actually, the text you replaced above with "[calls me a liar]" was "No,
> >>> it's an elegy".
> >> I would assume that it was a parody.
> > Then you would be wrong.
>
> Are you Kenneth Tilton?
>
> If not then how would know that it was not a parody?
Simple. When I said "[calls me a liar]", I was not intending it as a
parody. Thus I know it was not a parody.
On Jun 30, 4:43 pm, Kenneth Tilton <·········@gmail.com> wrote:
> Tim Bradshaw wrote:
> > On 2009-06-30 03:02:12 +0100, Alan Bawden <····@shaggy.csail.mit.edu> said:
> >> This is not even effective trolling any more. Mr. Expansion is now
> >> flying
> >> randomly around the room like a rapidly deflating balloon. He'll
> >> eventually come to rest behind the sofa, where we'll find him when
> >> cleaning
> >> house next fall. "What the heck is this?", someone will say, holding up
> >> the scrap of limp shriveled rubber he has become. "Oh", someone else
> >> will
> >> answer, "that's what's left of Series Expansion. He wasn't fun for very
> >> long. Just throw it out."
>
> > I find this kind of article really grossly unacceptable.
>
> Really?
Yes, Alan was indeed high on something when he wrote that. And the
White Album it isn't.
> ps. It took you dweebs this long to suss Expansion's uselessness?
I am not useless, so it's hardly surprising that people don't quickly
jump to the conclusion that I am.
Series Expansion wrote:
> On Jun 30, 4:43 pm, Kenneth Tilton <·········@gmail.com> wrote:
>> ps. It took you dweebs this long to suss Expansion's uselessness?
>
> I am not useless, so it's hardly surprising that people don't quickly
> jump to the conclusion that I am.
But it seems that people do !
Arne
On Jul 11, 8:20 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On Jun 30, 4:43 pm, Kenneth Tilton <·········@gmail.com> wrote:
> >> ps. It took you dweebs this long to suss Expansion's uselessness?
>
> > I am not useless, so it's hardly surprising that people don't quickly
> > jump to the conclusion that I am.
>
> But it seems that people do !
A few people do. Idiots, mostly.
Series Expansion wrote:
> On Jul 11, 8:20 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>> Series Expansion wrote:
>>> On Jun 30, 4:43 pm, Kenneth Tilton <·········@gmail.com> wrote:
>>>> ps. It took you dweebs this long to suss Expansion's uselessness?
>>> I am not useless, so it's hardly surprising that people don't quickly
>>> jump to the conclusion that I am.
>> But it seems that people do !
>
> A few people do. Idiots, mostly.
Hm.
My impression is that so far *all* people have.
Arne
On Jul 12, 10:03 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On Jul 11, 8:20 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Series Expansion wrote:
> >>> On Jun 30, 4:43 pm, Kenneth Tilton <·········@gmail.com> wrote:
> >>>> ps. It took you dweebs this long to suss Expansion's uselessness?
> >>> I am not useless, so it's hardly surprising that people don't quickly
> >>> jump to the conclusion that I am.
> >> But it seems that people do !
>
> > A few people do. Idiots, mostly.
>
> My impression is that so far *all* people have.
People have all kinds of impressions that don't necessarily correlate
all that strongly with reality. Particularly not when they, like you,
are idiots.
On Jun 30, 2:48 pm, Tim Bradshaw <····@tfeb.org> wrote:
> On 2009-06-30 03:02:12 +0100, Alan Bawden <····@shaggy.csail.mit.edu> said:
>
> > This is not even effective trolling any more. Mr. Expansion is now flying
> > randomly around the room like a rapidly deflating balloon. He'll
> > eventually come to rest behind the sofa, where we'll find him when cleaning
> > house next fall. "What the heck is this?", someone will say, holding up
> > the scrap of limp shriveled rubber he has become. "Oh", someone else will
> > answer, "that's what's left of Series Expansion. He wasn't fun for very
> > long. Just throw it out."
>
> I find this kind of article really grossly unacceptable.
Yes -- it is sad when people post while stoned. He'll be embarrassed
by it later. I am mystified that people frequently seek to impair
their reasoning, judgment, and decision-making faculties by
intentionally inebriating themselves with ethanol and psychotropic
drugs, even after having embarrassing photos turn up on Facebook, or
videos on YouTube, after a previous bender.
On Jun 29, 10:02 pm, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On Jun 25, 12:40 am, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
> > > Series Expansion <·······@gmail.com> writes:
> > > > On Jun 24, 1:51 pm, fortunatus <··············@excite.com> wrote:
> > > > > YES - the first one - that's the reason Lispers like the Lisp macro,
>
> > > > because it isn't one? How ridiculous. Redefining things and then
> > > > acting all shocked and flamey when people call you on it. Really now.
>
> > > Lisp has been calling them "macros" since they were originally proposed in
> > > 1963. [rest of irrelevant digression deleted]
>
> [calls me a liar]
No, you're the liar.
> > > Now that you've lost that argument
>
> > I have not.
>
> > > here you are again whining
>
> > I am not.
>
> > > ... Pathetic.
>
> > I am not.
>
> This is not even effective trolling any more.
Of course not, because IT NEVER WAS.
> Mr. Expansion is now flying randomly around the room like a rapidly
> deflating balloon. He'll eventually come to rest behind the sofa, where
> we'll find him when cleaning house next fall.
I recommend that you consult a physician. I suspect you may have
picked some bad mushrooms.
> "What the heck is this?", someone will say, holding up
> the scrap of limp shriveled rubber he has become. "Oh", someone else will
> answer, "that's what's left of Series Expansion. He wasn't fun for very
> long. Just throw it out."
This suggests a callous disregard for your fellow human beings. I
recommend you seek counseling.
On Jun 24, 9:34 pm, Series Expansion <·······@gmail.com> wrote:
> because it isn't one? How ridiculous. Redefining things and then
> acting all shocked and flamey when people call you on it. Really now.
It isn't a text preprocessing macro - yeah, you're right, the
definition is different.
Who cares that Lispers call it "macro"? As long as you can figure out
the meaning of the term in context you can join the discussion! (I
admit, though, that the difference does trip up newbies - me included,
took me a few months. It's something to learn about Lisp.)
By the way - If you could name it, Series Expansion, what would you
call it?
On Jun 25, 12:10 pm, fortunatus <··············@excite.com> wrote:
> On Jun 24, 9:34 pm, Series Expansion <·······@gmail.com> wrote:
>
> > because it isn't one? How ridiculous. Redefining things and then
> > acting all shocked and flamey when people call you on it. Really now.
>
> If you could name it, Series Expansion, what would you
> call it?
A "wackyfuckedupLispthing" perhaps.
On Jun 24, 9:34 pm, Series Expansion <·······@gmail.com> wrote:
> On Jun 24, 1:51 pm, fortunatus <··············@excite.com> wrote:
>
> > On Jun 1, 6:06 pm, Series Expansion <·······@gmail.com> wrote:
> > > To get the effects the Lispers have claimed seems to require seriously
> > > contorting the definitions of all of:
> > > * macro (not operating on text?!)
> > > * parse tree (contains undirected cycles?!)
> > > * source code (not flat ASCII?!)
> > > and possibly more.
>
> > YES - the first one - that's the reason Lispers like the Lisp macro,
>
> because it isn't one? How ridiculous. Redefining things and then
> acting all shocked and flamey when people call you on it. Really now.
I'm pretty sure lisp macros predate C macros.
Same would be true for the parse tree and source code.
(As lisp is older than c).
But anyway, maybe it would be less confusing if we called them
'compile time source-code manipulating functions'.
'Cotscmafu'.
'Macro' has had an too much of an association with excel spreadsheets
and cheating at MMOs to be really sexy anymore.
Food for thought. (maybe?)
On Jun 26, 9:48 am, ACL <··················@gmail.com> wrote:
> On Jun 24, 9:34 pm, Series Expansion <·······@gmail.com> wrote:
> > On Jun 24, 1:51 pm, fortunatus <··············@excite.com> wrote:
> > > On Jun 1, 6:06 pm, Series Expansion <·······@gmail.com> wrote:
> > > > To get the effects the Lispers have claimed seems to require seriously
> > > > contorting the definitions of all of:
> > > > * macro (not operating on text?!)
> > > > * parse tree (contains undirected cycles?!)
> > > > * source code (not flat ASCII?!)
> > > > and possibly more.
>
> > > YES - the first one - that's the reason Lispers like the Lisp macro,
>
> > because it isn't one? How ridiculous. Redefining things and then
> > acting all shocked and flamey when people call you on it. Really now.
>
> I'm pretty sure lisp macros predate C macros. [other irrelevancies
> deleted]
>
> But anyway, maybe it would be less confusing if we called them
> 'compile time source-code manipulating functions'.
>
> 'Cotscmafu'.
>
> 'Macro' has had an too much of an association with excel spreadsheets
> and cheating at MMOs to be really sexy anymore.
Cotscmafu it is. I particularly like how it ends with "fu".
On 2009-06-26 14:48:47 +0100, ACL <··················@gmail.com> said:
> I'm pretty sure lisp macros predate C macros.
> Same would be true for the parse tree and source code.
> (As lisp is older than c).
Yes, they do, by many years.
> But anyway, maybe it would be less confusing if we called them
> 'compile time source-code manipulating functions'.
"macro" is a fine name.
On Jun 26, 6:06 pm, Tim Bradshaw <····@tfeb.org> wrote:
> On 2009-06-26 14:48:47 +0100, ACL <··················@gmail.com> said:
>
> > I'm pretty sure lisp macros predate C macros.
> > Same would be true for the parse tree and source code.
> > (As lisp is older than c).
>
> Yes, they do, by many years.
You sure about that? I thought that both C-ish macros and the Lisp
MACRO mechanism came about around 1970 or so. And in any case, the
term is clearly making reference to assembler macro-instructions,
which are much more like C macros than Lisp ones.
> > But anyway, maybe it would be less confusing if we called them
> > 'compile time source-code manipulating functions'.
>
> "macro" is a fine name.
Indeed. And when I have the need to contrast the two styles of macros,
the adjectives "textual" and "structural" work fine.
On Jun 26, 2:49 pm, "Thomas F. Burdick" <········@gmail.com> wrote:
> On Jun 26, 6:06 pm, Tim Bradshaw <····@tfeb.org> wrote:
> > "macro" is a fine name.
>
> Indeed. And when I have the need to contrast the two styles of macros,
> the adjectives "textual" and "structural" work fine.
Structural, schmuctural. It's apparently a macro in much the way a
3.5" floppy disk is floppy.
On 2009-06-26 19:49:35 +0100, "Thomas F. Burdick" <········@gmail.com> said:
> You sure about that? I thought that both C-ish macros and the Lisp
> MACRO mechanism came about around 1970 or so.
The earliest reference I am aware of to Lisp macros is AIM-5, which
describes macros for Lisp 1.5 in 1963. The Lisp 1.5 manual does not
mention macros. So I'm guessing a date some time in 1963, or possibly a
little earlier.
Tim Bradshaw wrote:
> On 2009-06-26 19:49:35 +0100, "Thomas F. Burdick" <········@gmail.com>
> said:
>
>> You sure about that? I thought that both C-ish macros and the Lisp
>> MACRO mechanism came about around 1970 or so.
>
> The earliest reference I am aware of to Lisp macros is AIM-5, which
> describes macros for Lisp 1.5 in 1963. The Lisp 1.5 manual does not
> mention macros. So I'm guessing a date some time in 1963, or possibly a
> little earlier.
>
The Software Preservation Group web page for Lisp history,
http://www.softwarepreservation.org/projects/LISP/ has a link to an
October 22, 1963 paper "MACRO Definition for LISP" by Timothy P. Hart,
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-057.pdf
I don't know enough about Lisp to evaluate whether what it describes is
the foundation of the current Lisp feature. Perhaps someone with the
necessary knowledge could take a look at it?
Patricia
On 2009-06-26, Patricia Shanahan <····@acm.org> wrote:
> Tim Bradshaw wrote:
>> On 2009-06-26 19:49:35 +0100, "Thomas F. Burdick" <········@gmail.com>
>> said:
>>
>>> You sure about that? I thought that both C-ish macros and the Lisp
>>> MACRO mechanism came about around 1970 or so.
>>
>> The earliest reference I am aware of to Lisp macros is AIM-5, which
>> describes macros for Lisp 1.5 in 1963. The Lisp 1.5 manual does not
>> mention macros. So I'm guessing a date some time in 1963, or possibly a
>> little earlier.
>>
>
>
> The Software Preservation Group web page for Lisp history,
> http://www.softwarepreservation.org/projects/LISP/ has a link to an
> October 22, 1963 paper "MACRO Definition for LISP" by Timothy P. Hart,
> ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-057.pdf
>
> I don't know enough about Lisp to evaluate whether what it describes is
> the foundation of the current Lisp feature. Perhaps someone with the
> necessary knowledge could take a look at it?
It positively, definitely describes the foundations of macros.
At the outset, an example is given for replacing an existing fexpr called
csetq by a macro.
Also, the macro STASH is defined which does almost exactly what PUSH does
today, with the same argument order:
(stash form x) ;; push value of FORM onto variable X.
expands to
(setq x (cons form x))
The modern PUSH can push onto any storage location, not only a named
variable.
The SETQ expansion is achieved by means of
MACRO ((STASH (LAMBDA (FORM)
(LIST (QUOTE SETQ)
(CADAR FORM)
(LIST (CONS (CADR FORM)
(CADAR FORM)))))))
(Indentation mine).
This is in an old-style ``eval quote'' notation in which the outer parentheses
were omitted from the toplevel form. But basically the macro would work
today, with only a minor code update.
Modern Lisp macros no longer just receive the entire macro call form as their
one and only argument, but the underlying plumbing still works that way, and
access to the whole form is still available using the &WHOLE keyword in the
macro lambda list. We don't have to use a lambda expression to define the
function, either.
So reusing the macro code in Common Lisp looks like this:
(DEFMACRO STASH (&WHOLE FORM VALUE PLACE)
(LIST (QUOTE SETQ)
(CADAR FORM)
(LIST (CONS (CADR FORM)
(CADAR FORM)))))
But now I see two bugs here. Firstly, it expects the form to have a weird shape!
Namely this:
((STASH PLACE) VALUE)
^CADAR ^CADR
Rather than
(STASH VALUE PLACE)
^CADR ^CADDR
I.e. unless this was really the representation, the paper possibly has a typo:
CADAR instead of CADDR.
Secondly, the macro is generating code, which means that certain symbols must
be quoted. But note that the CONS function is just called! That's wrong; we
need to /generate/ the code (CONS ...) not to invoke CONS at macro-expansion
time. I.e. we want
(LIST (QUOTE CONS) ...)
not:
(LIST (CONS ...))
Exactly the way the SETQ operator is quoted with (QUOTE SETQ),
the CONS operator must be quoted too.
Clearly, the paper's author didn't cut and paste his own code from
the text editor into the Lisp window of his graphics worksation
to try it out. :) :) :)
Bugfixed version:
(DEFMACRO STASH (&WHOLE FORM VALUE PLACE)
(LIST (QUOTE SETQ)
(CADDR FORM)
(LIST (QUOTE CONS)
(CADR FORM)
(CADDR FORM)))))
And now, actual test run in a Lisp session:
[1]>
(DEFMACRO STASH (&WHOLE FORM VALUE PLACE)
(LIST (QUOTE SETQ)
(CADDR FORM)
(LIST (QUOTE CONS)
(CADR FORM)
(CADDR FORM)))))
STASH
[2]> (macroexpand '(stash value place))
(SETQ PLACE (CONS VALUE PLACE)) ;
T
Our macro also has error checking. Though we don't use the VALUE and PLACE
arguments, the DEFMACRO still knows that the macro must take exactly two:
[3]> (macroexpand '(stash value place 42))
*** - The macro STASH may not be called with 3 arguments:
(STASH VALUE PLACE 42)
This error checking is absent from the 1963 version, and would have required
extra code. The 1963 STASH would simply have pulled the value and place forms
out, and ignored the superfluous 42.
The ``modern'' version (actually 1970's or 1980's modern) of the macro would
use the automatic form destructuring features of DEFMACRO, whereby the macro
lambda list (argument list to the DEFMACRO) constitutes a tree pattern
with variables, which is unified (one way) against the shape of the macro call.
Furthermore, we would use the backquote syntax to express the code generation
rather than a mess of list, quote and hard to understand ``cadavers'' like
CADAR:
(defmacro stash (value variable)
`(setq ,variable (cons ,value ,variable)))
That's it! The backquote may generate code similar to the 1963 stuff.
(Exactly how backquote works is implementation-specific). On the Lisp
implementation I'm using, the backtick is transliterated to a macro syntax,
which is then expanded, and so you can do the same thing:
[6]> (macroexpand '`(setq ,variable (cons ,value ,variable)))
(LIST 'SETQ VARIABLE (LIST 'CONS VALUE VARIABLE)) ;
T
Of course 'SETQ is a shorthand for (QUOTE SETQ), which is another
convenience not found in the original code. If we expand this notation,
we get:
(LIST (QUOTE SETQ) VARIABLE (LIST (QUOTE CONS) VALUE VARIABLE)) ;
Now, replace VALUE and VARIABLE with the expressions that compute their values,
namely (CADDR FORM) and (CADR FORM), and you get the 1963-ish code. :)
Kaz Kylheku <········@gmail.com> writes:
> On 2009-06-26, Patricia Shanahan <····@acm.org> wrote:
>> Tim Bradshaw wrote:
>>> On 2009-06-26 19:49:35 +0100, "Thomas F. Burdick" <········@gmail.com>
>>> said:
>>>
>>>> You sure about that? I thought that both C-ish macros and the Lisp
>>>> MACRO mechanism came about around 1970 or so.
>>>
>>> The earliest reference I am aware of to Lisp macros is AIM-5, which
>>> describes macros for Lisp 1.5 in 1963. The Lisp 1.5 manual does not
>>> mention macros. So I'm guessing a date some time in 1963, or possibly a
>>> little earlier.
>>>
>>
>>
>> The Software Preservation Group web page for Lisp history,
>> http://www.softwarepreservation.org/projects/LISP/ has a link to an
>> October 22, 1963 paper "MACRO Definition for LISP" by Timothy P. Hart,
>> ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-057.pdf
>>
>> I don't know enough about Lisp to evaluate whether what it describes is
>> the foundation of the current Lisp feature. Perhaps someone with the
>> necessary knowledge could take a look at it?
>
> It positively, definitely describes the foundations of macros.
>
> [...]
>
> The SETQ expansion is achieved by means of
>
> MACRO ((STASH (LAMBDA (FORM)
> (LIST (QUOTE SETQ)
> (CADAR FORM)
> (LIST (CONS (CADR FORM)
> (CADAR FORM)))))))
>
> (Indentation mine).
>
> This is in an old-style ``eval quote'' notation in which the outer parentheses
> were omitted from the toplevel form. But basically the macro would work
> today, with only a minor code update.
In http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html
you have a prefix that allow you to run directly these punch cards...
You just use (driver "stash.job") instead of (load "stash.lisp").
You will have to add the definition for the MACRO operator:
;; not tested.
(define macro (definitions)
(dolist (def definitions)
(destructuring-bind (name (lambda (form) &body body)) def
(assert (eq 'lambda lambda))
(eval `(defmacro ,name (&whole ,form) ,@body)))))
> [...]
>
> Clearly, the paper's author didn't cut and paste his own code from
> the text editor into the Lisp window of his graphics worksation
> to try it out. :) :) :)
Good luck trying to cut with scissors the top row of the punch cards
and paste it with glue on your paper... And this, if you have card
punchers able to print on the cards too.
--
__Pascal Bourguignon__
On Jun 26, 12:06 pm, Tim Bradshaw <····@tfeb.org> wrote:
> On 2009-06-26 14:48:47 +0100, ACL <··················@gmail.com> said:
>
> [irrelevancies deleted]
>
> > But anyway, maybe it would be less confusing if we called them
> > 'compile time source-code manipulating functions'.
>
> "macro" is a fine name.
Not if that's not actually what it is.
On 2009-06-26 21:51:30 +0100, Series Expansion <·······@gmail.com> said:
> Not if that's not actually what it is.
Who defines "what it is"? Do you have some kind of tablets handed to
you by God with a definition of the word?
On Jun 27, 8:55 am, Tim Bradshaw <····@tfeb.org> wrote:
> On 2009-06-26 21:51:30 +0100, Series Expansion <·······@gmail.com> said:
>
> > Not if that's not actually what it is.
>
> Who defines "what it is"? Do you have some kind of tablets handed to
> you by God with a definition of the word?
A user posting from Bell in Ottawa, who leaps to conclusions based on
rumour and naming and then defends those errors long past all
reason... Hmm, where have we seen this before?
-o
On Jun 27, 3:07 pm, Owen Jacobson <············@gmail.com> wrote:
> On Jun 27, 8:55 am, Tim Bradshaw <····@tfeb.org> wrote:
>
> > On 2009-06-26 21:51:30 +0100, Series Expansion <·······@gmail.com> said:
>
> > > Not if that's not actually what it is.
>
> > Who defines "what it is"? Do you have some kind of tablets handed to
> > you by God with a definition of the word?
>
> A user posting from Bell in Ottawa, who leaps to conclusions based on
> rumour and naming and then defends those errors long past all
> reason... Hmm, where have we seen this before?
I honestly don't know. Certainly plenty of people here have been
making all sorts of errors and jumping to all sorts of conclusions,
though I'm not one of them. A number of them have apparently been
leaping to conclusions about me, though.
On Sat, 27 Jun 2009 13:55:30 +0100, Tim Bradshaw <···@tfeb.org> said:
> Who defines "what it is"?
Humpty-Dumpty...
---Vassil.
--
Vassil Nikolov <········@pobox.com>
(1) M(Gauss);
(2) M(a) if M(b) and declared(b, M(a)),
where M(x) := "x is a mathematician".
On Jun 28, 8:07 pm, Vassil Nikolov <········@pobox.com> wrote:
> On Sat, 27 Jun 2009 13:55:30 +0100, Tim Bradshaw <····@tfeb.org> said:
>
> > Who defines "what it is"?
>
> Humpty-Dumpty...
No, the dictionary.
On Jun 28, 11:47 pm, Series Expansion <·······@gmail.com> wrote:
> On Jun 28, 8:07 pm, Vassil Nikolov <········@pobox.com> wrote:
>
> > On Sat, 27 Jun 2009 13:55:30 +0100, Tim Bradshaw <····@tfeb.org> said:
>
> > > Who defines "what it is"?
>
> > Humpty-Dumpty...
>
> No, the dictionary.
OK, this is straight from Mirriam-Webster, since you mentioned them as
being the ultimate reference:
Main Entry: macro
Function: noun
Inflected Form(s): plural macros
Etymology: short for macroinstruction
Date: 1959
: a single computer instruction that stands for a sequence of
operations
That easily includes Lisp style macros, I think.
On Jul 1, 3:32 pm, fortunatus <··············@excite.com> wrote:
> On Jun 28, 11:47 pm, Series Expansion <·······@gmail.com> wrote:
>
> > On Jun 28, 8:07 pm, Vassil Nikolov <········@pobox.com> wrote:
>
> > > On Sat, 27 Jun 2009 13:55:30 +0100, Tim Bradshaw <····@tfeb.org> said:
>
> > > > Who defines "what it is"?
>
> > > Humpty-Dumpty...
>
> > No, the dictionary.
>
> : a single computer instruction that stands for a sequence of
> operations
>
> That easily includes Lisp style macros, I think.
That one is clearly flawed. It would cover a function call, operator,
or almost anything else.
On Jun 27, 8:55 am, Tim Bradshaw <····@tfeb.org> wrote:
> On 2009-06-26 21:51:30 +0100, Series Expansion <·······@gmail.com> said:
>
> > Not if that's not actually what it is.
>
> Who defines "what it is"?
The dictionary.
> Do you have some kind of tablets handed to
> you by God with a definition of the word?
No, but I do have some paper handed to me by Webster's with a
definition of the word.
On 2009-06-29 04:46:05 +0100, Series Expansion <·······@gmail.com> said:
> No, but I do have some paper handed to me by Webster's with a
> definition of the word.
Webster's , of course, being the preferred source for any kind of
computing term.
But, actually:
macro |ˈmakrəʊ|
noun ( pl. -ros)
1 (also macro instruction) Computing a single instruction that expands
automatically into a set of instructions to perform a particular task.
That looks to me like a fine definition of Lisp-style macros.
On Jun 29, 5:31 am, Tim Bradshaw <····@tfeb.org> wrote:
> On 2009-06-29 04:46:05 +0100, Series Expansion <·······@gmail.com> said:
>
> > No, but I do have some paper handed to me by Webster's with a
> > definition of the word.
>
> [insult deleted]
Most illogical.
Series Expansion wrote:
> On Jun 29, 5:31 am, Tim Bradshaw <····@tfeb.org> wrote:
>> On 2009-06-29 04:46:05 +0100, Series Expansion <·······@gmail.com> said:
>>> No, but I do have some paper handed to me by Webster's with a
>>> definition of the word.
>> Webster's , of course, being the preferred source for any kind of computing term.
>>
>> But, actually:
>>
>> macro |ˈmakrəʊ|
>> noun ( pl. -ros)
>> 1 (also macro instruction) Computing a single instruction that expands automatically into a set of instructions to perform a particular task.
>>
>> That looks to me like a fine definition of Lisp-style macros.
>
> Most illogical.
Illogical to check Webster when you suggested it !?!?
Arne
On Jul 11, 8:23 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On Jun 29, 5:31 am, Tim Bradshaw <····@tfeb.org> wrote:
> >> On 2009-06-29 04:46:05 +0100, Series Expansion <·······@gmail.com> said:
> >>> No, but I do have some paper handed to me by Webster's with a
> >>> definition of the word.
> >> Webster's , of course, being the preferred source for any kind of computing term.
>
> >> But, actually:
>
> >> macro |ˈmakrəʊ|
> >> noun ( pl. -ros)
> >> 1 (also macro instruction) Computing a single instruction that expands automatically into a set of instructions to perform a particular task.
>
> >> That looks to me like a fine definition of Lisp-style macros.
>
> > Most illogical.
>
> Illogical to check Webster when you suggested it !?!?
No, illogical to claim that it's a "fine definition" of "Lisp-style"
macros.
··············@excite.com writes:
> The thing about GYNSYM, and I confess I am not the one to answer, is
> that somehow both the lifetime of the symbol in the symbol table
> (internment) and the ability to reference it are _wierd_.
Well, the part that takes a bit of experience to understand is the
interaction between the reader and structures, since that is what your
issue here turns on.
> And, I didn't realize it until your post pointed out the issues
> surrounding representation! Thanks!
>
> Here's wierd: this works as expected:
> ----
> >(eval (let ((c (gensym))) `(progn (setq ,c 'test)(print ,c)(terpri))))
Right. That is because the LET establishes a binding of the symbol C to
the gensym. Backquote operates on objects, not surface text, so what
this is doing is inserting the actual symbol object referred to by C
into the resulting list structure. And that guarantees that the objects
introduced into backquote by ,c are the same.
> TEST
> NIL
> ----
> But this does not work as I expected:
> ----
> >(progn (setq #:G1801 'test)(print #:G1801)(terpri))
>
> Error in PROGN [or a callee]: The variable #:G1801 is unbound.
> ----
>
> I know you can't read and intern a symbol like #:<name>, but somehow
> it is done in the context of back-quote processing...
The reader handles the job of reading and interneing symbols. But the
#:<name> syntax specifically directs the reader NOT to intern the
resulting name. So each time, for example #:G1801 is encountered, you
get a new, distinct symbol. This is easily seen by comparing the
following:
(let (c #:G1801)
(eq c c))
==> T because you have the same reference.
(eq #:G1801 #:G1801)
==> NIL because two different, uninterned symbols with the symbol-name
"G1801" are created.
You can see the same effect using other operators that create new
objects as well. If you remember that gensym is really just an object
constructor, it becomes clear that you get separate objects.
(let (c (list 1 2 3))
(eq c c)) ==> T
(eq (list 1 2 3) (list 1 2 3)) ==> NIL
(defclass foo ()
(name :initarg :name))
(eq (make-instance 'foo :name "BAR") (make-instance 'foo :name "BAR"))
==> NIL
--
Thomas A. Russ, USC/Information Sciences Institute
Frank GOENNINGER wrote:
> Lew <·····@lewscanon.com> writes:
>
>> Frank GOENNINGER wrote:
>>> Series Expansion <·······@gmail.com> writes:
>>>
>>>> In my browsings around the net, the free Lisp implementations I've
>>>> come across seem to all be line-oriented. While it's possible that
>>>> I've missed something, it looks like the facilities required to create
>>>> a more capable UI are unavailable outside of expensive commercial
>>>> implementations.
>>> http://www.inspiration.com/videos/InspireData
>>>
>>> Done in Lisp.
>> Lisp is off-topic for a Java newsgroup.
>
> Your comment is off-topic for a any newsgroup.
I disagree. Is it a matter of childish glee in being a bad boy that makes you
want to keep re-crossposting back to clj.programmer as you engage in a
pointless flamewar with Series McShameUs about a strictly Lisp topic? Is it
such a terrible, terrible thing to ask that you confine the Lisp discussion to
the Lisp newsgroup? Are you simply committed to being annoying?
> Lew, you did better before...
You are treading in trollish waters, "Frank".
--
Lew
Lew <·····@lewscanon.com> writes:
> Frank GOENNINGER wrote:
>> Lew <·····@lewscanon.com> writes:
>>
>>> Frank GOENNINGER wrote:
>>>> Series Expansion <·······@gmail.com> writes:
>>>>
>>>>> In my browsings around the net, the free Lisp implementations I've
>>>>> come across seem to all be line-oriented. While it's possible that
>>>>> I've missed something, it looks like the facilities required to create
>>>>> a more capable UI are unavailable outside of expensive commercial
>>>>> implementations.
>>>> http://www.inspiration.com/videos/InspireData
>>>>
>>>> Done in Lisp.
>>> Lisp is off-topic for a Java newsgroup.
>>
>> Your comment is off-topic for a any newsgroup.
>
> I disagree. Is it a matter of childish glee in being a bad boy that
> makes you want to keep re-crossposting back to clj.programmer as you
> engage in a pointless flamewar with Series McShameUs about a strictly
> Lisp topic? Is it such a terrible, terrible thing to ask that you
> confine the Lisp discussion to the Lisp newsgroup? Are you simply
> committed to being annoying?
When reading between the lines of my previous post it should have been
clear that all this (meaning: that whole thread or threads) is precisely
not Lisp related. It has been taken to a "discussion" where we are
beyond rational behavior and I simply do not see why the Lispers only
should suffer from postings from our special friends Series and Seamus.
They are Java-boys and it would do us all good if the Java powers take
them down.
>
>> Lew, you did better before...
>
> You are treading in trollish waters, "Frank".
Oh, just for the record: No need to put my name in quotation marks. My
name really is Frank - or did you want to imply something else.? I am
"man enough" to reveal my name when posting, no less.
And I disagree being in "trollish waters". There was an intention (a
sincere one) behind - as written above.
Besides: This is Usenet. So, in the end, there's just our own countries'
laws that mark a border we can't cross - and this is true for all of
us. So, as long as our two friends are not breaking any laws in their
country, we of course simply have to be patient and have to wait until
they are loosing interest.
But I said enough is enough. And it's enough now for me - I took that a
bit on the personal side and therefore posted again ;-)
Over and out. 73 (as we Ham Radio guys say)
On Tue, 19 May 2009 17:31:18 +0200, Frank GOENNINGER wrote:
> us. So, as long as our two friends are not breaking any laws in their
> country, we of course simply have to be patient and have to wait until
> they are loosing interest.
Nope. Just filter them out, and they don't exist any more.
That's what I did with Lew too when he started spitting out one-liner
posts. BTW, it is pretty much telling that the guy can't use his own
newsreader to do this. Cf with people who write letters to TV
channels on what they should broadcast instead of reaching for the
remote.
Tamas
On May 19, 11:57 am, Tamas K Papp <······@gmail.com> wrote:
> On Tue, 19 May 2009 17:31:18 +0200, Frank GOENNINGER wrote:
> > us. So, as long as our two friends are not breaking any laws in their
> > country, we of course simply have to be patient and have to wait until
> > they are loosing interest.
>
> Nope. Just filter them out, and they don't exist any more.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tamas and Frank.
I do not need "filtering out" and I resent the implication that I do.
> That's what I did with Lew too when he started spitting out one-liner
> posts.
Lew posted nothing of value to this thread; filtering him out is quite
rational, unlike, say, filtering me out.
Frank GOENNINGER wrote:
> Lew <·····@lewscanon.com> writes:
>> I disagree. Is it a matter of childish glee in being a bad boy that
>> makes you want to keep re-crossposting back to clj.programmer as you
>> engage in a pointless flamewar with Series McShameUs
I don't care for the way your childish insult aimed at Series Expansion
bears a resemblance to a mangling of my own name. I also suspect it is
not a coincidence. Why drag my name into this corner of the thread,
where I was not involved?
> When reading between the lines of my previous post it should have been
> clear that all this (meaning: that whole thread or threads) is precisely
> not Lisp related. It has been taken to a "discussion" where we are
> beyond rational behavior and I simply do not see why the Lispers only
> should suffer from postings from our special friends Series and Seamus.
I am not a "special friend" nor do I inflict suffering. I find these
characterizations of me grossly rude, vulgar, unproductive, and
uncivilized. Please apologize, preferably to both of us but certainly to me.
The discussion is "beyond rational behavior" because our side's logical
arguments, evidence, citations, and rebuttals are met with insults,
hand-waves, exultations of faith, rude demands, non-sequiturs, off-topic
asides, and unsupported assertions, in roughly equal measure.
I find it especially disturbing that several people seem to genuinely
view myself and Series Expansion as evil, and to be singling us out for
particular hostility. I, for one, have been among the calmest
participants in this whole affair, with little in the way of flaming or
rudeness and even a fairly long absence. And most of the insults flung
my way were flung during that absence, at someone you'd apparently
assumed to have quit participating. That means they were both unprovoked
and, in some sense, spoken "behind my back". That's underhanded. Series
Expansion hasn't been much worse: from what I've skimmed, long detailed
arguments with chains of meticulous reasoning from first principles, and
a remarkably even temper when provoked by some pretty vicious insults
with only a handful of flames in response to such and more usually just
a calm statement that that sort of flamage does not support the case for
either side and is unproductive.
How can any rational observer agree with the tarring of the voices of
reason with the "evil" brush (or the "troll" brush, or any other
pejorative) in preference to these characters?:
1. A violent flamer with little of substance to say (Lew)
2. Several individuals who do attempt to argue their case, at least,
but who also liberally sprinkle their arguments with ad hominem
attacks.
3. Several more who largely refrain from flaming, but who accuse
others of flaming who did not and whose arguments consist largely
of unsupported assertions and exhortations of faith.
Any one of these categories contains worthier targets than I or Series
Expansion.
However, playing the blame game is also unproductive, so it would be
best for there to be no targets, no tarring of anybody with any brush.
So, can we either quit or get back to the business of civilly discussing
the relative merits of Java and Lisp please?
> They are Java-boys and it would do us all good if the Java powers take
> them down.
Threats and incitement to violence? Or, at least, incitements to
censorship? This is getting frankly ridiculous. It's a programming
language debate, not a fucking life-or-death matter. Can we not comport
ourselves like adults?
>>> Lew, you did better before...
>> You are treading in trollish waters, "Frank".
>
> Oh, just for the record: No need to put my name in quotation marks. My
> name really is Frank - or did you want to imply something else.?
He appears to do this with everyone's names. Mine and Series
Expansion's, too (the latter of which is certainly a pseudonym, mind).
> Besides: This is Usenet. So, in the end, there's just our own countries'
> laws that mark a border we can't cross - and this is true for all of
> us. So, as long as our two friends are not breaking any laws in their
> country, we of course simply have to be patient and have to wait until
> they are loosing interest.
This is condescending and rude, since it implies that we're ranting or
otherwise irrational when nothing could be further from the truth.
On May 19, 11:31 am, Frank GOENNINGER <······@googlemail.com> wrote:
> Lew <·····@lewscanon.com> writes:
> > Frank GOENNINGER wrote:
> >> Lew <·····@lewscanon.com> writes:
> >>> Frank GOENNINGER wrote:
> >>>> Series Expansion <·······@gmail.com> writes:
> >>>>> In my browsings around the net, the free Lisp implementations I've
> >>>>> come across seem to all be line-oriented. While it's possible that
> >>>>> I've missed something, it looks like the facilities required to create
> >>>>> a more capable UI are unavailable outside of expensive commercial
> >>>>> implementations.
> >>>>http://www.inspiration.com/videos/InspireData
> >>>> Done in Lisp.
> >>> Lisp is off-topic for a Java newsgroup.
> >> Lew, you did better before...
> > You are treading in trollish waters, "Frank".
>
> I disagree being in "trollish waters".
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Frank and "Lew".
> Besides: This is Usenet. So, in the end, there's just our own countries'
> laws that mark a border we can't cross - and this is true for all of
> us. So, as long as our two friends are not breaking any laws in their
> country, we of course simply have to be patient and have to wait until
> they are loosing interest.
This implies my presence here is undesirable, and thus yet another
personal attack. Have you not yet grasped that such attacks do not
advance your goals in any discernible manner?
Openly discussing a desire to get rid of me is rude, unwise, and
potentially illegal, if interpreted as implying a threat.
On May 19, 9:54 am, Lew <·····@lewscanon.com> wrote:
> Frank GOENNINGER wrote:
> > Lew <·····@lewscanon.com> writes:
>
> >> Frank GOENNINGER wrote:
> >>> Series Expansion <·······@gmail.com> writes:
>
> >>>> In my browsings around the net, the free Lisp implementations I've
> >>>> come across seem to all be line-oriented. While it's possible that
> >>>> I've missed something, it looks like the facilities required to create
> >>>> a more capable UI are unavailable outside of expensive commercial
> >>>> implementations.
> >>>http://www.inspiration.com/videos/InspireData
> >>> Done in Lisp.
> >> Lisp is off-topic for a Java newsgroup.
> > Lew, you did better before...
>
> You are treading in trollish waters, "Frank".
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
Frank GOENNINGER wrote:
> Lew <·····@lewscanon.com> writes:
>> Frank GOENNINGER wrote:
>>> Series Expansion <·······@gmail.com> writes:
>>>
>>>> In my browsings around the net, the free Lisp implementations I've
>>>> come across seem to all be line-oriented. While it's possible that
>>>> I've missed something, it looks like the facilities required to create
>>>> a more capable UI are unavailable outside of expensive commercial
>>>> implementations.
>>> http://www.inspiration.com/videos/InspireData
>>>
>>> Done in Lisp.
>> Lisp is off-topic for a Java newsgroup.
>
> Your comment is off-topic for a any newsgroup.
>
> Lew, you did better before...
It is not universal agreed on whether comments about something
being on or off topic is itself on or off topic.
I do not see a problem Lew stating so.
ONCE !
Arne
On May 19, 4:56 am, Frank GOENNINGER <······@googlemail.com> wrote:
> Lew <·····@lewscanon.com> writes:
> > Frank GOENNINGER wrote:
> >> Series Expansion <·······@gmail.com> writes:
>
> >>> In my browsings around the net, the free Lisp implementations I've
> >>> come across seem to all be line-oriented. While it's possible that
> >>> I've missed something, it looks like the facilities required to create
> >>> a more capable UI are unavailable outside of expensive commercial
> >>> implementations.
>
> >>http://www.inspiration.com/videos/InspireData
>
> >> Done in Lisp.
>
> > Lisp is off-topic for a Java newsgroup.
>
> Your comment is off-topic for a any newsgroup.
>
> Lew, you did better before...
Where? I have not seen it.
Frank GOENNINGER wrote:
> Series Expansion <·······@gmail.com> writes:
>> In my browsings around the net, the free Lisp implementations I've
>> come across seem to all be line-oriented. While it's possible that
>> I've missed something, it looks like the facilities required to create
>> a more capable UI are unavailable outside of expensive commercial
>> implementations.
>
> http://www.inspiration.com/videos/InspireData
Or if we can agree on considering Clojure to be
a LISP, then Clojure can use Swing. There is
an example on one of the main pages
(http://clojure.org/jvm_hosted).
Arne
Series Expansion wrote:
> Regardless, Lisp appears to have been designed for a simple line-
> oriented-terminal model of interaction, much like bare-bones ANSI C,
> actually, which requires third-party libraries to even do curses-type
> stuff, let alone graphics and mouse support. Unlike C, it seems
> difficult for such libraries to exist when Lisp, unlike C, compiles to
> bytecode. Certainly third-party Java libraries cannot, unless they use
> JNI, directly access hardware and thereby attain capabilities
> involving interfacing with the hardware or the host OS that weren't
> built into the JVM or the standard libraries. And I have not heard of
> any Lisp facility analogous to JNI. So unless the LVM (or whatever you
> want to call it) provides a particular form of host-system interface,
> it is apparently unavailable to programs.
>
> In my browsings around the net, the free Lisp implementations I've
> come across seem to all be line-oriented. While it's possible that
> I've missed something, it looks like the facilities required to create
> a more capable UI are unavailable outside of expensive commercial
> implementations.
If you pick Clojure then you can use the entire Java library
including JNI calls, Swing etc.etc..
Arne
On 15 maio, 15:30, Series Expansion <·······@gmail.com> wrote:
> On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
>
> > It does not rely on any internal representation
> > of the functions by some implementation - this would make the code
> > unportable - but it provides a macro that retrieves the function's
> > body to be stored into a file and then restored back again. It is as
> > simple as this: instead of writing (lambda (...) ...) you write (st
> > (lambda (...) ...).
>
> Cool. But why store a function that's there in your code anyway?
>
> Also, the commonplace lisp problem of short names. The name "st" in
> particular isn't particularly clear in meaning, and moreover, you'll
> quickly run out of short names to use in a big enough project anyway.
>
> > In Java I am pretty sure this isn't conceivable because
>
> > 1) Java does not have dynamically created functions (or am I wrong?)
> > 2) Java Code is not an easy manipulable data
> > 3) Java doesn't have macros.
>
> > As you can see, macros not only provide a way to make your
> > applications shorter or more readable, but they also make it possible
> > to do somethings that otherwise couldn't be done.
>
> Java is Turing-complete, so it can probably be done.
Oh, yes, of course, because there is even a CL compiler written in
Java :P
That is not exactly what I meant. You can do anything, but how non-
extensible, non-compatible with existing code and complicated this
would be? The library that I made is pretty small, straightforward and
readable, and it fits inside CL perfectly, with small changes when you
want to use it.
>
> You can certainly implement an interpreter in Java that can save and
> load its code. This also lets the function be created at run-time from
> other data or user-input.
An interpreter would be slow. My macro does not change the function
that will be generated, so it is as fast as it would be without my
macro. But, okay, you do that and in about two months you show me your
thousands of lines long code that you had to do to accomplish that.
>
> You can also monkey about with ClassLoader and byte arrays and
> bytecode, or (since Java 6) with ClassLoader, Compiler, and Strings
> full of Java source code, and make classes on the fly, save them to
> disk (e.g. as .class files), load them, instantiate them (with
> reflection), and invoke them (with reflection, or polymorphically
> through a compile-time-known base class or interface).
Why don't you write your own entire compiler instead with the new
feature added? This what you want to do is just painful, just to add a
small feature to the language. If anyone needed to do this in Java, he
or she would not do it, and change the approach he or she is using to
not need it. That is what I meant by "it can't be done".
>
> So yeah, Java can do it, though it's clunky. And Java can do it with
> "functions" created on the fly, not just some existing one like
> Math.sin(double). In the case of using ClassLoader and eventually
> calling the object via a base class or interface rather than
> reflection, and using a JIT-enabled JVM, it can even run the new
> function with performance rivaling compiled and optimized C code.
On May 15, 2:56 pm, gugamilare <··········@gmail.com> wrote:
> On 15 maio, 15:30, Series Expansion <·······@gmail.com> wrote:
> > Java is Turing-complete, so it can probably be done.
>
> Oh, yes, of course, because there is even a CL compiler written in
> Java :P
>
> That is not exactly what I meant. You can do anything, but how non-
> extensible, non-compatible with existing code and complicated this
> would be? The library that I made is pretty small, straightforward and
> readable, and it fits inside CL perfectly, with small changes when you
> want to use it.
And if code using your library and code using a different library to
do the same job get used together, it's collision time.
Heck, just two hunks of code separately using your library, but with
different "small changes". Then there's GUARANTEED to be name clashes
and incompatibility.
Meanwhile, your objection to Java's capabilities in this area (which
are used very sparingly anyway, thus apparently needed very sparingly)
is that they will cause ... incompatibility.
> > You can certainly implement an interpreter in Java that can save and
> > load its code. This also lets the function be created at run-time from
> > other data or user-input.
>
> An interpreter would be slow.
Hence the alternative, further down in my post.
> > You can also monkey about with ClassLoader and byte arrays and
> > bytecode, or (since Java 6) with ClassLoader, Compiler, and Strings
> > full of Java source code, and make classes on the fly, save them to
> > disk (e.g. as .class files), load them, instantiate them (with
> > reflection), and invoke them (with reflection, or polymorphically
> > through a compile-time-known base class or interface).
>
> Why don't you write your own entire compiler instead with the new
> feature added?
Why bother with the time and (probably) bugs when you can use the
existing compiler?
> If anyone needed to do this in Java, he
> or she would not do it, and change the approach he or she is using to
> not need it. That is what I meant by "it can't be done".
In other words, when you said "it can't be done" you didn't actually
mean it can't be done. Closer to "nobody wants to do it". Only if
you'd stated it that way to begin with, it wouldn't have seemed to
support your argument. "Lisp lets you more easily do something that
hardly anybody wants to do." Wow! What an endorsement! :)
Series Expansion <·······@gmail.com> writes:
> On May 15, 2:56�pm, gugamilare <··········@gmail.com> wrote:
>> On 15 maio, 15:30, Series Expansion <·······@gmail.com> wrote:
>> > Java is Turing-complete, so it can probably be done.
>>
>> Oh, yes, of course, because there is even a CL compiler written in
>> Java :P
>>
>> That is not exactly what I meant. You can do anything, but how non-
>> extensible, non-compatible with existing code and complicated this
>> would be? The library that I made is pretty small, straightforward and
>> readable, and it fits inside CL perfectly, with small changes when you
>> want to use it.
>
> And if code using your library and code using a different library to
> do the same job get used together, it's collision time.
Never happens in Common Lisp. We didn't mention it because the
discussion so far only involved macros, but Common Lisp is a full
featured programming language, and there are tools to solve all the
problems that occured to lisp programmer in the last fifty years. You
see, there's a lot of accumulated experience and knowledge, even if
unfortunately it's not spread over a big number of programmer.
So in this case, the notion of PACKAGE, which coarsely correspond to
that of C++ namespace is put to use, and there's never any collision
problem between two CL library because they live in different
namespaces. Of course, there may always be some collision on the
usage of some global resource, but at least names are not such a
global resource.
> Heck, just two hunks of code separately using your library, but with
> different "small changes". Then there's GUARANTEED to be name clashes
> and incompatibility.
And even in this case, it's rather trivial to load one version of the
library, and to _rename_ (at run-time) the packages of that version,
before loading the other version. Thus you can easily work with two
versions of the same libraries at the same time. (Or you can of
course do what you'd do with another programming language, modify the
source of the different versions to be able to work with both at the
same time).
Frankly, I must say that I find your objections rather silly...
> Meanwhile, your objection to Java's capabilities in this area (which
> are used very sparingly anyway, thus apparently needed very sparingly)
> is that they will cause ... incompatibility.
>
> [...]
>> > You can also monkey about with ClassLoader and byte arrays and
>> > bytecode, or (since Java 6) with ClassLoader, Compiler, and Strings
>> > full of Java source code, and make classes on the fly, save them to
>> > disk (e.g. as .class files), load them, instantiate them (with
>> > reflection), and invoke them (with reflection, or polymorphically
>> > through a compile-time-known base class or interface).
>>
>> Why don't you write your own entire compiler instead with the new
>> feature added?
>
> Why bother with the time and (probably) bugs when you can use the
> existing compiler?
Indeed why? When you can use a lisp compiler, and just patch it at a
high level with a few macros.
>> If anyone needed to do this in Java, he
>> or she would not do it, and change the approach he or she is using to
>> not need it. That is what I meant by "it can't be done".
>
> In other words, when you said "it can't be done" you didn't actually
> mean it can't be done. Closer to "nobody wants to do it". Only if
> you'd stated it that way to begin with, it wouldn't have seemed to
> support your argument. "Lisp lets you more easily do something that
> hardly anybody wants to do." Wow! What an endorsement! :)
Indeed. In lisp, it's easy to do things hard to do in other
languages, and it's possible to do things that are impossible in other
programming language. Get used to it, that's the way it is.
--
__Pascal Bourguignon__
On May 15, 7:05 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > And if code using your library and code using a different library to
> > do the same job get used together, it's collision time.
>
> Never happens in Common Lisp.
A hand-wave like this is not an argument. An idealist supposes people
will always do something more elegant than using two pieces of code
together that use incompatible versions of yet another bit of code. A
pragmatist knows that people will throw any two pieces of code
together eventually and having a way to deal with conflicts is
essential.
Example of a piece of software that assumed collisions would "never
happen": Windows 95. Remember DLL Hell?
Example of a piece of software that took the pragmatic approach, after
learning its lesson: Windows XP. DLL versioning and DLLs often kept
with programs, rather than in the system directory where two different
same-name ones would clobber one other, albeit at the cost of
sometimes having several copies of the same DLL in various Program
Files subdirectories.
Another thing you might fondly remember from Windows 95 is the
infamous BSOD. Much less common with XP. Guess why.
> We didn't mention it because the
> discussion so far only involved macros, but Common Lisp is a full
> featured programming language, and there are tools to solve all the
> problems that occured to lisp programmer in the last fifty years.
I'm more worried about all the problems that didn't occur to Lisp
programmers in their fifty years of tinkering with theorem-provers and
AI research in various ivory towers, but that J2EE server admins and
word-processor developers and social-networking site coders and
Limewire hackers encounter every day and have pragmatic solutions for.
> You see, there's a lot of accumulated experience and knowledge, even if
> unfortunately it's not spread over a big number of programmer.
Experience and knowledge doing what? Keeping the ivory from getting
dingy? :) Meanwhile, hackers all over the world have to maintain
systems that run power grids and dispatch 911 calls, serve millions of
customers a second at the bigger e-commerce sites, optimize inventory
management for high-volume bricks-and-mortar businesses, route network
packets, route trucks and buses and taxis and ambulances, and even run
in thermostats and SUV fuel-injection systems and bomb-sniffing
robots.
> So in this case, the notion of PACKAGE, which coarsely correspond to
> that of C++ namespace is put to use, and there's never any collision
> problem between two CL library because they live in different
> namespaces. Of course, there may always be some collision on the
> usage of some global resource,
such as a pre-existing system class or generic function or whatever
that needs modifying,
> but at least names are not such a global resource.
Hmm.
> > Heck, just two hunks of code separately using your library, but with
> > different "small changes". Then there's GUARANTEED to be name clashes
> > and incompatibility.
>
> And even in this case, it's rather trivial to load one version of the
> library, and to _rename_ (at run-time) the packages of that version,
> before loading the other version.
How crufty.
> Frankly, I must say that I find your objections rather silly...
Not as silly as that thing on your head. You should wear a baseball
cap or something.
> >> Why don't you write your own entire compiler instead with the new
> >> feature added?
>
> > Why bother with the time and (probably) bugs when you can use the
> > existing compiler?
>
> Indeed why? When you can use a lisp compiler, and just patch it at a
> high level with a few macros.
The Java compiler, meanwhile, doesn't need patching. It just works.
> >> If anyone needed to do this in Java, he
> >> or she would not do it, and change the approach he or she is using to
> >> not need it. That is what I meant by "it can't be done".
>
> > In other words, when you said "it can't be done" you didn't actually
> > mean it can't be done. Closer to "nobody wants to do it". Only if
> > you'd stated it that way to begin with, it wouldn't have seemed to
> > support your argument. "Lisp lets you more easily do something that
> > hardly anybody wants to do." Wow! What an endorsement! :)
>
> Indeed.
Well, there you go, then.
> In lisp, it's easy to do things hard to do in other
> languages
Useful things, though?
> and it's possible to do things that are impossible in other
> programming language.
You're now claiming it has supra-Turing capabilities? What's the
bonus? Halting oracle? True-analog operations? The downside being:
what's the hardware requirements? I don't have a quantum computer over
here, after all, just a few ordinary Pentium workstations.
Series Expansion <·······@gmail.com> writes:
>> and it's possible to do things that are impossible in other
>> programming language.
>
> You're now claiming it has supra-Turing capabilities? What's the
> bonus? Halting oracle? True-analog operations? The downside being:
> what's the hardware requirements? I don't have a quantum computer over
> here, after all, just a few ordinary Pentium workstations.
No, I mean simple things, such as doing additions or multiplications.
[···@galatea :0.0 tmp]$ cat add.java
class Add
extends Object
{
static public void main(String[] args)
{
int tt=2100000000;
System.out.println("2,100,000,000+2,100,000,000 = "+(tt+tt));
}
}
[···@galatea :0.0 tmp]$ javac add.java && java Add
2,100,000,000+2,100,000,000 = -94967296
[···@galatea :0.0 tmp]$ clisp -norc -q -x '(let ((tt 2100000000)) (format t "~A + ~A = ~A~%" tt tt (+ tt tt)))'
2100000000 + 2100000000 = 4200000000
NIL
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> ···@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>>tt+tt (...) (+ tt tt)
>>
>> Now, imagine both within an inner loop of an image processing
>> program.
>
> http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf
>
> You cannot win. :-)
Oh, I bet they don't bother reading it. It may be too much to take for
them. I really *pray* for making them read this paper ...
Frank GOENNINGER wrote:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>
>> ···@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>>> tt+tt (...) (+ tt tt)
>>> Now, imagine both within an inner loop of an image processing
>>> program.
>> http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf
>>
>> You cannot win. :-)
>
> Oh, I bet they don't bother reading it. It may be too much to take for
> them. I really *pray* for making them read this paper ...
And you'd have to make me. Why on earth would I *want* to blow up my web
browser by clicking on a .pdf link? :)
On May 20, 12:01 am, Seamus MacRae <··········@live.ca.nospam> wrote:
> Frank GOENNINGER wrote:
> > ····@informatimago.com (Pascal J. Bourguignon) writes:
>
> >> ····@zedat.fu-berlin.de (Stefan Ram) writes:
>
> >>> ····@informatimago.com (Pascal J. Bourguignon) writes:
> >>>> tt+tt (...) (+ tt tt)
> >>> Now, imagine both within an inner loop of an image processing
> >>> program.
> >>http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf
>
> >> You cannot win. :-)
>
> > Oh, I bet they don't bother reading it. It may be too much to take for
> > them. I really *pray* for making them read this paper ...
>
> And you'd have to make me. Why on earth would I *want* to blow up my web
> browser by clicking on a .pdf link? :)
What are you using?
Opens fine (quickly even!) here on Linux with Firefox 3.
··················@gmail.com wrote:
> On May 20, 12:01 am, Seamus MacRae <··········@live.ca.nospam> wrote:
>> Frank GOENNINGER wrote:
>>> ····@informatimago.com (Pascal J. Bourguignon) writes:
>>>> ····@zedat.fu-berlin.de (Stefan Ram) writes:
>>>>> ····@informatimago.com (Pascal J. Bourguignon) writes:
>>>>>> tt+tt (...) (+ tt tt)
>>>>> Now, imagine both within an inner loop of an image processing
>>>>> program.
>>>> http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf
>>>> You cannot win. :-)
>>> Oh, I bet they don't bother reading it. It may be too much to take for
>>> them. I really *pray* for making them read this paper ...
>> And you'd have to make me. Why on earth would I *want* to blow up my web
>> browser by clicking on a .pdf link? :)
>
> What are you using?
> Opens fine (quickly even!) here on Linux with Firefox 3.
.pdf opens fine? It's a miracle!
.pdf opens quickly? By whose standards, a turtle?
Quickly in Firefox? On what, a Cray?
Seamus MacRae <··········@live.ca.nospam> writes:
> Frank GOENNINGER wrote:
>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>
>>> ···@zedat.fu-berlin.de (Stefan Ram) writes:
>>>
>>>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>>>> tt+tt (...) (+ tt tt)
>>>> Now, imagine both within an inner loop of an image processing
>>>> program.
>>> http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf
>>>
>>> You cannot win. :-)
>>
>> Oh, I bet they don't bother reading it. It may be too much to take for
>> them. I really *pray* for making them read this paper ...
>
> And you'd have to make me. Why on earth would I *want* to blow up my
> web browser by clicking on a .pdf link? :)
Why on Earth would you want to use a browser that blew up when you
clicked PDF links?
Paul Donnelly wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Frank GOENNINGER wrote:
>>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>>
>>>> ···@zedat.fu-berlin.de (Stefan Ram) writes:
>>>>
>>>>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>>>>> tt+tt (...) (+ tt tt)
>>>>> Now, imagine both within an inner loop of an image processing
>>>>> program.
>>>> http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf
>>>>
>>>> You cannot win. :-)
>>> Oh, I bet they don't bother reading it. It may be too much to take for
>>> them. I really *pray* for making them read this paper ...
>> And you'd have to make me. Why on earth would I *want* to blow up my
>> web browser by clicking on a .pdf link? :)
>
> Why on Earth would you want to use a browser that blew up when you
> clicked PDF links?
Well, technically it's Adobe's POS Acrobat Reader software that does the
exploding, I suspect.
Which means browser choice is irrelevant. :)
Seamus MacRae <··········@live.ca.nospam> writes:
> And you'd have to make me. Why on earth would I *want* to blow up my web
> browser by clicking on a .pdf link? :)
Well, if your web browser blows up handling pdf files, I think it's time
to look for a new web browser.
I think someone's written one in Common Lisp....
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> And you'd have to make me. Why on earth would I *want* to blow up my web
>> browser by clicking on a .pdf link? :)
>
> Well, if your web browser blows up handling pdf files, I think it's time
> to look for a new web browser.
I think they pretty much all do. Or at least hang for ages.
> I think someone's written one in Common Lisp....
Thanks, but no thanks. One that blows up handling every kind of file
would not be an improvement. :)
Seamus MacRae wrote:
> Frank GOENNINGER wrote:
>> Oh, I bet they don't bother reading it. It may be too much to take for
>> them. I really *pray* for making them read this paper ...
>
> And you'd have to make me. Why on earth would I *want* to blow up my web
> browser by clicking on a .pdf link? :)
Time for a better browser and/or PDF plugin.
Arne
···@zedat.fu-berlin.de (Stefan Ram) writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>tt+tt (...) (+ tt tt)
>
> Now, imagine both within an inner loop of an image processing
> program.
>
> The chance that »tt+tt« can be compiled into a simple machine
> instruction seems to be greater than the same chance for
> »(+ tt tt)«.
Why in the world? The chances are very good that your compiler will
transform "tt+tt" into "(+ tt tt)" before generating machine code.
> In Java, you pay the performance penalty for
> java.math.BigInteger, if you need it. It is harder for the
> programmer to write as it is harder for the engine to process.
In Common Lisp, you don't have to worry about the size of your integers
except in speed-critical sections, at which time you simply (DECLARE
(TYPE FIXNUM THAT-VARIABLE)), without needing to change the code using
THAT-VARIABLE.
I'd rather make it easy to do what I want than to make things that are
hard for the computer hard for me. Last I checked, the whole point of
computer programming was to make computers do the hard work.
On 16 maio, 20:41, ····@zedat.fu-berlin.de (Stefan Ram) wrote:
> Paul Donnelly <·············@sbcglobal.net> writes:
> >Why in the world? The chances are very good that your compiler will
> >transform "tt+tt" into "(+ tt tt)" before generating machine code.
>
> I used »(+ tt tt)« not to refer the representation as an AST,
> but to the arbitrary-precision semantics.
You can specify it not to have arbitrary-precision if you want to (as
Paul Donnelly already stated) and Lisp programmers will do that when
they need speed. But there are places where this is a premature and
useless optimization that will make you restrict your code.
Well, ok, you can argue that there are up and down sides from both
sides, and I agree when it comes to number arithmetics. I won't agree
with you that this is the case with other kind of data manipulation,
specially generic functions and methods.
On May 16, 10:27 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> >> and it's possible to do things that are impossible in other
> >> programming language.
>
> > You're now claiming it has supra-Turing capabilities? What's the
> > bonus? Halting oracle? True-analog operations? The downside being:
> > what's the hardware requirements? I don't have a quantum computer over
> > here, after all, just a few ordinary Pentium workstations.
>
> No, I mean simple things, such as doing additions or multiplications.
>
> [···@galatea :0.0 tmp]$ cat add.java
> class Add
> extends Object
> {
>
> static public void main(String[] args)
> {
> int tt=2100000000;
> System.out.println("2,100,000,000+2,100,000,000 = "+(tt+tt));
> }
>
> }
>
> [···@galatea :0.0 tmp]$ javac add.java && java Add
> 2,100,000,000+2,100,000,000 = -94967296
>
> [···@galatea :0.0 tmp]$ clisp -norc -q -x '(let ((tt 2100000000)) (format t "~A + ~A = ~A~%" tt tt (+ tt tt)))'
> 2100000000 + 2100000000 = 4200000000
> NIL
Ignoring the spurious NIL here, have you forgotten a) Turing
completeness and b) java.math.BigInteger?
Series Expansion wrote:
> Ignoring the spurious NIL here, have you forgotten a) Turing
> completeness and b) java.math.BigInteger?
They have not.
--
Lew
On May 17, 12:52 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > Ignoring the spurious NIL here, have you forgotten a) Turing
> > completeness and b) java.math.BigInteger?
>
> They have not.
Although you neglected to quote it, the preceding post had contained
an implied claim that Java was incapable of other than modulo-2^32
arithmetic. In fact, it is natively capable of true integer arithmetic
and integer arithmetic modulo 2^64, 2^32, 2^16, and 2^8, and with the
explicit use of the % operator and BigInteger.mod() it's not difficult
to use pretty much any other modulus.
Furthermore, Java also has BigDecimal, float, and double, and the
ability to "roll one's own" numerical types.
(The attempt to misdirect this particular post away from
comp.lang.java.programmer is especially odd since it is clearly
primarily about Java, "Lew".)
On 15 maio, 15:30, Series Expansion <·······@gmail.com> wrote:
> On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
>
> > It does not rely on any internal representation
> > of the functions by some implementation - this would make the code
> > unportable - but it provides a macro that retrieves the function's
> > body to be stored into a file and then restored back again. It is as
> > simple as this: instead of writing (lambda (...) ...) you write (st
> > (lambda (...) ...).
>
> Cool. But why store a function that's there in your code anyway?
>
Oh, I forgot this question. Because in Lisp you can create functions
like objects. The canonical example:
(defun make-adder (n)
(lambda (x) (+ x n)))
The function make-adder receives a number n, and creates a function
that adds whatever number x it receives to n.
Of course, this is a small example of what function can do.
Dynamically created functions is a feature that all functional
languages have.
Stefan Ram wrote:
> gugamilare <··········@gmail.com> writes:
>> Oh, I forgot this question. Because in Lisp you can create functions
>> like objects. The canonical example:
>> (defun make-adder (n)
>> (lambda (x) (+ x n)))
>
> class Adder
> { final int n;
> public Adder( final int n ){ this.n = n; }
> public int add( final int x ){ return x + this.n; }}
>
> public class Main
> { public static void main( final java.lang.String[] args )
> { final Adder add0 = new Adder( 0 );
> final Adder add1 = new Adder( 1 );
> java.lang.System.out.println( add0.add( 0 ));
> java.lang.System.out.println( add1.add( 0 )); }}
>
> 0
> 1
>
Aside from the fact that you just beautifully illustrated that Java at
its cleanest would do well in a code obfuscation contest (obfuscation
via bloat), I think you also screwed up the Java: the closest thing to
lambda is an anonymous class.
hth, kzo
On 15 maio, 15:30, Series Expansion <·······@gmail.com> wrote:
> On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
>
> > It does not rely on any internal representation
> > of the functions by some implementation - this would make the code
> > unportable - but it provides a macro that retrieves the function's
> > body to be stored into a file and then restored back again. It is as
> > simple as this: instead of writing (lambda (...) ...) you write (st
> > (lambda (...) ...).
>
> Cool. But why store a function that's there in your code anyway?
>
> Also, the commonplace lisp problem of short names. The name "st" in
> particular isn't particularly clear in meaning, and moreover, you'll
> quickly run out of short names to use in a big enough project anyway.
>
st has its own package - namespace. If you want to use it, you need to
import it into your package. So someone who doesn't want to use st can
use it for something else, even if this someone uses a library that in
turn uses my library. This is how CL package system works. But,
anyway, that is not the point here.
On May 15, 3:29 pm, gugamilare <··········@gmail.com> wrote:
> On 15 maio, 15:30, Series Expansion <·······@gmail.com> wrote:> On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
>
> > > It does not rely on any internal representation
> > > of the functions by some implementation - this would make the code
> > > unportable - but it provides a macro that retrieves the function's
> > > body to be stored into a file and then restored back again. It is as
> > > simple as this: instead of writing (lambda (...) ...) you write (st
> > > (lambda (...) ...).
>
> > Cool. But why store a function that's there in your code anyway?
>
> > Also, the commonplace lisp problem of short names. The name "st" in
> > particular isn't particularly clear in meaning, and moreover, you'll
> > quickly run out of short names to use in a big enough project anyway.
>
> st has its own package - namespace. If you want to use it, you need to
> import it into your package. So someone who doesn't want to use st can
> use it for something else, even if this someone uses a library that in
> turn uses my library. This is how CL package system works. But,
> anyway, that is not the point here.
Oh, Lisp has namespaces already? That's not too bad. Though Java has
had this from the outset:
package foo;
import bar.St;
public class SomethingThatUsesBarsSt {
// ...
}
package quux;
import foo.SomethingThatUsesBarsSt;
public class St {
// My St!
// ... do something with a SomethingThatUsesBarsSt
// ...
}
From: Thomas A. Russ
Subject: Re: macros (was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <ymi8wkxoqvr.fsf@blackcat.isi.edu>
>
> Oh, Lisp has namespaces already? That's not too bad. Though Java has
> had this from the outset:
Well, lisp has onlyl had namespaces for about 3 times as long as Java
has EXISTED.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 15, 8:03 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > Oh, Lisp has namespaces already? That's not too bad. Though Java has
> > had this from the outset:
>
> Well, lisp has onlyl had namespaces for about 3 times as long as Java
> has EXISTED.
Irrelevant. Relevant is that Java's creators were smart enough to
include them from the outset.
On May 15, 8:30 pm, Series Expansion <·······@gmail.com> wrote:
> On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
>
> > It does not rely on any internal representation
> > of the functions by some implementation - this would make the code
> > unportable - but it provides a macro that retrieves the function's
> > body to be stored into a file and then restored back again. It is as
> > simple as this: instead of writing (lambda (...) ...) you write (st
> > (lambda (...) ...).
>
> Cool. But why store a function that's there in your code anyway?
>
> Also, the commonplace lisp problem of short names. The name "st" in
> particular isn't particularly clear in meaning, and moreover, you'll
> quickly run out of short names to use in a big enough project anyway.
>
> > In Java I am pretty sure this isn't conceivable because
>
> > 1) Java does not have dynamically created functions (or am I wrong?)
> > 2) Java Code is not an easy manipulable data
> > 3) Java doesn't have macros.
>
> > As you can see, macros not only provide a way to make your
> > applications shorter or more readable, but they also make it possible
> > to do somethings that otherwise couldn't be done.
>
> Java is Turing-complete, so it can probably be done.
Ahh, the good old Turing argument! By the same line of reasoning,
since Common Lisp is Turing-complete too, you can do in it everything
you do in a statically typed language, and the two are just
equivalent :)
The point here is not what is theoretically possible, but what is
doable reasonably with the language by a human being.
> You can certainly implement an interpreter in Java that can save and
> load its code. This also lets the function be created at run-time from
> other data or user-input.
>
> You can also monkey about with ClassLoader and byte arrays and
> bytecode, or (since Java 6) with ClassLoader, Compiler, and Strings
> full of Java source code, and make classes on the fly, save them to
> disk (e.g. as .class files), load them, instantiate them (with
> reflection), and invoke them (with reflection, or polymorphically
> through a compile-time-known base class or interface).
>
> So yeah, Java can do it, though it's clunky. And Java can do it with
> "functions" created on the fly, not just some existing one like
> Math.sin(double). In the case of using ClassLoader and eventually
> calling the object via a base class or interface rather than
> reflection, and using a JIT-enabled JVM, it can even run the new
> function with performance rivaling compiled and optimized C code.
Look, I have a concrete proof Java can do what you say and more: it's
called ABCL. It's a CL implementation written in Java. :)
Peace,
Ale
On May 15, 3:44 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 15, 8:30 pm, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
>
> > > It does not rely on any internal representation
> > > of the functions by some implementation - this would make the code
> > > unportable - but it provides a macro that retrieves the function's
> > > body to be stored into a file and then restored back again. It is as
> > > simple as this: instead of writing (lambda (...) ...) you write (st
> > > (lambda (...) ...).
>
> > Cool. But why store a function that's there in your code anyway?
>
> > Also, the commonplace lisp problem of short names. The name "st" in
> > particular isn't particularly clear in meaning, and moreover, you'll
> > quickly run out of short names to use in a big enough project anyway.
>
> > > In Java I am pretty sure this isn't conceivable because
>
> > > 1) Java does not have dynamically created functions (or am I wrong?)
> > > 2) Java Code is not an easy manipulable data
> > > 3) Java doesn't have macros.
>
> > > As you can see, macros not only provide a way to make your
> > > applications shorter or more readable, but they also make it possible
> > > to do somethings that otherwise couldn't be done.
>
> > Java is Turing-complete, so it can probably be done.
>
> Ahh, the good old Turing argument! By the same line of reasoning,
> since Common Lisp is Turing-complete too, you can do in it everything
> you do in a statically typed language, and the two are just
> equivalent :)
>
> The point here is not what is theoretically possible, but what is
> doable reasonably with the language by a human being.
True enough.
With Lisp: blowing your foot off, and metaprogramming most people
apparently don't need.
With Java: getting the job done, and having the compiler catch a
lot of bugs and locate them for you, saving hours of
work tracking down how that Rabbit got into what was
supposed to be a list of Collaborators. (Caveat: Java
still causes headaches when a null gets into a list of
Collaborators, but Java 7 might address that soon.)
On May 15, 10:12 pm, Series Expansion <·······@gmail.com> wrote:
> On May 15, 3:44 pm, Alessio Stalla <·············@gmail.com> wrote:
>
>
>
> > On May 15, 8:30 pm, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 15, 11:11 am, gugamilare <··········@gmail.com> wrote:
>
> > > > It does not rely on any internal representation
> > > > of the functions by some implementation - this would make the code
> > > > unportable - but it provides a macro that retrieves the function's
> > > > body to be stored into a file and then restored back again. It is as
> > > > simple as this: instead of writing (lambda (...) ...) you write (st
> > > > (lambda (...) ...).
>
> > > Cool. But why store a function that's there in your code anyway?
>
> > > Also, the commonplace lisp problem of short names. The name "st" in
> > > particular isn't particularly clear in meaning, and moreover, you'll
> > > quickly run out of short names to use in a big enough project anyway.
>
> > > > In Java I am pretty sure this isn't conceivable because
>
> > > > 1) Java does not have dynamically created functions (or am I wrong?)
> > > > 2) Java Code is not an easy manipulable data
> > > > 3) Java doesn't have macros.
>
> > > > As you can see, macros not only provide a way to make your
> > > > applications shorter or more readable, but they also make it possible
> > > > to do somethings that otherwise couldn't be done.
>
> > > Java is Turing-complete, so it can probably be done.
>
> > Ahh, the good old Turing argument! By the same line of reasoning,
> > since Common Lisp is Turing-complete too, you can do in it everything
> > you do in a statically typed language, and the two are just
> > equivalent :)
>
> > The point here is not what is theoretically possible, but what is
> > doable reasonably with the language by a human being.
>
> True enough.
>
> With Lisp: blowing your foot off, and metaprogramming most people
> apparently don't need.
> With Java: getting the job done, and having the compiler catch a
> lot of bugs and locate them for you, saving hours of
> work tracking down how that Rabbit got into what was
> supposed to be a list of Collaborators. (Caveat: Java
> still causes headaches when a null gets into a list of
> Collaborators, but Java 7 might address that soon.)
I know Java. In fact, I use it every day at work. I don't think it's a
bad language; it has some features (some not well-known) that you
could only dream of in mainstream languages prior to it. And it has a
huge standard library, and many widely used open source libraries for
all sorts of things.
But. Especially in big applications, static typing really shows its
limits. To do some of the things a dynamic language like Lisp allows
easily, Java (and C# and C++ and...) programmers are forced to use
lots of XML and other similar mechanisms. XML is NOT type safe with
respect to Java: if you write an XML configuration for your
application that specifies an object of type X as the dependency of
another one that requires type Y instead, you won't notice until
runtime - exactly like it happens in Lisp. But Lisp is built to deal
with this: for example, you can test functions one by one in Lisp, and
with some compilers statically check declared or derived types; you
can't check for correctness pieces of XML configuration (*) - you must
wait for it to crash at runtime. Believe me, XML configuration is
really a big, important part in the kind of applications I work on.
Another common example are all the kind of non-type-safe "expression
languages" that are used in Java, especially with Web frameworks.
Again, you mistype a dot-notation expression pointing to some deeply
nested property of an object, and you can only detect the error at
runtime. What if it is in a rarely executed code path? Again, with
Lisp if you make a typo when writing a call to a slot accessor, you'll
likely get an undefined function warning at compile time. Who is
safer? ;)
These things and many others derive from an abuse of reflection in
Java. Unfortunately, indiscriminate use of reflection is the only tool
Java programmers (and especially library writers) have for writing
more dynamic code.
I'm not saying Java is unusable and should be dropped tomorrow. Just
that maybe it's not the be-all, end-all of programming languages ;)
Alessio
(*) I'm not speaking of checking the XML itself - I know of XSD
schemas, DTDs and the likes. I mean checking it *with respect to the
Java code* it will execute when interpreted.
On May 15, 5:00 pm, Alessio Stalla <·············@gmail.com> wrote:
> I know Java. In fact, I use it every day at work. I don't think it's a
> bad language; it has some features (some not well-known) that you
> could only dream of in mainstream languages prior to it. And it has a
> huge standard library, and many widely used open source libraries for
> all sorts of things.
Now, is there any Lisp implementation for which this is true?
Particularly, as broad coverage of common requirements (GUIs,
networking, threading, math) as Java has in standard/widely-used
libraries?
> But. Especially in big applications, static typing really shows its
> limits.
You're kidding. Especially in BIG applications? But we've just been
through why the static typing overhead is a smaller proportion of the
work the bigger the app, and the bug-finding savings bigger.
> [a whole lot of some tangent about XML]
>
> I'm not saying Java is unusable and should be dropped tomorrow. Just
> that maybe it's not the be-all, end-all of programming languages ;)
I'm not sure any of them are.
Don't knock having the compiler check for type errors until you've
tried it.
On May 16, 5:43 am, Series Expansion <·······@gmail.com> wrote:
> On May 15, 5:00 pm, Alessio Stalla <·············@gmail.com> wrote:
>
> > I know Java. In fact, I use it every day at work. I don't think it's a
> > bad language; it has some features (some not well-known) that you
> > could only dream of in mainstream languages prior to it. And it has a
> > huge standard library, and many widely used open source libraries for
> > all sorts of things.
>
> Now, is there any Lisp implementation for which this is true?
> Particularly, as broad coverage of common requirements (GUIs,
> networking, threading, math) as Java has in standard/widely-used
> libraries?
Commercial implementations offer their libraries, and they do cover
the areas you mentioned. There are many open source libraries too, but
we're still far from the "grab from the shelf" philosophy Java strives
to achieve (and manages to, often ;). But, the library situation in
Lisp is in fact better than most people think, especially with respect
to the size of the Lisp community, which is tiny compared to Java.
> > But. Especially in big applications, static typing really shows its
> > limits.
>
> You're kidding. Especially in BIG applications? But we've just been
> through why the static typing overhead is a smaller proportion of the
> work the bigger the app, and the bug-finding savings bigger.
No, I'm not talking about the overhead of static typing here. The
"tangent about XML" you removed from the quotation was an example of
how, in big applications, Java programmers often resort to sub-optimal
means (like very complex XML configuration files) only to achieve
something they have from the start in dynamic languages - namely, more
dynamism, or if you prefer, less constraint from static types. And by
doing so they lose the benefit of static typing, AND do not have a
strong enough support for dynamic typing that would compensate for
that loss (like it happens in Lisp and other languages).
As an example, try using Spring and voluntarily mistype the name of a
bean's property: you'll only see it fail at runtime. In Lisp the same
would happen, but you would use Lisp and not XML: most Lisp compilers
issue a warning about calls undefined functions (such as a mistyped
accessor); plus in Lisp you can test in isolation the single function
or macro where you have made the typo, and catch it early.
My point is that sooner or later at least some dynamic language
features are inevitably needed (especially in big applications). If
you have a language that is natively dynamic you have means to deal
with the negative side of the dynamism. If you emulate those features
on a statically typed language, you'll get worse implementation of the
same features and less tools to cope with type errors and other kinds
of errors at runtime.
Just my opinion, of course...
Alessio
> > [a whole lot of some tangent about XML]
>
> > I'm not saying Java is unusable and should be dropped tomorrow. Just
> > that maybe it's not the be-all, end-all of programming languages ;)
>
> I'm not sure any of them are.
>
> Don't knock having the compiler check for type errors until you've
> tried it.
On May 16, 4:12 am, Alessio Stalla <·············@gmail.com> wrote:
> On May 16, 5:43 am, Series Expansion <·······@gmail.com> wrote:
>
> > On May 15, 5:00 pm, Alessio Stalla <·············@gmail.com> wrote:
>
> > > I know Java. In fact, I use it every day at work. I don't think it's a
> > > bad language; it has some features (some not well-known) that you
> > > could only dream of in mainstream languages prior to it. And it has a
> > > huge standard library, and many widely used open source libraries for
> > > all sorts of things.
>
> > Now, is there any Lisp implementation for which this is true?
> > Particularly, as broad coverage of common requirements (GUIs,
> > networking, threading, math) as Java has in standard/widely-used
> > libraries?
>
> Commercial implementations offer their libraries, and they do cover
> the areas you mentioned.
And free implementations?
> we're still far from the "grab from the shelf" philosophy Java strives
> to achieve (and manages to, often ;).
Oh. How disappointing.
> > > But. Especially in big applications, static typing really shows its
> > > limits.
>
> > You're kidding. Especially in BIG applications? But we've just been
> > through why the static typing overhead is a smaller proportion of the
> > work the bigger the app, and the bug-finding savings bigger.
>
> No, I'm not talking about the overhead of static typing here. The
> "tangent about XML" you removed from the quotation was an example of
> how, in big applications, Java programmers often resort to sub-optimal
> means (like very complex XML configuration files) only to achieve
> something they have from the start in dynamic languages - namely, more
> dynamism, or if you prefer, less constraint from static types.
Getting rid of types to solve this is throwing out the baby with the
bathwater.
> in Lisp you can test in isolation the single function
> or macro where you have made the typo, and catch it early.
Says someone who evidently has never heard of junit.
On May 16, 11:37 pm, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:12 am, Alessio Stalla <·············@gmail.com> wrote:
[...]
> > No, I'm not talking about the overhead of static typing here. The
> > "tangent about XML" you removed from the quotation was an example of
> > how, in big applications, Java programmers often resort to sub-optimal
> > means (like very complex XML configuration files) only to achieve
> > something they have from the start in dynamic languages - namely, more
> > dynamism, or if you prefer, less constraint from static types.
> Getting rid of types to solve this is throwing out the baby with the
> bathwater.
It's an awfully good thing that Common Lisp didn't do that, then,
isn't it?
Cheers, Pillsy
[...]
Pillsy wrote:
> On May 16, 11:37 pm, Series Expansion <·······@gmail.com> wrote:
>> On May 16, 4:12 am, Alessio Stalla <·············@gmail.com> wrote:
> [...]
>>> No, I'm not talking about the overhead of static typing here. The
>>> "tangent about XML" you removed from the quotation was an example of
>>> how, in big applications, Java programmers often resort to sub-optimal
>>> means (like very complex XML configuration files) only to achieve
>>> something they have from the start in dynamic languages - namely, more
>>> dynamism, or if you prefer, less constraint from static types.
>
>> Getting rid of types to solve this is throwing out the baby with the
>> bathwater.
>
> It's an awfully good thing that Common Lisp didn't do that, then,
> isn't it?
Sure is!
--
Lew
On May 17, 1:00 pm, Lew <·····@lewscanon.com> wrote:
> Pillsy wrote:
> > On May 16, 11:37 pm, Series Expansion <·······@gmail.com> wrote:
> >> Getting rid of types to solve this is throwing out the baby with the
> >> bathwater.
>
> > It's an awfully good thing that Common Lisp didn't do that, then,
> > isn't it?
>
> Sure is!
But it did, more or less. The only types in the language are cons
cells, integers, maybe a few other numeric types, strings, symbols,
and nil, and variables lack types. Lisp doesn't even have a true
boolean type, using the nil value "nil" and the symbol "t" instead. A
result of this is that if a variable can hold a boolean, it can hold a
heterogeneous variety of objects; certainly it could also hold the
symbol "foobar" (or else not be able to hold "t"). Yuck!
On May 16, 11:45 pm, Pillsy <·········@gmail.com> wrote:
> On May 16, 11:37 pm, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 4:12 am, Alessio Stalla <·············@gmail.com> wrote:
> [...]
> > > No, I'm not talking about the overhead of static typing here. The
> > > "tangent about XML" you removed from the quotation was an example of
> > > how, in big applications, Java programmers often resort to sub-optimal
> > > means (like very complex XML configuration files) only to achieve
> > > something they have from the start in dynamic languages - namely, more
> > > dynamism, or if you prefer, less constraint from static types.
> > Getting rid of types to solve this is throwing out the baby with the
> > bathwater.
>
> It's an awfully good thing that Common Lisp didn't do that, then,
> isn't it?
But it more or less did. The only types in Common Lisp appear to be
cons cells, nil, integers, and one or two other numeric types, and as
near as I can tell, variables and arguments are untyped anyway, so the
compiler won't bat an eye no matter what you assign to them.
Even Smalltalk appears to have more types, though it too is dynamic.
Variables and arguments lack types there, too, but all objects have a
fixed type from birth. CLOS is built on top of Lisp rather than built
*into* Lisp, by contrast, so its objects' classes are not something
the compiler can really know much about. This also precludes some
types of optimization, since all dispatch has to be done at run-time.
It is not dissimilar from how tables of function pointers in C can be
used to emulate object-oriented dispatch, but will not receive
optimizations from the C compiler that a C++ compiler would make to
its vtables. The C++ compiler both knows about the latter, and has
control over their layout.
A similar performance difference exists between C++ garbage collection
implementations and Java's. A C++ gc can't make any assumptions about
program data and object layout: every sequence of four bytes (every
aligned sequence, or sequence of eight bytes, on some architectures)
is potentially a pointer that should prevent its target from being
collected. A JVM's collector gets to benefit from the JVM knowing
exactly how objects are structured and laid out in memory; it can know
exactly what is really a pointer and what is some other kind of data.
This last at first seems to be about garbage collection, and about how
building something into the language and its tools instead of building
it on top of the language can create optimization opportunities, but
if you look closely you may note that it's actually also about types:
the JVM's collector can distinguish among pointers, ints, floats,
bools, doubles, longs, and shorts, whereas a C++ collector cannot,
because there's more run-time type information and because the
knowledge of this type information is built into the language tools,
compiler, and runtime rather than being up to the programmer's whims.
Lisp's garbage collector likewise can presumably distinguish pointers
from values and thus exhibit the efficiency of Java's. Unfortunately,
its object system is another story, to hear you guys tell it, because
it's implemented on top of the language, like object-oriented C code,
rather than built into the language, like C++ or Java objects. The one
difference being that CLOS was essentially made into a library, unlike
faking vtables in C, which tends to be done manually. That difference
may make CLOS easier to use, but it will not make it easier for the
compiler to optimize.
On May 17, 5:37 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:12 am, Alessio Stalla <·············@gmail.com> wrote:
>
>
>
> > On May 16, 5:43 am, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 15, 5:00 pm, Alessio Stalla <·············@gmail.com> wrote:
>
> > > > I know Java. In fact, I use it every day at work. I don't think it's a
> > > > bad language; it has some features (some not well-known) that you
> > > > could only dream of in mainstream languages prior to it. And it has a
> > > > huge standard library, and many widely used open source libraries for
> > > > all sorts of things.
>
> > > Now, is there any Lisp implementation for which this is true?
> > > Particularly, as broad coverage of common requirements (GUIs,
> > > networking, threading, math) as Java has in standard/widely-used
> > > libraries?
>
> > Commercial implementations offer their libraries, and they do cover
> > the areas you mentioned.
>
> And free implementations?
I've already answered you. There's lots of free (as in freedom and as
in beer) CL libraries, but sometimes they require to - gasp! - spend a
little time reading their documentation and installing them, instead
of clicking "add library X" in some IDE. But this has nothing to do
with languages and much to do with community size and amount of
invested money. (Just to clarify, I do find it easier to install
libraries in Java, but I've never had any serious problems installing
a CL library, either. Many of them are actually packaged in Linux
distros, for example, and you can install them just as you install any
other library).
> > we're still far from the "grab from the shelf" philosophy Java strives
> > to achieve (and manages to, often ;).
>
> Oh. How disappointing.
>
> > > > But. Especially in big applications, static typing really shows its
> > > > limits.
>
> > > You're kidding. Especially in BIG applications? But we've just been
> > > through why the static typing overhead is a smaller proportion of the
> > > work the bigger the app, and the bug-finding savings bigger.
>
> > No, I'm not talking about the overhead of static typing here. The
> > "tangent about XML" you removed from the quotation was an example of
> > how, in big applications, Java programmers often resort to sub-optimal
> > means (like very complex XML configuration files) only to achieve
> > something they have from the start in dynamic languages - namely, more
> > dynamism, or if you prefer, less constraint from static types.
>
> Getting rid of types to solve this is throwing out the baby with the
> bathwater.
Yet this is precisely what happens when you use any kind of XML-based
configuration in Java and other languages. Need I mention some
examples? Spring's application context, web.xml webapp descriptor,
faces-config.xml, tld files, Facelet taglibs, and the list goes on and
on. Any decently-sized enterprise application will use at least some
of them, and probably others. All of these files refer (using
strings!) to names of classes, or even properties and methods of those
classes, and combine them *without* any kind of static type checking,
since XML is not considered to be source code and thus not compiled.
If you say that programmers should get rid of these non-statically-
typed tools and always use statically-typed Java for everything,
that's fine - but I doubt you'll convince any Java programmer of this.
So I'm just saying that what in Spring you write as
<bean id="someObject" class="com.mypackage.MyClass">
<property name="someProperty" ref="someOtherObject" />
</bean>
in Lisp - without using any library - you'll simply write as
(defvar *some-object*
(make-instance 'my-package:my-class
:some-property *some-other-object*))
and *compile* and load the file with this code *at runtime*, getting
warnings or errors if you have made mistakes. This covers the most
common and simple use of Spring, I repeat using only standard CL -
that is defining a bunch of "singleton" (in Spring parlance) objects
and combining them, and being able to change their classes without
recompiling the whole application. If you want something more
sophisticated, you'll need a library, which hasn't been written yet
(probably because there's not much need of it in Lisp). You could try
and write such a library, it could be a great way to learn some
Lisp ;)
> > in Lisp you can test in isolation the single function
> > or macro where you have made the typo, and catch it early.
>
> Says someone who evidently has never heard of junit.
I know JUnit and regularly use it - for testing Java code. I'm not
aware of how JUnit could test fragments of XML.
Alessio
PS: Spring is only an example. You can easily replace other kinds of
XML-based configurations using bare Lisp or a little DSL on top of it.
For example, take a loot at how Hunchentoot - a Lisp web server -
registers functions to be executed when a request matches a certain
pattern, just like web.xml does with servlets:
http://www.weitz.de/hunchentoot/#request-dispatch
Series Expansion wrote:
>> Says someone who evidently has never heard of junit [sic].
Alessio Stalla wrote:
> I know JUnit and regularly use it - for testing Java code. I'm not
> aware of how JUnit could test fragments of XML.
My language is better!
No, *my* language is better!
Is not!
Is, too!
Nyaah, nyaah!
--
Lew
On May 17, 1:02 pm, Lew <·····@lewscanon.com> wrote:
> Alessio Stalla wrote:
> > Series Expansion wrote:
> >> Says someone who evidently has never heard of junit.
> > I know JUnit and regularly use it - for testing Java code. I'm not
> > aware of how JUnit could test fragments of XML.
It should be apparent that a JUnit test could be written that tests
the Java code that loads the XML and reports errors. Such a test will
catch errors in the XML as well as in the particular Java code that
interprets it.
> My language is better!
>
> No, *my* language is better!
>
> Is not!
>
> Is, too!
>
> Nyaah, nyaah!
Perhaps you should shut off the computer and duck. I think that's a
teacher coming down the hall towards the computer room, and he's
probably looking for you. If you are captured, you will probably face
detention or worse at the hands of the principal.
On May 17, 4:53 am, Alessio Stalla <·············@gmail.com> wrote:
> On May 17, 5:37 am, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 4:12 am, Alessio Stalla <·············@gmail.com> wrote:
> > > Commercial implementations offer their libraries, and they do cover
> > > the areas you mentioned.
>
> > And free implementations?
>
> I've already answered you.
You had indicated that free implementations of CL itself existed
(though I remain unaware of any Windows ones), but I don't recall
seeing anything about their library feature-coverage until now.
[snip encouraging information regarding library coverage]
> > > The "tangent about XML" you removed from the quotation was an example
> > > of how, in big applications, Java programmers often resort to sub-optimal
> > > means (like very complex XML configuration files) only to achieve
> > > something they have from the start in dynamic languages - namely, more
> > > dynamism, or if you prefer, less constraint from static types.
>
> > Getting rid of types to solve this is throwing out the baby with the
> > bathwater.
>
> Yet this is precisely what happens when you use any kind of XML-based
> configuration in Java and other languages.
I have not claimed that those kludges are superior; indeed they
clearly are not. What is truly needed is going to be quite different
from either.
> Any decently-sized enterprise application will use at least some
> of them, and probably others. All of these files refer (using
> strings!) to names of classes, or even properties and methods of those
> classes, and combine them *without* any kind of static type checking,
> since XML is not considered to be source code and thus not compiled.
Perhaps the solution is a standardized script interpreter in Java that
can call into Java and that inherits Java's type system; such
configuration files could then be replaced by scripts that this
interpreter would run. The interpreter would report any type errors in
the scripts immediately on parsing them, so the scripts could be
checked by running a unit test that simply invoked the interpreter
class's "load script" function without calling any entry points within
the script.
Of course, you'd get the reverse problem, no type checking of Java
calls into these scripts, but it's a much smaller problem since the
typical case would replace a long XML file with many Java bindings
(unchecked) and a call to an XML interpreting function to a long
script with many Java bindings (checked) and a call to a
"configure_server" entry point (unchecked). One unchecked call instead
of many. If it was specifically for this sort of configuration task,
it could even be designed so that scripts just had one entry point
with no arguments (from Java) and the call pattern was just
Interpreter i = Interpreter.load(scriptFile); i.run(); and nothing at
all unchecked now.
Then again, I don't see why there isn't a tool to type-check the XML
file against the Java codebase, or use of unit tests to use the XML in
the Java code in a mock server environment to reveal any problems pre-
deployment.
> If you say that programmers should get rid of these non-statically-
> typed tools and always use statically-typed Java for everything,
> that's fine
I don't.
> So I'm just saying that what in Spring you write as
>
> <bean id="someObject" class="com.mypackage.MyClass">
> <property name="someProperty" ref="someOtherObject" />
> </bean>
I don't see why tools can't easily type-check this, for instance by
checking that com.mypackage.MyClass exists, has the appropriate
getters and setters, and these have the appropriate type (the class
named in the "class=" attribute of the bean tag with
"id=someOtherObject").
> in Lisp
In Lisp, you'll have no types at all on any of this stuff, so while it
may not be worse it isn't better either.
> (defvar *some-object*
> (make-instance 'my-package:my-class
> :some-property *some-other-object*))
>
> and *compile* and load the file with this code *at runtime*, getting
> warnings or errors if you have made mistakes.
There's no reason that the Java code that processes the XML files
can't likewise generate warnings or errors at runtime. Indeed, I
expect it must, throwing various reflection exceptions like
NoSuchMethodError, depending on the exact nature of the problem.
> > > in Lisp you can test in isolation the single function
> > > or macro where you have made the typo, and catch it early.
>
> > Says someone who evidently has never heard of junit.
>
> I know JUnit and regularly use it - for testing Java code. I'm not
> aware of how JUnit could test fragments of XML.
I was responding to the erroneous implication that something in Java
precluded testing single functions in isolation.
Regarding XML, see above -- if one had JUnit tests for the system as a
whole (the Java AND the XML) these could easily include checking that
the XML works.
More generally, I don't see a timing advantage to the error messages
on either side here, let alone on Lisp's. While technically the Lisp
errors occur "at compile time", this is only because it compiles the
bean info file when it loads it whereas the Java analogue does not
compile the XML file. Both will spit out corresponding errors at the
same point: when they get around to loading the corresponding bean
info files. Neither gives earlier warning of trouble than the other.
>
> Alessio
>
> PS: Spring is only an example. You can easily replace other kinds of
> XML-based configurations using bare Lisp or a little DSL on top of it.
> For example, take a loot at how Hunchentoot - a Lisp web server -
> registers functions to be executed when a request matches a certain
> pattern, just like web.xml does with servlets:http://www.weitz.de/hunchentoot/#request-dispatch
On May 17, 1:00 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > Says someone who evidently has never heard of junit [sic].
>
> Spelling counts.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
(The attempt to misdirect this particular post away from
comp.lang.java.programmer is especially odd, seeing as it's primarily
about Java.)
Series Expansion wrote:
> On May 17, 1:00 pm, Lew <·····@lewscanon.com> wrote:
>> Series Expansion wrote:
>>> Says someone who evidently has never heard of junit [sic].
>> Spelling counts.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew".
Stating that spelling count is not a personal attack.
Maybe you should read what you reply to.
> (The attempt to misdirect this particular post away from
> comp.lang.java.programmer is especially odd, seeing as it's primarily
> about Java.)
I am sure a lot of cljp'ers would have been happy not to see it !
Arne
On May 19, 7:32 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 17, 1:00 pm, Lew <·····@lewscanon.com> wrote:
> >> Series Expansion wrote:
> >>> Says someone who evidently has never heard of junit [sic].
> >> Spelling counts.
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, "Lew".
>
> Stating that spelling count
does not constitute a rational argument in favor of either Lisp or
Java.
> Maybe you should read what you reply to.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
> > (The attempt to misdirect this particular post away from
> > comp.lang.java.programmer is especially odd, seeing as it's primarily
> > about Java.)
>
> I am sure a lot of cljp'ers would have been happy not to see it !
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
On 15 May, 21:12, Series Expansion <·······@gmail.com> wrote:
> On May 15, 3:44 pm, Alessio Stalla <·············@gmail.com> wrote:
>
> > The point here is not what is theoretically possible, but what is
> > doable reasonably with the language by a human being.
>
> True enough.
>
> With Lisp: blowing your foot off, and metaprogramming most people
> apparently don't need.
You can blow your foot off with pretty much every language. You
seem convinced that macros make things much more dangerous
but this hasn't been the experience of Lisp programmers or they
would have abandoned macros. Note that core parts of Lisp
are implemented with macros and it hasn't caused anyone's foot
to blow off.
Regarding whether metaprogramming is needed then strictly
speaking it is not. Strictly speaking one doesn't even need a
high level language , people have written useful programmes
in assembly. But metaprogramming offers great power and
convenience without any great dangers in *** languages which
have good support for it ***. Most languages do not and that's
the reason most programmers do not use it.
--
If there really exist any apostate ex-Randroids, god damn I'd
love to meet them. Apparently, though, it's like a black hole,
i.e., once you go there, you don't come back - ever.
http://www.iidb.org/vbb/showthread.php?p=2704978#post2704978
On May 15, 5:02 pm, Spiros Bousbouras <······@gmail.com> wrote:
> On 15 May, 21:12, Series Expansion <·······@gmail.com> wrote:
>
> > On May 15, 3:44 pm, Alessio Stalla <·············@gmail.com> wrote:
>
> > > The point here is not what is theoretically possible, but what is
> > > doable reasonably with the language by a human being.
>
> > True enough.
>
> > With Lisp: blowing your foot off, and metaprogramming most people
> > apparently don't need.
>
> You can blow your foot off with pretty much every language. You
> seem convinced that macros make things much more dangerous
> but this hasn't been the experience of Lisp programmers or they
> would have abandoned macros.
That's interesting. It HAS been the experience of C programmers. And
they haven't abandoned macros; they're still alive and well, if used
sparingly.
> Note that core parts of Lisp
> are implemented with macros and it hasn't caused anyone's foot
> to blow off.
Core parts of Lisp are well-tested, I assume.
Five-minute quick hacks are another story, and unfortunately, it's in
the nature of macros to potentially interact with practically the
entire code base.
If you doubt that, think for two seconds about the consequences of
taking any very large C project and sticking this at the top of the
most commonly-included header file:
#define malloc(x) 1
The horror of it is, it will probably actually compile (at least if
the malloc.h header is seen before the one you edited) but it will
bomb with SIGSEGV or otherwise blow up spectacularly when run.
And that's macro mischief in a "safe" (well, type-safe) language.
I can only begin to imagine what might happen (even by accident) with
a macro in a dynamically-typed language.
With a badly-written function, the code that uses that function has
problems. A badly-written macro can throw a spanner into the works
just about *anywhere*. Or, sometimes, just about *everywhere*.
> Regarding whether metaprogramming is needed then strictly
> speaking it is not. Strictly speaking one doesn't even need a
> high level language , people have written useful programmes
> in assembly.
Interesting that people mostly prefer C and Java to assembly, but
mostly prefer C and Java to Lisp, then ...
On May 15, 11:54 pm, Series Expansion <·······@gmail.com> wrote:
> On May 15, 5:02 pm, Spiros Bousbouras <······@gmail.com> wrote:
[...]
> > You can blow your foot off with pretty much every language. You
> > seem convinced that macros make things much more dangerous
> > but this hasn't been the experience of Lisp programmers or they
> > would have abandoned macros.
> That's interesting. It HAS been the experience of C programmers. And
> they haven't abandoned macros; they're still alive and well, if used
> sparingly.
Lisp macros are much less dangerous than C macros, they're much more
powerful, and they're much easier to write. For one thing, Lisp macros
are defined within a specific namespace, just like Lisp classes,
functions, variables and all the rest. For another, they work on the
syntax tree, instead of just doing text substitution.
There's no equivalent of your
#define malloc(x) 1
example, because there's no support for changing the definitions of
standard functions or macros.
Cheers,
Pillsy
[...]
On May 16, 12:31 am, Pillsy <·········@gmail.com> wrote:
> On May 15, 11:54 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 15, 5:02 pm, Spiros Bousbouras <······@gmail.com> wrote:
> > > You can blow your foot off with pretty much every language. You
> > > seem convinced that macros make things much more dangerous
> > > but this hasn't been the experience of Lisp programmers or they
> > > would have abandoned macros.
> > That's interesting. It HAS been the experience of C programmers. And
> > they haven't abandoned macros; they're still alive and well, if used
> > sparingly.
>
> Lisp macros are much less dangerous than C macros, they're much more
> powerful, and they're much easier to write.
Wow, This is like hearing some air force dude say "Nukes are much less
dangerous than C-4, they're much more powerful, and they're much
easier to use".
Be afraid. Be very afraid.
> For another, they work on the syntax tree, instead of just doing
> text substitution.
Sounds like they're less powerful and slightly less dangerous then,
rather than more powerful and a lot less dangerous.
On May 16, 2:42 pm, Series Expansion <·······@gmail.com> wrote:
> On May 16, 12:31 am, Pillsy <·········@gmail.com> wrote:
[...]
> > Lisp macros are much less dangerous than C macros, they're much more
> > powerful, and they're much easier to write.
> Wow, This is like hearing some air force dude say "Nukes are much less
> dangerous than C-4, they're much more powerful, and they're much
> easier to use".
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?
They let you do what you want in a much more structured way than their
C equivalents, and allow you to use familiar language constructs to do
it instead of introducing an entirely different (and pitiful)
language. How is it surprising that this is both safer and more
powerful?
Cheers,
Pillsy
On May 16, 2:59 pm, Pillsy <·········@gmail.com> wrote:
> On May 16, 2:42 pm, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 12:31 am, Pillsy <·········@gmail.com> wrote:
> [...]
> > > Lisp macros are much less dangerous than C macros, they're much more
> > > powerful, and they're much easier to write.
> > Wow, This is like hearing some air force dude say "Nukes are much less
> > dangerous than C-4, they're much more powerful, and they're much
> > easier to use".
>
> 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.
On May 17, 12:02 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 2:59 pm, Pillsy <·········@gmail.com> wrote:
> > On May 16, 2:42 pm, Series Expansion <·······@gmail.com> wrote:
[...]
> > > Wow, This is like hearing some air force dude say "Nukes are much less
> > > dangerous than C-4, they're much more powerful, and they're much
> > > easier to use".
> > 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.
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 wrote:
> Series Expansion <·······@gmail.com> wrote:
>> 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.
So both Lisp and Java are superior to C!
--
Lew
Lew <·····@lewscanon.com> writes:
> Pillsy wrote:
>> Series Expansion <·······@gmail.com> wrote:
>>> 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.
>
> So both Lisp and Java are superior to C!
At least we can agree on that! :-)
--
__Pascal Bourguignon__
On May 17, 1:03 pm, Lew <·····@lewscanon.com> wrote:
> Pillsy wrote:
> > Series Expansion <·······@gmail.com> wrote:
> >> 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
But it does, as I have already explained.
> >> 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.
>
> So both Lisp and Java are superior to C!
Java certainly is, except for programming low-level kernel-mode code
for which raw access to the hardware is required, or bridges between
Java and operating system APIs.
(The attempt to misdirect this particular post away from
comp.lang.java.programmer is especially odd, since it is explicitly
partly about Java.)
On May 19, 10:27 pm, Series Expansion <·······@gmail.com> wrote:
> On May 17, 1:03 pm, Lew <·····@lewscanon.com> wrote:
>
> > Pillsy wrote:
> > > Series Expansion <·······@gmail.com> wrote:
> > >> 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
>
> But it does, as I have already explained.
>
> > >> 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.
>
> > So both Lisp and Java are superior to C!
>
> Java certainly is, except for programming low-level kernel-mode code
> for which raw access to the hardware is required, or bridges between
> Java and operating system APIs.
>
> (The attempt to misdirect this particular post away from
> comp.lang.java.programmer is especially odd, since it is explicitly
> partly about Java.)
Series, did you see my post explaining gensyms? It's here
http://groups.google.com/group/comp.lang.lisp/msg/675547670bee692b?hl=en
Please read it. I really do think it'll help you understand how what
truly is impossible in C-style macros, is possible in Lisp macros.
By the way, Series, I'm under legal drinking age. SO?
If I can make a clear explanation, does my age matter?
Or, for that matter, if I just rant and rave and ignore what people
say -- does my age matter?
Those are rhetorical questions. Just please read the post about using
GENSYM in Lisp macros.
On 19 maio, 17:49, Adlai <·········@gmail.com> wrote:
> Series, did you see my post explaining gensyms?
Clearly he didn't. He is still reading posts from 2 days ago now, and
you have just written yours. The last post he replied is from 1pm two
days ago, and he is replying all of them in order, even the flammatory
pointless one-liners. It will take him at least a week until he
finally reaches your post. And even when he reads it, I believe he
will give you more excuses like always (What about non-moderate users,
will they know how to do this? What about Lisp data types? Namespace?
Classpaths? Bla bla bla bla...).
He will drive you nuts, he will make you explain to him every single
detail about Common Lisp and Emacs while still refusing to learn, each
explanation more than three times for each detail (by now he has
already read at least 5 posts talking about each of the subjects:
gensyms, Emacs windowing, generic functions and packages; and he
clearly didn't understand any single of those yet). If he wanted to
learn, he would read the book Practical Common Lisp which free links
we provided him more than once (about 5 times as well?), and PCL is
much shorter and easier to understand than this thread enormous
thread, isn't it?
Whenever he sees that he is wrong about something he just invents an
excuse on something else he clearly don't have a clue about, and he
won't accept a simple "Didn't you realize you don't have enough
knowledge in Lisp to criticize Lisp?" - he will say that you are
making "personal attacks". Not to mention the possibility that he
already knows about the language and that he is wasting our time on
purpose (as Lew suggested). It is just pointless.
I'm sorry if I am insisting on this subject, but just let it go. It
doesn't matter anyway. If he doesn't like Lisp it's his problem.
gugamilare wrote:
> I'm sorry if I am insisting on this subject, but just let it go. It
> doesn't matter anyway. If he doesn't like Lisp it's his problem.
And Java's problem since we are stuck with him.
Arne
On May 19, 7:29 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> gugamilare wrote:
> > I'm sorry if I am insisting on this subject, but just let it go. It
> > doesn't matter anyway. If he doesn't like Lisp it's his problem.
>
> And Java's problem since we are stuck with him.
Incorrect. Nowhere have I claimed to dislike Lisp. Dislike of Lisp is
not a problem in need of correcting. Nor am I a problem in need of
correcting.
Arne, you are being exceptionally rude. Please desist.
On May 19, 5:37 pm, gugamilare <··········@gmail.com> wrote:
> On 19 maio, 17:49, Adlai <·········@gmail.com> wrote:
>
> > Series, did you see my post explaining gensyms?
>
> Clearly he didn't.
Incorrect.
> He is still reading posts from 2 days ago now, and
> you have just written yours. The last post he replied is from 1pm two
> days ago, and he is replying all of them in order, even the flammatory
> pointless one-liners. It will take him at least a week until he
> finally reaches your post.
Also incorrect. As can be seen from the post headers of his post and
this post I am currently writing, it took less than half that.
> And even when he reads it, I believe he
> will give you more excuses like always (What about non-moderate users,
> will they know how to do this? What about Lisp data types? Namespace?
> Classpaths? Bla bla bla bla...).
That, too, was incorrect. Instead, I discovered Adlai's post to be
about macros being able to allocate storage away from existing
objects, hardly a revolutionary feature. A hypothetical macro
preprocessor for Java could do this, by having the macro expand to
code containing the "new" keyword. What neither could do is devise a
local variable name guaranteed not to be in use in any enclosing
scope, which the compiler would subsequently be guaranteed to resolve
to a unique stack offset.
> He will drive you nuts, he will make you explain to him every single
> detail about Common Lisp and Emacs while still refusing to learn
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, nor in favor of either emacs or
Eclipse, gugamilare.
> he clearly didn't understand any single of those yet.
Incorrect.
> Whenever he sees that he is wrong about something
That has not happened thus far in this thread, so you have no data
from which you could draw any inferences about what my behavior would
be in the event of such an unlikely occurrence.
> excuse on something else he clearly don't have a clue about
Personal attack.
> he won't accept a simple "Didn't you realize you don't have enough
Personal attack.
> he will say that you are making "personal attacks".
So long as you continue to mistake statements of unflattering personal
opinions about me for valid arguments against Java or for Lisp, I will
continue to point out that they are not.
> Not to mention the possibility that he
> already knows about the language and that he is wasting our time on
> purpose (as Lew suggested).
Further accusations and personal attacks, unsubstantiated, as always,
by any evidence, and irrelevant, as always, to the issue of Lisp macro
behavior.
> I'm sorry if I am insisting on this subject, but just let it go. It
> doesn't matter anyway. If he doesn't like Lisp it's his problem.
The suggestion that I dislike Lisp is in error. That I criticize it
indicates no such thing. I also have been known to criticize Java, but
I do not dislike Java; rather, I wish to see it improved.
The suggestion that dislike of Lisp constitutes a problem is a more
grievous error. This type of error has led, throughout history, to
many of the worst instances of war, repression, and persecution on
record. Freedom of opinion is an important right in a just and
civilized society.
On May 19, 4:49 pm, Adlai <·········@gmail.com> wrote:
> On May 19, 10:27 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 17, 1:03 pm, Lew <·····@lewscanon.com> wrote:
> > > Pillsy wrote:
> > > > Series Expansion <·······@gmail.com> wrote:
> > > >> 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.
>
> > > So both Lisp and Java are superior to C!
>
> > Java certainly is, except for programming low-level kernel-mode code
> > for which raw access to the hardware is required, or bridges between
> > Java and operating system APIs.
>
> > (The attempt to misdirect this particular post away from
> > comp.lang.java.programmer is especially odd, since it is explicitly
> > partly about Java.)
>
> Series, did you see my post explaining gensyms?
Yes. It failed to prove anything except that Lisp macros could
allocate data that would not collide in memory with preexisting data.
This was irrelevant. The issue is variable name resolution to
referents, at compile time, not whether the referents themselves
collide in main memory at runtime.
You focused on:
t = object1;
u = object1;
being avoided in favor of
t = object1;
u = object2;
The thing that poses a problem is instead
t = object1;
t = object2;
in which two distinct objects, with distinct memory storage, are
created, but a local variable that should remain referring to the
first ends up referring to the second.
> By the way, Series, I'm under legal drinking age.
As I suspected.
> If I can make a clear explanation, does my age matter?
A clear explanation of something unrelated to the problem actually
under discussion is of little value.
> Or, for that matter, if I just rant and rave and ignore what people
> say -- does my age matter?
Emulating "Lew" would not be a recommended course of action, Adlai. I
suggest you emulate someone else instead, perhaps me.
> Those are rhetorical questions. Just please read the post about using
> GENSYM in Lisp macros.
I already have.
On May 17, 1:42 am, Pillsy <·········@gmail.com> wrote:
> On May 17, 12:02 am, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 2:59 pm, Pillsy <·········@gmail.com> wrote:
> > > On May 16, 2:42 pm, Series Expansion <·······@gmail.com> wrote:
> [...]
> > > > Wow, This is like hearing some air force dude say "Nukes are much less
> > > > dangerous than C-4, they're much more powerful, and they're much
> > > > easier to use".
> > > 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.
>
> 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.
On 16 May, 04:54, Series Expansion <·······@gmail.com> wrote:
> On May 15, 5:02 pm, Spiros Bousbouras <······@gmail.com> wrote:
>
> > You can blow your foot off with pretty much every language. You
> > seem convinced that macros make things much more dangerous
> > but this hasn't been the experience of Lisp programmers or they
> > would have abandoned macros.
>
> That's interesting. It HAS been the experience of C programmers. And
> they haven't abandoned macros; they're still alive and well, if used
> sparingly.
So in other words they have reduced their use and adopted a
collection of guidelines for macro usage which bring the danger
down to an acceptable level. And they tend to consider them a
wart. With Lisp there is also a set of guidelines on how to
construct macros but as long as you follow those (and think
carefully when you decide to violate them) you can use macros to
your heart's content hence Lisp programmers have not reduced
their use of macros. And they consider them one of the parts
of the language to be most proud of.
> > Note that core parts of Lisp
> > are implemented with macros and it hasn't caused anyone's foot
> > to blow off.
>
> Core parts of Lisp are well-tested, I assume.
>
> Five-minute quick hacks are another story, and unfortunately, it's in
> the nature of macros to potentially interact with practically the
> entire code base.
No , macros only interact with the code which uses them in much the
same way that functions only interact with code which uses them.
> If you doubt that, think for two seconds about the consequences of
> taking any very large C project and sticking this at the top of the
> most commonly-included header file:
>
> #define malloc(x) 1
>
> The horror of it is, it will probably actually compile (at least if
> the malloc.h header is seen before the one you edited) but it will
> bomb with SIGSEGV or otherwise blow up spectacularly when run.
I expect you would get many warnings about assigning integer to
pointer without a cast.
> And that's macro mischief in a "safe" (well, type-safe) language.
C is not type safe because it has casts but it's besides the
point. Imagine that C didn't have macros. You go on and change
the definition of malloc() and make it do something it's not
supposed to do. Don't you think that your programme would also
crash or even worse corrupt data? Obviously yes so why is it
that macros specifically cause the problem?
Apart from that you give an example where you use a macro in a
silly manner. You cannot extrapolate from that to when you use
macros in a thoughtful manner.
> I can only begin to imagine what might happen (even by accident) with
> a macro in a dynamically-typed language.
>
> With a badly-written function, the code that uses that function has
> problems. A badly-written macro can throw a spanner into the works
> just about *anywhere*. Or, sometimes, just about *everywhere*.
Anywhere the macro is used just like functions. Look, macros are
also functions whose input and output is Lisp code. You seem to
think that if a function's input and output is anything other
than code then it's ok but when the input and output is code
then you reach a whole new level of danger. You don't.
> > Regarding whether metaprogramming is needed then strictly
> > speaking it is not. Strictly speaking one doesn't even need a
> > high level language , people have written useful programmes
> > in assembly.
>
> Interesting that people mostly prefer C and Java to assembly, but
> mostly prefer C and Java to Lisp, then ...
It's interesting but I'm not sure it's relevant. It would be
relevant if we knew that people made their choice on the basis
of macros and their choice was an informed one. I doubt that
either assumption is a true one. Take you for example: you have
strong opinions about macros but I bet you've never written a
single Lisp macro. May I suggest reading chapter 7 of "Practical
Common Lisp"? It can be found at
http://www.gigamonkeys.com/book/macros-defining-your-own.html
I realise that you probably consider it a waste of time to read
about Lisp macros but it's a quick read and if you take the time
you may find that Lisp macros are not as dangerous as you think
they are.
--
Who's your mama?
On 16 May, 06:42, Spiros Bousbouras <······@gmail.com> wrote:
> May I suggest reading chapter 7 of "Practical
> Common Lisp"? It can be found at
> http://www.gigamonkeys.com/book/macros-defining-your-own.html
That would be chapter 8.
On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
> On 16 May, 04:54, Series Expansion <·······@gmail.com> wrote:
> > That's interesting. It HAS been the experience of C programmers. And
> > they haven't abandoned macros; they're still alive and well, if used
> > sparingly.
>
> So in other words they have reduced their use and adopted a
> collection of guidelines for macro usage which bring the danger
> down to an acceptable level.
While you lot apparently just use them in a gung-ho manner until the
sky falls down on you.
> And they consider them one of the parts
> of the language to be most proud of.
I'm sure Ted Bundy's mother was proud of him, even for a while after
everyone else started telling her he was a bad seed.
> > Core parts of Lisp are well-tested, I assume.
>
> > Five-minute quick hacks are another story, and unfortunately, it's in
> > the nature of macros to potentially interact with practically the
> > entire code base.
>
> No
Yes
> macros only interact with the code which uses them in much the
> same way that functions only interact with code which uses them.
The problem is that "the code which uses them" includes any code that
contains the text that triggers the macro and that occurs after the
macro in evaluation by the compiler.
> > If you doubt that, think for two seconds about the consequences of
> > taking any very large C project and sticking this at the top of the
> > most commonly-included header file:
>
> > #define malloc(x) 1
>
> > The horror of it is, it will probably actually compile (at least if
> > the malloc.h header is seen before the one you edited) but it will
> > bomb with SIGSEGV or otherwise blow up spectacularly when run.
>
> I expect you would get many warnings about assigning integer to
> pointer without a cast.
That's still compiling, and it can be made silent easily enough:
#define malloc(x) ((void *)1)
> > And that's macro mischief in a "safe" (well, type-safe) language.
>
> C is not type safe because it has casts
It's type safe compared to Lisp! Though Java is "type safer" than it
is since its casts are tightly regulated, and mis-casts produce a
clean run-time error.
> but it's besides the point. Imagine that C didn't have macros.
> You go on and change the definition of malloc()...
Still not getting it, I see. To change the definition of malloc() one
would edit the source file containing malloc(). Whereas that macro
could be stuck pretty much anywhere and blow things up. Locality of
side effects of code changes is destroyed by macros.
> Obviously yes so why is it that macros specifically cause the
> problem?
The problem with macros that I've been getting it is their inherent
ability to alter the behavior of far-away code from pretty much
anywhere. A function has to be intentionally invoked by some code to
have effect there; a macro has to be coded to operate ON some other
code to have effect there. It's easy to whip up a C macro that affects
all the code that uses strlen() or all the code that uses char *
pointers or turn all the code's floats into doubles. Some of these
uses might be useful. All of them are potential maintenance headaches,
since
1. Someone reading the affected code might assume it does what it
says at face value, and the macro changed that;
2. Even if they know, or suspect, otherwise, finding all the macros
that potentially alter the behavior of a particular bit of code
is an exercise in haystack-needle-finding.
Lisp macros apparently are slightly more limited, having to take the
form of function calls rather than arbitrary code fragments. However,
my example of a destructive C macro was intentionally chosen to adhere
to that restriction and show that that restriction does not
significantly reduce the hazard. At least if you suspect some function
has been replaced or altered by a macro, you can search on the
function's name and find any such macro since the name has to be the
same. Of course, if you suspect some chunk of code has been affected
by a macro, the whole code base must be searched for any macros whose
names match any function names occurring in the affected chunk, which
might mean searching several thousand files for each of several dozen
different names.
It's Tylenol time!
> Apart from that you give an example where you use a macro in a
> silly manner.
It's a bit contrived, but it's not outlandish to imagine it resulting
from an accidental typo hitting "#define mallow" or something.
> You cannot extrapolate from that to when you use
> macros in a thoughtful manner.
Typos are non-thoughtful more or less by definition.
> > With a badly-written function, the code that uses that function has
> > problems. A badly-written macro can throw a spanner into the works
> > just about *anywhere*. Or, sometimes, just about *everywhere*.
>
> Anywhere the macro is used just like functions. Look, macros are
> also functions whose input and output is Lisp code. You seem to
> think that if a function's input and output is anything other
> than code then it's ok but when the input and output is code
> then you reach a whole new level of danger.
No, I think that when an innocent-looking function call may have been
redefined far from either the call site or the (nominal) site of that
function's definition, then code maintenance becomes a hell of a lot
harder.
> > Interesting that people mostly prefer C and Java to assembly, but
> > mostly prefer C and Java to Lisp, then ...
>
> It's interesting but I'm not sure it's relevant.
That's the hallmark of faith-based belief systems: empirical
statistics are irrelevant.
There's no point in arguing further with you, then; it's a corollary
that arguing against someone's faith tends to be useless, as compared
to arguing against someone's erroneous beliefs that are not faith-
based.
> Take you for example: you have strong opinions about macros but
> I bet you've never written a single Lisp macro.
I've written lots of macros, though, in a variety of places and
contexts.
> May I suggest reading chapter 7 of "Practical Common Lisp"?
Don't have it and can't be arsed to blow $40 on something I'll
probably never use, sorry.
On 16 maio, 17:10, Series Expansion <·······@gmail.com> wrote:
> On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
>
> > On 16 May, 04:54, Series Expansion <·······@gmail.com> wrote:
> > > That's interesting. It HAS been the experience of C programmers. And
> > > they haven't abandoned macros; they're still alive and well, if used
> > > sparingly.
>
> > So in other words they have reduced their use and adopted a
> > collection of guidelines for macro usage which bring the danger
> > down to an acceptable level.
>
> While you lot apparently just use them in a gung-ho manner until the
> sky falls down on you.
>
> > And they consider them one of the parts
> > of the language to be most proud of.
>
> I'm sure Ted Bundy's mother was proud of him, even for a while after
> everyone else started telling her he was a bad seed.
>
> > > Core parts of Lisp are well-tested, I assume.
>
> > > Five-minute quick hacks are another story, and unfortunately, it's in
> > > the nature of macros to potentially interact with practically the
> > > entire code base.
>
> > No
>
> Yes
>
> > macros only interact with the code which uses them in much the
> > same way that functions only interact with code which uses them.
>
> The problem is that "the code which uses them" includes any code that
> contains the text that triggers the macro and that occurs after the
> macro in evaluation by the compiler.
>
> > > If you doubt that, think for two seconds about the consequences of
> > > taking any very large C project and sticking this at the top of the
> > > most commonly-included header file:
>
> > > #define malloc(x) 1
>
> > > The horror of it is, it will probably actually compile (at least if
> > > the malloc.h header is seen before the one you edited) but it will
> > > bomb with SIGSEGV or otherwise blow up spectacularly when run.
>
> > I expect you would get many warnings about assigning integer to
> > pointer without a cast.
>
> That's still compiling, and it can be made silent easily enough:
>
> #define malloc(x) ((void *)1)
>
> > > And that's macro mischief in a "safe" (well, type-safe) language.
>
> > C is not type safe because it has casts
>
> It's type safe compared to Lisp! Though Java is "type safer" than it
> is since its casts are tightly regulated, and mis-casts produce a
> clean run-time error.
>
> > but it's besides the point. Imagine that C didn't have macros.
> > You go on and change the definition of malloc()...
>
> Still not getting it, I see. To change the definition of malloc() one
> would edit the source file containing malloc(). Whereas that macro
> could be stuck pretty much anywhere and blow things up. Locality of
> side effects of code changes is destroyed by macros.
Lisp is not different than this. If you define a function, and then a
macro with the same name, it will complain (emit a warning) which an
average Lisp programmer (even beginners) will note and correct it.
Macros are not very different from functions. Whatever problems you
cause with macros, you cause with functions. And, whatever safety
functions provide, functions also provide. You fail to see this
because you NEED DESPERATELY to learn Lisp so you can understand this.
>
> > Obviously yes so why is it that macros specifically cause the
> > problem?
>
> The problem with macros that I've been getting it is their inherent
> ability to alter the behavior of far-away code from pretty much
> anywhere. A function has to be intentionally invoked by some code to
> have effect there; a macro has to be coded to operate ON some other
> code to have effect there. It's easy to whip up a C macro that affects
> all the code that uses strlen() or all the code that uses char *
> pointers or turn all the code's floats into doubles. Some of these
> uses might be useful. All of them are potential maintenance headaches,
> since
This is not the same case as CL. We are not dumbs.
>
> 1. Someone reading the affected code might assume it does what it
> says at face value, and the macro changed that;
> 2. Even if they know, or suspect, otherwise, finding all the macros
> that potentially alter the behavior of a particular bit of code
> is an exercise in haystack-needle-finding.
Believe me when I say, this is not the case with Lisp at all. Things
work differently.
>
> Lisp macros apparently are slightly more limited, having to take the
> form of function calls rather than arbitrary code fragments.
Sorry, but, I don't follow. What is the difference? Arbitrary forms
are arbitrary code fragments. I really don't get it.
> > You cannot extrapolate from that to when you use
> > macros in a thoughtful manner.
>
> Typos are non-thoughtful more or less by definition.
Typos are the programmer's problem, not language's one, just like
infinite loops.
> > Take you for example: you have strong opinions about macros but
> > I bet you've never written a single Lisp macro.
>
> I've written lots of macros, though, in a variety of places and
> contexts.
But not CL macros. They are VERY different. You won't understand that
until you can actually write CL macros.
On May 16, 4:41 pm, gugamilare <··········@gmail.com> wrote:
> On 16 maio, 17:10, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
> > > but it's besides the point. Imagine that C didn't have macros.
> > > You go on and change the definition of malloc()...
>
> > Still not getting it, I see. To change the definition of malloc() one
> > would edit the source file containing malloc(). Whereas that macro
> > could be stuck pretty much anywhere and blow things up. Locality of
> > side effects of code changes is destroyed by macros.
>
> 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?
> > > Obviously yes so why is it that macros specifically cause the
> > > problem?
>
> > The problem with macros that I've been getting it is their inherent
> > ability to alter the behavior of far-away code from pretty much
> > anywhere. A function has to be intentionally invoked by some code to
> > have effect there; a macro has to be coded to operate ON some other
> > code to have effect there. It's easy to whip up a C macro that affects
> > all the code that uses strlen() or all the code that uses char *
> > pointers or turn all the code's floats into doubles. Some of these
> > uses might be useful. All of them are potential maintenance headaches,
> > since
>
> 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.
> > 1. Someone reading the affected code might assume it does what it
> > says at face value, and the macro changed that;
> > 2. Even if they know, or suspect, otherwise, finding all the macros
> > that potentially alter the behavior of a particular bit of code
> > is an exercise in haystack-needle-finding.
>
> 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.
> > Lisp macros apparently are slightly more limited, having to take the
> > form of function calls rather than arbitrary code fragments.
>
> 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.
> > > You cannot extrapolate from that to when you use
> > > macros in a thoughtful manner.
>
> > Typos are non-thoughtful more or less by definition.
>
> 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.
> > > Take you for example: you have strong opinions about macros but
> > > I bet you've never written a single Lisp macro.
>
> > I've written lots of macros, though, in a variety of places and
> > contexts.
>
> 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.
On May 17, 8:47 am, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:41 pm, gugamilare <··········@gmail.com> wrote:
>
> > On 16 maio, 17:10, Series Expansion <·······@gmail.com> wrote:
> > > On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
> > > > but it's besides the point. Imagine that C didn't have macros.
> > > > You go on and change the definition of malloc()...
>
> > > Still not getting it, I see. To change the definition of malloc() one
> > > would edit the source file containing malloc(). Whereas that macro
> > > could be stuck pretty much anywhere and blow things up. Locality of
> > > side effects of code changes is destroyed by macros.
>
> > 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?
>
> > > > Obviously yes so why is it that macros specifically cause the
> > > > problem?
>
> > > The problem with macros that I've been getting it is their inherent
> > > ability to alter the behavior of far-away code from pretty much
> > > anywhere. A function has to be intentionally invoked by some code to
> > > have effect there; a macro has to be coded to operate ON some other
> > > code to have effect there. It's easy to whip up a C macro that affects
> > > all the code that uses strlen() or all the code that uses char *
> > > pointers or turn all the code's floats into doubles. Some of these
> > > uses might be useful. All of them are potential maintenance headaches,
> > > since
>
> > 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.
The problem with giving C examples, is that C macros are something
completely different from Lisp marcos. Apples and oranges.
>
> > We are not dumbs.
>
> 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.
>
> > > 1. Someone reading the affected code might assume it does what it
> > > says at face value, and the macro changed that;
> > > 2. Even if they know, or suspect, otherwise, finding all the macros
> > > that potentially alter the behavior of a particular bit of code
> > > is an exercise in haystack-needle-finding.
>
> > 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.
Ok. I'll explain the Lisp macro system, briefly, at the end of this
post.
>
> > > Lisp macros apparently are slightly more limited, having to take the
> > > form of function calls rather than arbitrary code fragments.
>
> > 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.
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.
>
> > > > You cannot extrapolate from that to when you use
> > > > macros in a thoughtful manner.
>
> > > Typos are non-thoughtful more or less by definition.
>
> > 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.
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
>
> > > > Take you for example: you have strong opinions about macros but
> > > > I bet you've never written a single Lisp macro.
>
> > > I've written lots of macros, though, in a variety of places and
> > > contexts.
>
> > 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.
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
On 17 maio, 03:22, Adlai <·········@gmail.com> wrote:
> On May 17, 8:47 am, Series Expansion <·······@gmail.com> wrote:
>
>
>
> > On May 16, 4:41 pm, gugamilare <··········@gmail.com> wrote:
>
> > > On 16 maio, 17:10, Series Expansion <·······@gmail.com> wrote:
> > > We are not dumbs.
>
> > 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.
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.
gugamilare wrote:
> 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.
A) Your English is fine.
B) It's not that he thinks you're stupid because of your English, it's that
Series Expansion is a troll and a liar.
C) He doesn't have a point.
D) Neither does this thread.
--
Lew
On May 17, 1:06 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > 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.
>
> A) Your English is fine.
> B) It's not that he thinks you're stupid because of your English, it's that
> Series Expansion is a troll and a liar.
> C) He doesn't have a point.
> D) Neither does this thread.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and gugamilare.
I was not considering gugamilare's grammatical errors in isolation,
but as part of a larger pattern.
On May 17, 2:54 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 03:22, Adlai <·········@gmail.com> wrote:
>
> > On May 17, 8:47 am, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 16, 4:41 pm, gugamilare <··········@gmail.com> wrote:
>
> > > > On 16 maio, 17:10, Series Expansion <·······@gmail.com> wrote:
> > > > We are not dumbs.
>
> > > 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.
>
> 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.
On May 17, 2:22 am, Adlai <·········@gmail.com> wrote:
> On May 17, 8:47 am, Series Expansion <·······@gmail.com> wrote:
> > 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.
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.)
> > > We are not dumbs.
>
> > 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.
If that mistake had been made in isolation, I might agree. However, it
is part of a larger pattern.
> > > > Lisp macros apparently are slightly more limited, having to take the
> > > > form of function calls rather than arbitrary code fragments.
>
> > > 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.
>
> 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.
> > > > > You cannot extrapolate from that to when you use
> > > > > macros in a thoughtful manner.
>
> > > > Typos are non-thoughtful more or less by definition.
>
> > > 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.
>
> 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.)
> > 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.
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.
On 17 maio, 02:47, Series Expansion <·······@gmail.com> wrote:
> On May 16, 4:41 pm, gugamilare <··········@gmail.com> wrote:
> > Sorry, but, I don't follow. What is the difference? Arbitrary forms
> > are arbitrary code fragments. I really don't get it.
Ah!!! I didn't know that! Now I know why C macros fail. And why this
is so difficult for you to understand
>
> 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.
Now you get it. The only difference between macros and functions is
when it is called, and the type of arguments it receives. 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.
>
> > > > You cannot extrapolate from that to when you use
> > > > macros in a thoughtful manner.
>
> > > Typos are non-thoughtful more or less by definition.
>
> > 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.
The Lisp compiler always complains about name collisions, whether it
is a macro-macro, function-function or macro-function call. Any other
cases can't be misinterpreted.
>
> > > > Take you for example: you have strong opinions about macros but
> > > > I bet you've never written a single Lisp macro.
>
> > > I've written lots of macros, though, in a variety of places and
> > > contexts.
>
> > But not CL macros. They are VERY different.
>
> Another hand-wave. Macros are macros are macros.
No. Every language implements everything in a different way.
>
> 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.
This is easily handled in lisp using local variables and gensyms (auto-
generated collision-free symbols). You just bound the arguments you
want to evaluate into variables whenever you want to evaluate anything
(this is mostly, but not always, the case), and then use the
variables. Side-effects and variable-collision safe. Just simple as
that.
>
> Furthermore, the variable capture problems follow automatically as
> well.
Gensyms again.
> 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.
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.
Nintendo 64 was implemented using Lisp. So was Mario 64. And also
another game made to Playstation 2 that I don't remember the name. ITA
Software is a well known company that uses Common Lisp. 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.
Many really experienced programmers like Paul Graham use Lisp (and not
only Lisp). And you are the first one to ever see these problems. You
must be a genius.
gugamilare <··········@gmail.com> writes:
> Nintendo 64 was implemented using Lisp. So was Mario 64.
Was it? Where did you learn that?
>And also another game made to Playstation 2 that I don't remember the
>name.
Jak and Daxter, although some of their other games might have been done
the same way. I don't recall.
Paul Donnelly <·············@sbcglobal.net> writes:
> gugamilare <··········@gmail.com> writes:
>
>> Nintendo 64 was implemented using Lisp. So was Mario 64.
>
> Was it? Where did you learn that?
I don't know many details, but IIRC a Lisp-based system by Nichimen
Graphics was used for some part of the implementation of Mario 64.
http://www.franz.com/success/customer_apps/animation_graphics/nichimen.lhtml
has some info.
Zach
Zach Beane <····@xach.com> writes:
> Paul Donnelly <·············@sbcglobal.net> writes:
>
>> gugamilare <··········@gmail.com> writes:
>>
>>> Nintendo 64 was implemented using Lisp. So was Mario 64.
>>
>> Was it? Where did you learn that?
>
> I don't know many details, but IIRC a Lisp-based system by Nichimen
> Graphics was used for some part of the implementation of Mario 64.
>
> http://www.franz.com/success/customer_apps/animation_graphics/nichimen.lhtml
> has some info.
>
> Zach
Thanks for the link; I didn't know about that.
On May 17, 2:34 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 02:47, Series Expansion <·······@gmail.com> wrote:
> > On May 16, 4:41 pm, gugamilare <··········@gmail.com> wrote:
> > > Sorry, but, I don't follow. What is the difference? Arbitrary forms
> > > are arbitrary code fragments. I really don't get it.
>
> 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.
> > 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.
>
> 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.
> > > > > You cannot extrapolate from that to when you use
> > > > > macros in a thoughtful manner.
>
> > > > Typos are non-thoughtful more or less by definition.
>
> > > 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.
>
> 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.
> > > > > Take you for example: you have strong opinions about macros but
> > > > > I bet you've never written a single Lisp macro.
>
> > > > I've written lots of macros, though, in a variety of places and
> > > > contexts.
>
> > > But not CL macros. They are VERY different.
>
> > Another hand-wave. Macros are macros are macros.
>
> 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.
> > 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.
>
> 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.
> > 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.
>
> 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 <·······@gmail.com> writes:
> On May 16, 4:41 pm, gugamilare <··········@gmail.com> wrote:
>> On 16 maio, 17:10, Series Expansion <·······@gmail.com> wrote:
>> > On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
>> > > but it's besides the point. Imagine that C didn't have macros.
>> > > You go on and change the definition of malloc()...
>>
>> > Still not getting it, I see. To change the definition of malloc() one
>> > would edit the source file containing malloc(). Whereas that macro
>> > could be stuck pretty much anywhere and blow things up. Locality of
>> > side effects of code changes is destroyed by macros.
>>
>> 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.
You're complaining that macros can do something that functions can do
too?
You might want to explain this "lack of encapsulation barrier" stuff so
we can tell you specifically how wrong you are this time.
Paul Donnelly wrote:
> You might want to explain this "lack of encapsulation barrier" stuff so
> we can tell you specifically how wrong you are this time.
We'd prefer that neither of you do that.
--
Lew
On May 17, 1:08 pm, Lew <·····@lewscanon.com> wrote:
> Paul Donnelly wrote:
> > You might want to explain this "lack of encapsulation barrier" stuff so
> > we can tell you specifically how wrong you are this time.
>
> We'd prefer that neither of you do that.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Paul.
Series Expansion wrote:
> On May 17, 1:08 pm, Lew <·····@lewscanon.com> wrote:
>> Paul Donnelly wrote:
>>> You might want to explain this "lack of encapsulation barrier" stuff so
>>> we can tell you specifically how wrong you are this time.
>> We'd prefer that neither of you do that.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew" and Paul.
That was not a personal attack.
Do you read what you reply to?
Arne
On May 20, 9:24 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 17, 1:08 pm, Lew <·····@lewscanon.com> wrote:
> >> Paul Donnelly wrote:
> >>> You might want to explain this "lack of encapsulation barrier" stuff so
> >>> we can tell you specifically how wrong you are this time.
> >> We'd prefer that neither of you do that.
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, "Lew" and Paul.
>
> That was not a personal attack.
It implied one.
> Do you read what you reply to?
Of course.
On May 17, 5:17 am, Paul Donnelly <·············@sbcglobal.net> wrote:
> Series Expansion <·······@gmail.com> writes:
> > Except the lack of encapsulation barrier, and the ability of macros to
> > replace or modify existing functions of the same name.
>
> You're complaining that macros can do something that functions can do
> too?
No; functions generally cannot do that. For example, in C:
#include <stdio.h>
int foo (int x) { return 0; }
#define foo(x) x
int main (void) { printf("%d",foo(1)); }
-> 1
#include <stdio.h>
int foo (int x) { return 0; }
int foo (int x) { return x; }
int main (void) { printf("%d",foo(1)); }
-> duplicate symbol error
Java likewise won't allow silently replacing methods or classes, save
by replacing their .class or .jar files rather than simply adding code
somewhere. Though Java lacks macros.
> You might want to explain this "lack of encapsulation barrier" stuff
Already did, at least twice. I don't feel like doing it a third time.
> so we can tell you specifically how wrong you are this time.
If my doing it a third time would be "rebutted" with ad hominem
arguments, then I am certainly not doing it a third time, since
clearly it would be a waste of my time instead of leading to
productive debate.
Series Expansion <·······@gmail.com> writes:
>> But not CL macros. They are VERY different.
>
> Another hand-wave. Macros are macros are macros.
Dogs are dogs are dogs. How loud does your hot-dog bark?
> 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.
Lisp macros are functions, not symbols. Symbols are only used to name
lisp macros.
> 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.
You may want to write a macro such as:
(print-and-return (incf x))
that should print the value returned, without evaluating the
expression twice. (An artificial example, since the function PRINT
already does that). Then you'd write it:
(defmacro print-and-return (expression)
(let ((value-name (gensym)))
`(let ((,value-name ,expression)) ; evaluates expression once
(print ,value-name) ; prints its value
,value-name))) ; and returns it.
On the other hand, you may want to write a macro such as:
(repeat-thrice (incf x))
that should evaluate the expression three times. Then you'd write:
(defmacro repeat-thrice (expression)
`(progn
,expression
,expression
,expression))
so expression will be evaluted three times.
If you want to do something, then do it. If you don't want it, then
just don't do it. That's what we call not being dumb.
> 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.
If you want to capture a variable, then you can.
If you want to capture a variable specified as parameter, then you can.
If you want to define variables that are not accessible to the subexpressions, then you can.
If you want to define variables that are accessible to the subexpressions, then you can.
If you want to define variables specified as parameter that are accessible to the subexpressions, then you can.
If you want to define variables specified as parameter that are accessible to the subexpressions but protected from any interference, then you can.
If you want to avoid capturing any variable (see print-and-return above), then you can.
If you want to have side effects, then you can.
If you want to be side-effect free, then you can.
Why would you do something that you wouldn't want? Are you dumb?
Capture a variable:
(defmacro capturing-x (y) `(- (* 157 x x) ,y))
(let ((x 42)) (capturing-x 239))
--> 276709
Capture a variable specified as parameter:
(defmacro capture (var y) `(- (* 157 ,var ,var) ,y))
(let ((x 42) (y 1))
(list (capture x 239) (capture y 42)))
--> (276709 115)
Define variables that are not accessible to the subexpressions:
(defmacro repeat-using-inaccessible-variable (n expression)
(let ((inaccessible-variable (gensym)))
`(dotimes (,inaccessible-variable ,n) ,expression)))
(repeat-using-inaccessible-variable 3
(print "whatever you do here you can't get access to the counter"))
prints:
"whatever you do here you can't get access to the counter"
"whatever you do here you can't get access to the counter"
"whatever you do here you can't get access to the counter"
Define variables that are accessible to the subexpressions:
(defmacro repeat-using-accessible-variable-named-counter (n expression)
`(dotimes (counter ,n) ,expression))
(repeat-using-accessible-variable-named-counter 4
(format t "The value of COUNTER in the ~A~:*~[th~;st~;nd~;rd~;th~] iteration is ~A~%"
(1+ counter) counter))
prints:
The value of COUNTER in the 1st iteration is 0
The value of COUNTER in the 2nd iteration is 1
The value of COUNTER in the 3rd iteration is 2
The value of COUNTER in the 4th iteration is 3
Define variables specified as parameter that are accessible to the subexpressions:
(defmacro repeat-with-counter ((counter n) expression)
`(dotimes (,counter ,n) ,expression))
(repeat-with-counter (my-counter 4)
(format t "The value of ~A in the ~A~:*~[th~;st~;nd~;rd~;th~] iteration is ~A~%"
'my-counter (1+ my-counter) my-counter))
prints:
The value of MY-COUNTER in the 1st iteration is 0
The value of MY-COUNTER in the 2nd iteration is 1
The value of MY-COUNTER in the 3rd iteration is 2
The value of MY-COUNTER in the 4th iteration is 3
Define variables specified as parameter that are accessible to the
subexpressions but protected from any interference:
(defmacro repeat-with-protected-counter ((counter n) expression)
`(dotimes (,counter ,n) (let ((,counter ,counter)) ,expression)))
(repeat-with-protected-counter (my-counter 4)
(progn
(format t "The value of ~A in the ~A~:*~[th~;st~;nd~;rd~;th~] iteration is ~A~%"
'my-counter (1+ my-counter) my-counter)
(setf my-counter 0)))
prints:
The value of MY-COUNTER in the 1st iteration is 0
The value of MY-COUNTER in the 2nd iteration is 1
The value of MY-COUNTER in the 3rd iteration is 2
The value of MY-COUNTER in the 4th iteration is 3
Avoid capturing any variable:
(defmacro print-and-return (expression)
(let ((value-name (gensym)))
`(let ((,value-name ,expression)) ; evaluates expression once
(print ,value-name) ; prints its value
,value-name))) ; and returns it.
(let ((x 0) (value-name 'toto))
(print-and-return (incf x))
(print value-name))
prints:
1
TOTO
Have side effects:
(defmacro define-typed-function (name arguments &body body)
`(defun ,name ,(mapcar (function first) arguments)
(declare ,@(mapcar (lambda (var-type)
(destructuring-bind (var type) var-type
`(type ,type ,var))) arguments))
,@body))
(define-typed-function fact ((n integer))
(if (<= n 0)
1
(* n (fact (1- n)))))
--> FACT
(macroexpand-1 '(define-typed-function fact ((n integer))
(if (<= n 0)
1
(* n (fact (1- n))))))
--> (DEFUN FACT (N) (DECLARE (TYPE INTEGER N)) (IF (<= N 0) 1 (* N (FACT (1- N))))) ;
T
(fact 20)
--> 2432902008176640000
Not have side effects:
(defmacro print-and-return (expression)
(let ((value-name (gensym)))
`(let ((,value-name ,expression)) ; evaluates expression once
(print ,value-name) ; prints its value
,value-name))) ; and returns it.
(let ((x 0) (value-name 'toto))
(print-and-return (incf x))
(print value-name))
prints:
1
TOTO
> 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.
Yes. So why would you do that if that's not what you want to do?
> And all of the above is extrapolated from the definition of "macro"
> without reference to any particular language, implementation, or
> anything.
Oh! How dumb! We were discussing Lisp macros... Dog, Hot-Dog?
> 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.
Assembler macros where invented in the 1950's.
Lisp macros were invented in the early 1960's.
C macros where invented in the 1970's.
All the above can be done as well in good macro assemblers, this has
already been mentionned in this thread.
We have priority on the terminology here.
--
__Pascal Bourguignon__
On May 17, 11:20 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> >> But not CL macros. They are VERY different.
>
> > Another hand-wave. Macros are macros are macros.
>
> Dogs are dogs are dogs. How loud does your hot-dog bark?
Non-sequitur.
> Lisp macros are functions, not symbols. Symbols are only used to name
> lisp macros.
Irrelevant to the point I am making.
> that should print the value returned, without evaluating the
> expression twice. (An artificial example, since the function PRINT
> already does that). Then you'd write it:
>
> (defmacro print-and-return (expression)
> (let ((value-name
[snip]
Of course it did occur to me that one could assign the expression to a
local variable and then use the local variable. This trades the
multiple-evaluation problem for either potential variable capture or
potential variable hiding. The remaining alternative, use of a global
variable, has well-known pitfalls, even with the use of namespaces.
> On the other hand, you may want to write a macro such as:
>
> (repeat-thrice (incf x))
>
> that should evaluate the expression three times. Then you'd write:
>
> (defmacro repeat-thrice (expression)
> `(progn
> ,expression
> ,expression
> ,expression))
>
> so expression will be evaluted three times.
Closures can be used to do this too, and without the pitfalls. You'd
pass the expression as a closure to an ordinary function, which having
its own local scope instead of ending up lexically merged with its
call site, would not have any variable hiding or variable capture
potential. Then the closure can be evaluated once and its value
stored, without nasty side effects, or it can be evaluated multiple
times. The latter is how "3 timesRepeat: [expr]" works in Smalltalk.
> If you want to do something, then do it. If you don't want it, then
> just don't do it. That's what we call not being dumb.
Einstein could not write certain macros to simultaneously avoid all
four of multiple evaluation, variable capture, variable hiding, and
use of global variables, independently of the names of the local
variables in scope at the call site.
The use of a long and obscure name on a macro-internal local variable,
combined with nesting its use within an enclosing local scope within
the macro, affords the maximum mitigation; multiple evaluation,
variable capture, and global variables are all completely avoided but
variable hiding, though rendered unlikely, remains possible.
That is the absolute best that can be done.
A function with closure-valued arguments can do everything you've done
with macros, so far, except for the "it trick", and additionally can
easily be made to avoid all four of multiple evaluation, variable
capture, variable hiding, and global variables simultaneously and with
100% reliability. Einstein not required; a reasonably competent
Smalltalk programmer in particular can do it.
Which means the only things Lisp macros apparently get you are:
a) Compile time expansion, i.e. basically automatic inlining, and an
optimizing compiler can inline a function that takes closures; and
b) Macros that deliberately use variable capture.
The latter, so far, seem to be clever tricks that slightly simplify
some sorts of code, but nothing crucial; the "it trick" in particular
amounts to syntactic sugar.
Closure-taking functions get you:
a) Optional inlining instead of mandatory; not inlining in some cases
might reduce cache misses; and
b) The ability for the closure itself, not just the variables used in
it, to vary at run-time; and
c) The ability to simultaneously reliably avoid all four of multiple
evaluation, variable capture, variable hiding, and global
variables.
Right now closure-taking functions seem to be coming out ahead.
> Why would you do something that you wouldn't want?
Because you couldn't avoid it?
> Are you dumb?
No.
[large volume of Lisp code deleted]
None of this is relevant to the issues described above. Those issues
are inherent in the very definition of a macro as lexically replacing
its call and having its actual parameters lexically replace its formal
parameters, as has been proven repeatedly.
> > 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.
>
> Yes. So why would you do that if that's not what you want to do?
Because the only alternatives, sometimes, are multiple evaluation of
arguments that may have side effects and use of global variables.
> > And all of the above is extrapolated from the definition of "macro"
> > without reference to any particular language, implementation, or
> > anything.
>
> Oh! How dumb!
No, it is not.
> We were discussing Lisp macros
Not relevant.
These issues are inherent in the very definition of a macro as
lexically replacing its call and having its actual parameters
lexically replace its formal parameters, as has been proven
repeatedly.
If Lisp macros have the property of lexically replacing their calls
and having their actual parameters lexically replace their formal
parameters, then Lisp macros inevitably succumb to the tradeoffs
described above (and, repeatedly, in previous posts).
If Lisp macros lack the property of lexically replacing their calls
and having their actual parameters lexically replace their formal
parameters, then Lisp macros are not actually macros at all and you,
and your associates, have perpetrated a colossal hoax here and should
be ashamed of yourselves.
> Dog, Hot-Dog?
Non-sequitur. Unless this seemingly irrelevant sentence fragment is
meant to imply that Lisp macros are not truly macros, in which case
you and your fellow hoaxers have a great deal to apologize for,
starting with a massive trolling of comp.lang.java.programmer.
It is advisable that this be cleared up once and for all, so I will
directly ask:
Do Lisp macros possess the property of lexically replacing their calls
and having their actual parameters lexically replace their formal
parameters?
Yes or no.
> > 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.
> Assembler macros where invented in the 1950's.
Irrelevant.
> Lisp macros were invented in the early 1960's.
Irrelevant.
> C macros where invented in the 1970's.
Irrelevant.
> All the above can be done as well in good macro assemblers, this has
> already been mentionned in this thread.
Irrelevant.
> We have priority on the terminology here.
Non-sequitur.
Do Lisp macros possess the property of lexically replacing their calls
and having their actual parameters lexically replace their formal
parameters?
Yes or no.
Series Expansion <·······@gmail.com> writes:
>
> Of course it did occur to me that one could assign the expression to a
> local variable and then use the local variable. This trades the
> multiple-evaluation problem for either potential variable capture or
> potential variable hiding. The remaining alternative, use of a global
> variable, has well-known pitfalls, even with the use of namespaces.
But there was another alternative that you don't even consider, namely
the use of uninterned symbols to name the variables. They are precisely
the tool for avoiding multiple-evaluation, variable capture and variable
hiding. And they aren't global variables.
There was, in fact, an example of that posted in another part of this
thread.
> Closures can be used to do this too, and without the pitfalls. You'd
> pass the expression as a closure to an ordinary function, which having
> its own local scope instead of ending up lexically merged with its
> call site, would not have any variable hiding or variable capture
> potential. Then the closure can be evaluated once and its value
> stored, without nasty side effects, or it can be evaluated multiple
> times. The latter is how "3 timesRepeat: [expr]" works in Smalltalk.
>
> > If you want to do something, then do it. ��If you don't want it, then
> > just don't do it. ��That's what we call not being dumb.
>
> Einstein could not write certain macros to simultaneously avoid all
> four of multiple evaluation, variable capture, variable hiding, and
> use of global variables, independently of the names of the local
> variables in scope at the call site.
Well, I'm sure that is only because Einstein didn't learn Lisp. If he
had, then he would clearly be aware that GENSYMs solve precisely all
four of the problems you list above.
> The use of a long and obscure name on a macro-internal local variable,
> combined with nesting its use within an enclosing local scope within
> the macro, affords the maximum mitigation; multiple evaluation,
> variable capture, and global variables are all completely avoided but
> variable hiding, though rendered unlikely, remains possible.
>
> That is the absolute best that can be done.
Bzzt. Wrong again. But thanks for playing.
The absolute best that can be done involves GENSYMs, which are
themselves sometimes made even easier to use via the common ONCE-ONLY
macro.
> Which means the only things Lisp macros apparently get you are:
> a) Compile time expansion, i.e. basically automatic inlining, and an
> optimizing compiler can inline a function that takes closures; and
> b) Macros that deliberately use variable capture.
How about a function that performs code analysis and uses computations
in order to determine the proper expansion. The LOOP macro is one
example of this that I think would be rather tricky to accomplish using
closures.
What about modified evaluation of arguments? A simple macro that takes
a variable name and prints out the name and the value of the variable.
> Do Lisp macros possess the property of lexically replacing their calls
> and having their actual parameters lexically replace their formal
> parameters?
>
> Yes or no.
It depends. The macro expansion argument can do arbitary things with
the arguments passed to it. There is no requirement that the actual
parameters appear anywhere in the expansion. They may, or they may
not. Sometimes they are only used in helping determine what an
appropriate expansion should be.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 19, 3:16 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > Of course it did occur to me that one could assign the expression to a
> > local variable and then use the local variable. This trades the
> > multiple-evaluation problem for either potential variable capture or
> > potential variable hiding. The remaining alternative, use of a global
> > variable, has well-known pitfalls, even with the use of namespaces.
>
> But there was another alternative that you don't even consider
No, there wasn't.
> namely the use of uninterned symbols to name the variables.
I didn't consider a solution that only works for write-only variables
to be sufficiently general to be of interest.
> > > If you want to do something, then do it. Ž If you don't want it, then
> > > just don't do it. Ž That's what we call not being dumb.
>
> > Einstein could not write certain macros to simultaneously avoid all
> > four of multiple evaluation, variable capture, variable hiding, and
> > use of global variables, independently of the names of the local
> > variables in scope at the call site.
>
> Well, I'm sure that is only because Einstein didn't learn Lisp.
Illogical.
> > The use of a long and obscure name on a macro-internal local variable,
> > combined with nesting its use within an enclosing local scope within
> > the macro, affords the maximum mitigation; multiple evaluation,
> > variable capture, and global variables are all completely avoided but
> > variable hiding, though rendered unlikely, remains possible.
>
> > That is the absolute best that can be done.
>
> Bzzt. Wrong again. But thanks for playing.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
> > Which means the only things Lisp macros apparently get you are:
> > a) Compile time expansion, i.e. basically automatic inlining, and an
> > optimizing compiler can inline a function that takes closures; and
> > b) Macros that deliberately use variable capture.
>
> How about a function that performs code analysis and uses computations
> in order to determine the proper expansion.
A function that uses computations and conditions on the values of some
of its arguments in order to determine which of several closures to
invoke, in what sequence, and repeatedly until other conditions are
met.
There are looping constructs in Smalltalk implemented using closures,
but without macros.
> The LOOP macro is one example of this that I think would be rather
> tricky to accomplish using closures.
The LOOP macro is also one butt-ugly piece of ... something, which
even many of you Lispers seem to avoid for philosophical or aesthetic
reasons.
> What about modified evaluation of arguments? A simple macro that takes
> a variable name and prints out the name and the value of the variable.
A poor-man's watch function. Get a proper debugger.
> > Do Lisp macros possess the property of lexically replacing their calls
> > and having their actual parameters lexically replace their formal
> > parameters?
>
> > Yes or no.
>
> It depends.
Cop-out.
On May 19, 5:47 am, Series Expansion <·······@gmail.com> wrote:
[snip]
>
> > If you want to do something, then do it. If you don't want it, then
> > just don't do it. That's what we call not being dumb.
>
> Einstein could not write certain macros to simultaneously avoid all
> four of multiple evaluation,variablecapture,variablehiding, and
> use of global variables, independently of the names of the local
> variables in scope at the call site.
I am not Einstein, yet in another post I showed you a macro that does
neither of the above.
> The use of a long and obscure name on a macro-internal localvariable,
> combined with nesting its use within an enclosing local scope within
> the macro, affords the maximum mitigation; multiple evaluation,variablecapture, and global variables are all completely avoided butvariablehiding, though rendered unlikely, remains possible.
>
> That is the absolute best that can be done.
Not really. See my other post.
> A function with closure-valued arguments can do everything you've done
> with macros, so far, except for the "it trick", and additionally can
> easily be made to avoid all four of multiple evaluation,variablecapture,variablehiding, and global variables simultaneously and with
> 100% reliability.Einsteinnot required; a reasonably competent
> Smalltalk programmer in particular can do it.
> Which means the only things Lisp macros apparently get you are:
> a) Compile time expansion, i.e. basically automatic inlining, and an
> optimizing compiler can inline a function that takes closures; and
> b) Macros that deliberately usevariablecapture.
>
> The latter, so far, seem to be clever tricks that slightly simplify
> some sorts of code, but nothing crucial; the "it trick" in particular
> amounts to syntactic sugar.
Actually intentional variable capture, or introduction of local
functions/macros which is equivalent, is a valuable technique: it
allows, among other things, macros which establish a dynamic context
by locally rebinding variables; for example, the macro with-standard-
io-syntax that is built-in in the CL standard.
A higher-order function also does not allow other common uses of
macros like introducing new syntax, executing code at compile time,
etc.
> Closure-taking functions get you:
> a) Optional inlining instead of mandatory; not inlining in some cases
> might reduce cache misses; and
> b) The ability for the closure itself, not just the variables used in
> it, to vary at run-time; and
> c) The ability to simultaneously reliably avoid all four of multiple
> evaluation,variablecapture,variablehiding, and global
> variables.
>
> Right now closure-taking functions seem to be coming out ahead.
>
> > Why would you do something that you wouldn't want?
>
> Because you couldn't avoid it?
>
> > Are you dumb?
>
> No.
>
> [large volume of Lisp code deleted]
>
> None of this is relevant to the issues described above. Those issues
> are inherent in the very definition of a macro as lexically replacing
> its call and having its actual parameters lexically replace its formal
> parameters, as has been proven repeatedly.
>
> > > 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.
>
> > Yes. So why would you do that if that's not what you want to do?
>
> Because the only alternatives, sometimes, are multiple evaluation of
> arguments that may have side effects and use of global variables.
>
> > > And all of the above is extrapolated from the definition of "macro"
> > > without reference to any particular language, implementation, or
> > > anything.
>
> > Oh! How dumb!
>
> No, it is not.
>
> > We were discussing Lisp macros
>
> Not relevant.
>
> These issues are inherent in the very definition of a macro as
> lexically replacing its call and having its actual parameters
> lexically replace its formal parameters, as has been proven
> repeatedly.
>
> If Lisp macros have the property of lexically replacing their calls
> and having their actual parameters lexically replace their formal
> parameters, then Lisp macros inevitably succumb to the tradeoffs
> described above (and, repeatedly, in previous posts).
>
> If Lisp macros lack the property of lexically replacing their calls
> and having their actual parameters lexically replace their formal
> parameters, then Lisp macros are not actually macros at all and you,
> and your associates, have perpetrated a colossal hoax here and should
> be ashamed of yourselves.
>
> > Dog, Hot-Dog?
>
> Non-sequitur. Unless this seemingly irrelevant sentence fragment is
> meant to imply that Lisp macros are not truly macros, in which case
> you and your fellow hoaxers have a great deal to apologize for,
> starting with a massive trolling of comp.lang.java.programmer.
>
> It is advisable that this be cleared up once and for all, so I will
> directly ask:
>
> Do Lisp macros possess the property of lexically replacing their calls
> and having their actual parameters lexically replace their formal
> parameters?
>
> Yes or no.
>
> > > 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.
> > Assembler macros where invented in the 1950's.
>
> Irrelevant.
>
> > Lisp macros were invented in the early 1960's.
>
> Irrelevant.
>
> > C macros where invented in the 1970's.
>
> Irrelevant.
>
> > All the above can be done as well in good macro assemblers, this has
> > already been mentionned in this thread.
>
> Irrelevant.
>
> > We have priority on the terminology here.
>
> Non-sequitur.
>
> Do Lisp macros possess the property of lexically replacing their calls
> and having their actual parameters lexically replace their formal
> parameters?
>
> Yes or no.
Yes, they have. The fallacy here is that this fact DOES NOT imply
variable capture, multiple evaluation, introduction of clashing local
variables, or use of global variables. In Lisp symbols are first-class
objects and there are ways to create a symbol and locally bind it
(introducing a local variable) having GUARANTEED that the generated
symbol is UNIQUE and thus it can not clash with anything. This is what
you fail to understand.
Alessio
Alessio Stalla wrote:
> On May 19, 5:47 am, Series Expansion <·······@gmail.com> wrote:
> [snip]
>>> If you want to do something, then do it. If you don't want it, then
>>> just don't do it. That's what we call not being dumb.
>> Einstein could not write certain macros to simultaneously avoid all
>> four of multiple evaluation,variablecapture,variablehiding, and
>> use of global variables, independently of the names of the local
>> variables in scope at the call site.
>
> I am not Einstein, yet in another post I showed you a macro that does
> neither of the above.
>
>> The use of a long and obscure name on a macro-internal localvariable,
>> combined with nesting its use within an enclosing local scope within
>> the macro, affords the maximum mitigation; multiple evaluation,variablecapture, and global variables are all completely avoided butvariablehiding, though rendered unlikely, remains possible.
>>
>> That is the absolute best that can be done.
>
> Not really. See my other post.
>
>> A function with closure-valued arguments can do everything you've done
>> with macros, so far, except for the "it trick", and additionally can
>> easily be made to avoid all four of multiple evaluation,variablecapture,variablehiding, and global variables simultaneously and with
>> 100% reliability.Einsteinnot required; a reasonably competent
>> Smalltalk programmer in particular can do it.
>> Which means the only things Lisp macros apparently get you are:
>> a) Compile time expansion, i.e. basically automatic inlining, and an
>> optimizing compiler can inline a function that takes closures; and
>> b) Macros that deliberately usevariablecapture.
>>
>> The latter, so far, seem to be clever tricks that slightly simplify
>> some sorts of code, but nothing crucial; the "it trick" in particular
>> amounts to syntactic sugar.
>
> Actually intentional variable capture, or introduction of local
> functions/macros which is equivalent, is a valuable technique: it
> allows, among other things, macros which establish a dynamic context
> by locally rebinding variables; for example, the macro with-standard-
> io-syntax that is built-in in the CL standard.
> A higher-order function also does not allow other common uses of
> macros like introducing new syntax, executing code at compile time,
> etc.
>
>> Closure-taking functions get you:
>> a) Optional inlining instead of mandatory; not inlining in some cases
>> might reduce cache misses; and
>> b) The ability for the closure itself, not just the variables used in
>> it, to vary at run-time; and
>> c) The ability to simultaneously reliably avoid all four of multiple
>> evaluation,variablecapture,variablehiding, and global
>> variables.
>>
>> Right now closure-taking functions seem to be coming out ahead.
>>
>>> Why would you do something that you wouldn't want?
>> Because you couldn't avoid it?
>>
>>> Are you dumb?
>> No.
>>
>> [large volume of Lisp code deleted]
>>
>> None of this is relevant to the issues described above. Those issues
>> are inherent in the very definition of a macro as lexically replacing
>> its call and having its actual parameters lexically replace its formal
>> parameters, as has been proven repeatedly.
>>
>>>> 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.
>>> Yes. So why would you do that if that's not what you want to do?
>> Because the only alternatives, sometimes, are multiple evaluation of
>> arguments that may have side effects and use of global variables.
>>
>>>> And all of the above is extrapolated from the definition of "macro"
>>>> without reference to any particular language, implementation, or
>>>> anything.
>>> Oh! How dumb!
>> No, it is not.
>>
>>> We were discussing Lisp macros
>> Not relevant.
>>
>> These issues are inherent in the very definition of a macro as
>> lexically replacing its call and having its actual parameters
>> lexically replace its formal parameters, as has been proven
>> repeatedly.
>>
>> If Lisp macros have the property of lexically replacing their calls
>> and having their actual parameters lexically replace their formal
>> parameters, then Lisp macros inevitably succumb to the tradeoffs
>> described above (and, repeatedly, in previous posts).
>>
>> If Lisp macros lack the property of lexically replacing their calls
>> and having their actual parameters lexically replace their formal
>> parameters, then Lisp macros are not actually macros at all and you,
>> and your associates, have perpetrated a colossal hoax here and should
>> be ashamed of yourselves.
>>
>>> Dog, Hot-Dog?
>> Non-sequitur. Unless this seemingly irrelevant sentence fragment is
>> meant to imply that Lisp macros are not truly macros, in which case
>> you and your fellow hoaxers have a great deal to apologize for,
>> starting with a massive trolling of comp.lang.java.programmer.
>>
>> It is advisable that this be cleared up once and for all, so I will
>> directly ask:
>>
>> Do Lisp macros possess the property of lexically replacing their calls
>> and having their actual parameters lexically replace their formal
>> parameters?
>>
>> Yes or no.
>>
>>>> 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.
>>> Assembler macros where invented in the 1950's.
>> Irrelevant.
>>
>>> Lisp macros were invented in the early 1960's.
>> Irrelevant.
>>
>>> C macros where invented in the 1970's.
>> Irrelevant.
>>
>>> All the above can be done as well in good macro assemblers, this has
>>> already been mentionned in this thread.
>> Irrelevant.
>>
>>> We have priority on the terminology here.
>> Non-sequitur.
>>
>> Do Lisp macros possess the property of lexically replacing their calls
>> and having their actual parameters lexically replace their formal
>> parameters?
>>
>> Yes or no.
>
> Yes, they have. The fallacy here is that this fact DOES NOT imply
> variable capture, multiple evaluation, introduction of clashing local
> variables, or use of global variables. In Lisp symbols are first-class
> objects and there are ways to create a symbol and locally bind it
> (introducing a local variable) having GUARANTEED that the generated
> symbol is UNIQUE and thus it can not clash with anything. This is what
> you fail to understand.
Plonk this thread.
--
Lew
On May 19, 9:55 am, Lew <·····@lewscanon.com> wrote:
> Alessio Stalla wrote:
> > On May 19, 5:47 am, Series Expansion <·······@gmail.com> wrote:
> > [snip]
> >>> If you want to do something, then do it. If you don't want it, then
> >>> just don't do it. That's what we call not being dumb.
> >> Einstein could not write certain macros to simultaneously avoid all
> >> four of multiple evaluation,variablecapture,variablehiding, and
> >> use of global variables, independently of the names of the local
> >> variables in scope at the call site.
[enormous volumes of unused quoted material discarded]
> > Yes, they have. The fallacy here is ... This is what
> > you fail to understand.
>
> Plonk this thread.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Alessio.
I have explained in a direct followup to Alessio why there is no
failure on my part and no fallacy in my reasoning.
On May 19, 7:03 am, Alessio Stalla <·············@gmail.com> wrote:
> On May 19, 5:47 am, Series Expansion <·······@gmail.com> wrote:
[an attribution is missing here]
> > > If you want to do something, then do it. If you don't want it, then
> > > just don't do it. That's what we call not being dumb.
>
> > Einstein could not write certain macros to simultaneously avoid all
> > four of multiple evaluation,variablecapture,variablehiding, and
> > use of global variables, independently of the names of the local
> > variables in scope at the call site.
>
> I am not Einstein, yet in another post I showed you a macro that does
> neither of the above.
You did not. You showed me that a repeat macro allocates memory for
its loop counter guaranteed not to already be in use. Java's new
operator also allocates memory that is not already in use. So does C+
+'s, and C's malloc() function. There's nothing fancy there. Nor
anything relevant to the issue at hand, which involved variable name
resolution at compile time, not storage allocation at run time.
> > The use of a long and obscure name on a macro-internal localvariable,
> > combined with nesting its use within an enclosing local scope within
> > the macro, affords the maximum mitigation; multiple evaluation,variablecapture, and global variables are all completely avoided butvariablehiding, though rendered unlikely, remains possible.
>
> > That is the absolute best that can be done.
>
> Not really. See my other post.
Yes really. Your other post utterly failed to suggest anything other
than the trivial fact that at least the macro could avoid accidentally
clobbering already-used memory when dynamically allocating fresh
memory for some data-structure.
> > A function with closure-valued arguments can do everything you've done
> > with macros, so far, except for the "it trick", and additionally can
> > easily be made to avoid all four of multiple evaluation,variablecapture,variablehiding, and global variables simultaneously and with
> > 100% reliability.Einsteinnot required; a reasonably competent
> > Smalltalk programmer in particular can do it.
> > Which means the only things Lisp macros apparently get you are:
> > a) Compile time expansion, i.e. basically automatic inlining, and an
> > optimizing compiler can inline a function that takes closures; and
> > b) Macros that deliberately usevariablecapture.
>
> > The latter, so far, seem to be clever tricks that slightly simplify
> > some sorts of code, but nothing crucial; the "it trick" in particular
> > amounts to syntactic sugar.
>
> Actually intentional variable capture, or introduction of local
> functions/macros which is equivalent, is a valuable technique
All I've seen demonstrated with it so far was the cute "it trick",
which amuses for a few seconds and accomplishes little else.
It may not be just more of the proverbial bathwater, but it does not
appear to be the proverbial baby, either.
> A higher-order function also does not allow other common uses of
> macros like introducing new syntax
It does, or rather, it allows introducing new control structures,
which suffices.
> executing code at compile time
This is a decision better made by the compiler and optimizer, not by
the programmer. Inlining is capable of causing otherwise-avoidable
cache misses, and bloats up the code.
> > Do Lisp macros possess the property of lexically replacing their calls
> > and having their actual parameters lexically replace their formal
> > parameters?
>
> > Yes or no.
>
> Yes, they have.
Then that's the end of it. Thank you.
> The fallacy here
There is no fallacy here.
> is that this fact DOES NOT imply variable capture, multiple evaluation,
> introduction of clashing local variables, or use of global variables.
It does not guarantee them for all macros, no, but it does guarantee
them for some, by the logic I'd previously outlined.
Suppose an argument is to be used twice. To avoid multiple evaluation,
the result of evaluating it must be stored somewhere. Regardless of
where the storage for that value is allocated, the code that replaces
the macro call must refer to it. To do so it must use a name. If that
creates a global variable, then a bad thing happens. If it does not,
then that name must name a local variable. It also must be a legal
identifier. It follows that another variable may exist in a nesting
scope that possesses the same name, which will therefore either be
captured or be hidden by the macro variable, and a bad thing happens.
That the Lisp macro can compute any function of its arguments to use
as the replacement code does not let you escape the trap. The names of
all existing variables in all enclosing scope cannot be computed from
the arguments alone, so unless the macro is the entire computer
program, it is possible for it to pick a variable name that is already
in use in an enclosing scope.
> In Lisp symbols are first-class
> objects and there are ways to create a symbol and locally bind it
> (introducing a local variable) having GUARANTEED that the generated
> symbol is UNIQUE
This is all entirely irrelevant. The issue is that the local variable
you bind may share its name with another, and rebinding it will
therefore rebind the other.
You are focusing on the equivalent of "if I have t = new Foo(); and u
= new Foo(); and call t.setQuux(42); and u.setQuux(17); it won't
change the 42 in the Foo pointed to by t to 17", when the real issue
at hand is "if I have t = new Foo(); and t = new Foo(); then call
t.setQuux(42); and t.setQuux(17); it will change the 42 in the Foo
pointed to by t to 17". It may be true that the first Foo allocated
with new Foo(); still does not get its quux clobbered, but it is also
irrelevant -- the local variable t has ended up rebound, pointing to
the wrong Foo object, and this will cause logic errors in subsequent
program execution.
> This is what you fail to understand.
I fail at nothing. As demonstrated, I understand perfectly, whereas
you seem to be confused between issues of name resolution (at compile
time!) and issues of storage allocation/aliasing (at run time!).
Series Expansion <·······@gmail.com> wrote in news:886d0118-9790-45f9-
·················@s16g2000vbp.googlegroups.com:
> Another hand-wave. Macros are macros are macros.
That's like saying tools are tools are tools. And there are some
situations where some tools are known to be dangerous. Therefore you
want to disallow tools.
You should also keep in mind that when you argue with Lisp novices about
the advantages and disadvantages of various Lisp features, you aren't
necessarily learning as much as you think you are.
As I said before, it's useless for us to try to explain the advantages of
CL macros to someone with no experience in CL, because there is a
powerful synergy in their advantages, such that you could memorize a list
of their advantages and still not get it, till you have enough experience
with them to become aware of that synergy.
Most of the macro fears you express here are not even significant in CL.
A typo won't redefine a built-in function as a macro, for example. The
kinds of bugs that happen in actual practice with macros are easy to see
and easy to fix. And even if they weren't, the extra effort to fix them
would be worth it, because CL macros are so powerful that they enable one
programmer to do the work of dozens. C macros don't provide any such
power, which should tell you that CL and C macros are two different
usages of the word "macro" with two different meanings.
On May 21, 5:39 am, "eric-and-jane-smith" <·······@nospam.com> wrote:
> Series Expansion <·······@gmail.com> wrote in news:886d0118-9790-45f9-
> ·················@s16g2000vbp.googlegroups.com:
>
> > Another hand-wave. Macros are macros are macros.
>
> That's like saying tools are tools are tools.
Did you have a point?
Macros have certain features in common. So do tools. One can reason
about them without knowing more about the specific type, although with
less information one can draw fewer conclusions. For instance, if all
one knows is that an object is a tool, one cannot immediately infer
that it is heavy. One can however infer that it is useful in some
manner and probably an artifact of human civilization. Likewise with a
macro, one can infer it will be expanded in some manner, replaced with
some deterministic function of its arguments.
> And there are some situations where some tools are known to be dangerous.
> Therefore you want to disallow tools.
I don't want to disallow anything, except possibly illogical arguments
and pointless personal attacks.
Your "leap of logic" here is akin to if I had said that 400-volt 10-
amp electricity is dangerous and that that high a power level would be
unwise to employ in home wiring, and you responded by accusing me of
advocating to have electric power banned entirely.
> You should also keep in mind that when you argue with Lisp novices about
> the advantages and disadvantages of various Lisp features, you aren't
> necessarily learning as much as you think you are.
Are you, then, admitting to be novices? This explains your internal
contradictions and apparent inability to make a good impression or
present a coherent case for preferring Lisp over Java. However, it
prompts a new question: if you are novices, then why have you insisted
on playing the role of a "know-it-all" and why have you been so
certain that it is superior to Java? Your inability to back the latter
up with convincing arguments, and apparent need to resort to personal
attacks to press your points home and even to change the subject
entirely away from Lisp, to me indicates that you have no proof
whatsoever of your claim of its superiority. In which case your
starting and continuing this argument is clearly illogical.
> As I said before, it's useless for us to try to explain the advantages of
> CL macros
Perhaps, but not for the reasons you think. The apparent fact that you
are novices yourselves may have more to do with this.
> there is a powerful synergy in their advantages, such that you could
> memorize a list of their advantages and still not get it, till you have
> enough experience with them to become aware of that synergy.
This borders on an expression of religious faith. Only the initiated
can understand, we cannot or will not explain things to lay persons,
logic is irrelevant, and so forth.
I have little interest in joining your mystery cult, or any other. I
believe in the ability of thinking minds to communicate, explain, and
understand any abstract subject matter, if it is explained coherently
enough; that is, in the power of general-purpose intelligence. This is
diametrically opposed to any belief that there are things that "only
the initiated can understand", or similar statements that have been
implied by some of your assertions.
> Most of the macro fears you express here are not even significant in CL.
It is for each individual user or potential user to judge for himself
what problems are or are not "significant".
> The kinds of bugs that happen in actual practice with macros are easy to
> see and easy to fix.
Extraordinary claims require extraordinary evidence, and as yet you
have furnished nothing of the sort.
> And even if they weren't, the extra effort to fix them
> would be worth it, because CL macros are so powerful that they enable one
> programmer to do the work of dozens.
Extraordinary claims require extraordinary evidence.
> C macros don't provide any such power, which should tell you that CL
> and C macros are two different usages of the word "macro" with two
> different meanings.
Not 100% different, and my objections have been primarily based on
specific knowledge of CL macros. None have yet addressed my
observation that a variable name guaranteed to avoid capture cannot be
reliably computed by any function of a macro's arguments, except for
the case that the arguments contain the entire rest of the code base
aside from the invocation itself and the macro's definition.
On May 23, 9:30 pm, Series Expansion <·······@gmail.com> wrote:
> None have yet addressed my
> observation that a variable name guaranteed to avoid capture cannot be
> reliably computed by any function of a macro's arguments, except for
> the case that the arguments contain the entire rest of the code base
> aside from the invocation itself and the macro's definition.
It can, if the variable name is not a string but a symbol. Symbols
have identity. So I can have two variables with different names
(different symbols) even if the printed representation of the symbols
(their name as a string) is equal.
(eq 'a 'a) ==> T ;same symbol
(eq '#:x '#:x) ==> NIL ;different symbols due to #: syntax
(let ((a '#:x)) (eq a a)) ==> T ;same symbol referenced twice
I can create a unique symbol, store it somewhere, and reference it
multiple times (e.g. as a variable name). The fact it's unique isn't a
function of anything; simply is a new symbol object which is not
reachable through any package, and so it can only be referenced by
holding a pointer to it.
On May 23, 7:30 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 23, 9:30 pm, Series Expansion <·······@gmail.com> wrote:
>
> > None have yet addressed my
> > observation that a variable name guaranteed to avoid capture cannot be
> > reliably computed by any function of a macro's arguments, except for
> > the case that the arguments contain the entire rest of the code base
> > aside from the invocation itself and the macro's definition.
>
> It can, if the variable name is not a string but a symbol.
It cannot. The way in which the name is constructed is irrelevant. The
only way to always construct one that did not match any existing one
in any wider scope would be to have a list of them all, in all wider
scopes. But such a list cannot, in general, be computed solely from
the macro's arguments.
> Symbols have identity. So I can have two variables with different names
> (different symbols) even if the printed representation of the symbols
> (their name as a string) is equal.
You refer to namespaces, or some similar concept. The problem is that
the lexical expansion of the macro will be contained in lexical scopes
that may declare variables the macro has no knowledge of, because they
are not referenced in its arguments. Namespaces, in any form, will not
get you around this problem.
> (eq 'a 'a) ==> T ;same symbol
>
> (eq '#:x '#:x) ==> NIL ;different symbols due to #: syntax
The result of doing this is to make the name useless. It means that if
the macro code expanded to perform:
(let ((#:x arg-value)))
...
(somefunc (#:x))
...
(otherfunc (#:x))
this would not pass arg-value to either somefunc or otherfunc, because
every occurrence of #:x is separate from every other. This completely
defeats the purpose of even having a variable name, which requires
that it can be referred to multiple times.
Thus these #:x symbols are a mere curiosity. They do not provide a
means to avoid multiple evaluation, let alone (except trivially)
variable capture.
> (let ((a '#:x)) (eq a a)) ==> T ;same symbol referenced twice
This does not get around the problem:
(let ((a '#:x)))
(let (*a arg-value))
...
(somefunc (*a))
...
(otherfunc (*a))
(I do not know how to indirect through a, so I used the C-like
notation *a above. It doesn't matter to the point I'm making.)
This may work, getting arg-value into somefunc and otherfunc, but now
if the enclosing scope also uses a variable named a, we have a new
collision.
This is precisely what I was getting at in my previous post on this
subject.
> I can create a unique symbol, store it somewhere, and reference it
> multiple times (e.g. as a variable name).
But to reference the same one multiple times, you need another
variable to refer to it, like the variable named "a" in your second
example above. THAT variable needs a name. If it is another of your
"gensyms", it too needs a variable referring to it, so we eventually
must arrive at a variable that has an ordinary name. And then that
name may become involved in a collision. We are reduced back to the
original problem, the inability of the macro to compute a collision-
safe name solely from its arguments.
> The fact it's unique isn't a function of anything; simply is a new
> symbol object which is not reachable through any package, and so
> it can only be referenced by holding a pointer to it.
A clever attempt and a fine effort, but the collision problem has
simply moved to the name of the variable holding a pointer to it.
As I said before, the introduction of a layer of indirection here does
not solve the problem.
On May 24, 2:50 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> > This completely
> > defeats the purpose of even having a variable name, which requires
> > that it can be referred to multiple times.
>
> If each occurrence of #:x is the exact same symbol, then it's the same
> variable each time. Problem solved.
Problem not solved, as I explained further on in my post.
> >> (let ((a '#:x)) (eq a a)) ==> T ;same symbol referenced twice
>
> > This does not get around the problem:
>
> > (let ((a '#:x)))
> > (let (*a arg-value))
> > ...
> > (somefunc (*a))
> > ...
> > (otherfunc (*a))
>
> > (I do not know how to indirect through a, so I used the C-like
> > notation *a above. It doesn't matter to the point I'm making.)
>
> Try it like this:
>
> (setq code '(let ((x arg-value)) (somefunc x) (otherfunc x)))
>
> Then
>
> (setq new-code (subst '#:x 'x code))
>
> [that is, replace occurences of X (the variable) in code with #:X (a
> different, uninterned symbol...but the same one each time!)] Now
>
> new-code => (let ((#:x arg-value)) (somefunc #:x) (otherfunc #:x))
And you're back where you started. If you pasted that code into the
editor from this news-post, saved it to a file, and compiled it,
that'd be three separate #:xs there.
> > But to reference the same one multiple times, you need another
> > variable to refer to it, like the variable named "a" in your second
> > example above. THAT variable needs a name. If it is another of your
> > "gensyms", it too needs a variable referring to it,
>
> No.
Yes.
> Because macros are not just stupid code templates; they're
> functions.
Not relevant. It does not matter how the macro computes an output such
as
(let ((#:x value)))
...
(func(#:x))
all that matters is that when the compiler compiles the above source
code the #:xs will not be the same.
> So the variable that has has the name of the temporary
> variable is a variable in the macro function, not a variable in the
> expansion.
Almost clever enough to get around it, but it all falls apart when the
"#:x" symbols (perhaps the same at this point) in the macro's output
are substituted for the macro invocation in the source code. Whereupon
they simply become "#:x" occurrences in the source code. Which the
compiler will then regard as distinct.
The only way around this would be for the macro to output somehow
directly into the object code, rather than transform the source code,
and then it would not be a macro anymore by any reasonable definition
of the word. In particular, it would become false in general that
manually expanding a macro invocation in the source code would not
alter the program semantics, which would be a serious violation of the
definition, of the principle of least astonishment, and likely of
several other things.
In fact, such a thing threatens the very sanctity of the definition of
"source code" itself, by implying that Lisp source code is really a
form of rich-text and not plain ASCII and converting it to the latter
loses information. I think it should be apparent how dangerous this
could be.
It follows that if your macros don't avoid variable capture, they're
dangerous, and if they somehow do, they're even MORE dangerous.
I rest my case.
> (defmacro see-what-I-mean (&body whatever)
> (let ((safe-variable (gensym)))
> `(let ((,safe-variable some-value))
> ,@whatever)))
>
> (macroexpand '(see-what-I-mean anything-you-like-here))
>
> => (LET ((#:G1959 SOME-VALUE))
> ANYTHING-YOU-LIKE-HERE)
>
> What do you think you can put in place of ANYTHING-YOU-LIKE-HERE that
> can get access to the variable called #:G1959?
Nothing, but it's a useless example, since there's no subsequent
retrieval of some-value. That gensyms allow you to throw values across
the event horizons of black holes had already been established.
> > must arrive at a variable that has an ordinary name. And then that
> > name may become involved in a collision.
>
> The "ordinary name" in the above example is "safe-variable". But that
> doesn't appear in the macro's expansion, so you can't collide with it.
(defmacro see-what-I-mean (&body whatever)
(let ((safe-variable (gensym)))
`(let ((,safe-variable some-value))
,@whatever
func(,safe-variable)))
(macroexpand '(see-what-I-mean anything-you-like-here))
=> (LET ((#:G1959 SOME-VALUE))
ANYTHING-YOU-LIKE-HERE
FUNC(#:G1959))
and compiling the above three lines will not cause func to be invoked
on some-value, because the #:G1959s are different again.
If they were different to begin with, you're sunk. If they weren't,
and macroexpand made them different, then you're even worse off for
the reasons outlined previously, since macroexpand is now failing to
preserve semantics and macros aren't quite macros. If they weren't,
and macroexpand didn't make them different but copying its output and
pasting it back in did, then you're even worse off than THAT because
now your source code isn't even able to be copied and pasted, or
otherwise manipulated with tools that only know ASCII, without the
semantics sometimes being altered. (And then the apparently-widespread
Lisper preference for emacs over more advanced editors comes into play
in a big way.) Source code that cannot safely be handled using tools
like grep, sed, awk, normal text editors, and so forth is not source
code in my opinion.
On 2009-05-24, Series Expansion <·······@gmail.com> wrote:
>> new-code => (let ((#:x arg-value)) (somefunc #:x) (otherfunc #:x))
>
> And you're back where you started. If you pasted that code into the
> editor from this news-post, saved it to a file, and compiled it,
> that'd be three separate #:xs there.
Then you'd have to RTFM about *print-circle*.
See, you keep assuming that there isn't any more to Lisp than what you have
read so far in this Usenet thread.
>> > But to reference the same one multiple times, you need another
>> > variable to refer to it, like the variable named "a" in your second
>> > example above. THAT variable needs a name. If it is another of your
>> > "gensyms", it too needs a variable referring to it,
>>
>> No.
>
> Yes.
>
>> Because macros are not just stupid code templates; they're
>> functions.
>
> Not relevant. It does not matter how the macro computes an output such
> as
>
> (let ((#:x value)))
> ...
> (func(#:x))
(#:x) means call the function called #:x, rather than evaluate
the variable #:x.
> all that matters is that when the compiler compiles the above source
> code the #:xs will not be the same.
We don't know that. Two #:x symbols could be the same symbol or could
not. If the code is machine generated by a macro, the #:x will be the same
symbol because the macro would have done this:
(let ((x-sym (gensym)))
`(let ((,x-sym value))
(func ,x-sym)))
I.e it would allocate a single symbol and stick it into multiple places
in the generated code. When that code is printed, those will all look like
#:x.
Yes, woe to you if you try to cut and paste that code back into Lisp.
If you want that to work reliably, then you will just have to learn about the
*print-circle* variable in the Lisp printer.
Here is how you can write a Lisp list with three occurences of #:x which really
are the same object:
[1]> '(#1=#:x #1# #1#)
(#:X #:X #:X)
[2]> (eq '#1=#:x '#1#)
T
#1= OBJ means ``the notation of OBJ is to be read normally, but also
remembered by an association with the number 1''.
#1# means ``regurgitate the object that was previously associated with 1''.
And so things like circular references, and multiple occurences of homeless
symbols can be reprented at read-time.
When you enable *print-circle*, the Lisp printer will render objects into this
notation.
[1]> (setf *print-circle* t)
T
[2]> (let ((x (cons 1 2))) (setf (cdr x) x))
#1=(1 . #1#)
See, *print-circle* shows us that circular list has itself as its tail. The ##
notation is capable of backpatching. The whole object can be associated with
#1, but #1# can also occur inside that object. Here, the object is a single
cons notated with the dot notation, and the CDR slot of the cell is the
cell itself (backpointer).
On May 25, 7:08 am, Kaz Kylheku <········@gmail.com> wrote:
> Here is how you can write a Lisp list with three occurences of #:x which really
> are the same object:
>
> [1]> '(#1=#:x #1# #1#)
> (#:X #:X #:X)
>
> [2]> (eq '#1=#:x '#1#)
> T
>
> #1= OBJ means ``the notation of OBJ is to be read normally, but also
> remembered by an association with the number 1''.
>
> #1# means ``regurgitate the object that was previously associated with 1''.
>
> And so things like circular references, and multiple occurences of homeless
> symbols can be reprented at read-time.
>
> When you enable *print-circle*, the Lisp printer will render objects into this
> notation.
>
> [1]> (setf *print-circle* t)
> T
> [2]> (let ((x (cons 1 2))) (setf (cdr x) x))
> #1=(1 . #1#)
>
> See, *print-circle* shows us that circular list has itself as its tail. The ##
> notation is capable of backpatching.
I guess I have to thank Series "The Troll" Expansion for creating a
situation wherein I inadvertantly learned that the #1=OBJ syntax is
useful for more than just circular lists. Thank you, my dear troll.
Now go home and RTFPCL.
- Adlai
On May 25, 5:25 pm, Adlai <·········@gmail.com> wrote:
> I guess I have to thank Series "The Troll" Expansion
I am not a troll.
> for creating a
> situation wherein I inadvertantly learned that the #1=OBJ syntax is
> useful for more than just circular lists. Thank you, my dear troll.
> Now go home and RTFPCL.
You are being rude, incoherent, and irrational.
On May 25, 12:08 am, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-05-24, Series Expansion <·······@gmail.com> wrote:
>
> >> new-code => (let ((#:x arg-value)) (somefunc #:x) (otherfunc #:x))
>
> > And you're back where you started. If you pasted that code into the
> > editor from this news-post, saved it to a file, and compiled it,
> > that'd be three separate #:xs there.
>
> Then you'd have to RTFM about *print-circle*.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Kaz.
> See, you keep assuming that there isn't any more to Lisp than what you have
> read so far in this Usenet thread.
No, I just keep assuming certain baseline, safe assumptions, one of
which is that source code is vanilla ASCII or, at worst (Java),
Unicode.
> > all that matters is that when the compiler compiles the above source
> > code the #:xs will not be the same.
>
> We don't know that. Two #:x symbols could be the same symbol or could
> not.
They can inside the macro processor's brain. Once the output is
incorporated into the in-memory image of the source code and becomes
ordinary text, however, they will be separate.
Put this way: if I type
(foo #:x)
(blah #:x)
into the code and compile it, that's two #:xs.
Macros basically automate transforming pieces of code into other
pieces of code, so if you typed something like that often, you could
get a macro to do it for you, thus avoiding one of the things you
criticize Java for: boilerplate code. So, if a macro generated
(foo #:x)
(blah #:x)
into the code and I compiled it, that should also be two #:xs, since
the macro is supposed to simply be automating the effect of typing
that stuff repeatedly and saving me the bother.
> If the code is machine generated by a macro, the #:x will be the same
> symbol because the macro would have done this:
>
> (let ((x-sym (gensym)))
> `(let ((,x-sym value))
> (func ,x-sym)))
>
> I.e it would allocate a single symbol and stick it into multiple places
> in the generated code.
And when that code is fed to the compiler, it's multiple #:xs again.
Certainly, if you selected the above and pasted it in, it would be.
And certainly, manually replacing a macro invocation in your source
file with its expansion should not change the semantics of that code
(though it would invite stuff-getting-out-of-synch problems down the
line).
> Yes, woe to you if you try to cut and paste that code back into Lisp.
Cutting and pasting code from one sourcefile to another shouldn't
alter semantics!! modulo the effects of enclosing scopes and
contextual imports.
> When you enable *print-circle*, the Lisp printer will render objects into this
> notation.
>
> [1]> (setf *print-circle* t)
> T
> [2]> (let ((x (cons 1 2))) (setf (cdr x) x))
> #1=(1 . #1#)
>
> See, *print-circle* shows us that circular list has itself as its tail. The ##
> notation is capable of backpatching. The whole object can be associated with
> #1, but #1# can also occur inside that object. Here, the object is a single
> cons notated with the dot notation, and the CDR slot of the cell is the
> cell itself (backpointer).
This hasn't solved your problem. Now the #1 in the output is the
potential source of a collision!
Series Expansion <·······@gmail.com> writes:
> On May 25, 12:08��am, Kaz Kylheku <········@gmail.com> wrote:
> > See, you keep assuming that there isn't any more to Lisp than what you have
> > read so far in this Usenet thread.
>
> No, I just keep assuming certain baseline, safe assumptions, one of
> which is that source code is vanilla ASCII or, at worst (Java),
> Unicode.
The whole problem with this series of threads is that you keep making
assumptions about lisp that are patently incorrect. And then you base
arguments on those incorrect assumptions.
When experienced lisp programmers point out to you that your assumptions
are incorrect, you then persist in trying to defend those assumptions,
instead of either accepting the correction in assumptions.
You see, lisp really is a language that works differently. If you can't
try to learn about lisp starting from a premise that the language works
differently, then your understanding of it is doomed. And so is any
credible technical critique, because the critique will be based on
unsound premises -- namely your limited imagination about how it can be
done.
Now, oddly enough, you seem quite willing to blithely assume that the
language MUST work in ways that make it impossible for the language to
actually work the way that everyday users of the language use it. So,
you are, of course, free to continue making unwarranted assumptions
based on your ignorance of the actual workings of Common Lisp.
But you then miss some of the greatest strengths of the language, the
chief one (in this particular thread) being that macros get to operate
on the structure of the language rather than its surface text. To put
that into more Java-friendly terms, it means that macros operate on the
parse-tree of the program, rather than on the program itself. So there
are manipulations possible that are not possible using just the text.
That is a real power.
Now it so happens that lisp uses a serialization of the structure of
lisp programs (although it's not called a "serialization" in lisp) that
can be used to reconstruct the structure of the source code. It can, in
fact, recreate the structure of any readable lisp object, including
circular structures.
The real problem with a lot of the argumentation in this thread is that
the objections were problems that either never existed or for which
problems were found long ago. There are some real benefits in having a
language with 50 years of development effort behind it (I'm speaking
here of lisp in general). And it seems rather silly to claim that such
a long-lived language absolutely doesn't work, and can't work the way
that the specification says it does.
I suppose that would be quite a hoax, if the lisp folks could pull it
off. To have a language that doesn't really work, but for which we have
a wide array of talented people who seem to agree that it really does
work. And to have them agree in their description in so much technical
detail is truly astonishing.
--
Thomas A. Russ, USC/Information Sciences Institute
On 2009-05-26, Thomas A. Russ <···@sevak.isi.edu> wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 25, 12:08��am, Kaz Kylheku <········@gmail.com> wrote:
>
>> > See, you keep assuming that there isn't any more to Lisp than what you have
>> > read so far in this Usenet thread.
>>
>> No, I just keep assuming certain baseline, safe assumptions, one of
>> which is that source code is vanilla ASCII or, at worst (Java),
>> Unicode.
>
> The whole problem with this series of threads is that you keep making
> assumptions about lisp that are patently incorrect. And then you base
> arguments on those incorrect assumptions.
A ``safe assumption'' is in fact another word for a ``fact''. All other
assumptions are mere suppositions pulled from thin air (or, in worse
cases, from someone's ass: hence ass-umption).
Series Expansion cannot tell the difference between a fact, and something
he pulled from his ass. He will dispute the former, and regard the latter
as a safe assumption.
> When experienced lisp programmers point out to you that your assumptions
> are incorrect, you then persist in trying to defend those assumptions,
> instead of either accepting the correction in assumptions.
Not really. The above is the behavior of the Seamus MacRae identity.
This one works slightly differently. It accepts those facts, but then it
augments those new facts by pulling more assumptions out of nowhere.
The game plan is obvious: treat the debate as a game of chess, in which
the only information content is the current configuration of the board,
your color, whose turn it is, and the set of legal moves.
In making your next move, heuristics is fair game. Sacrificing truth
here and there is like losing a pawn.
The basic iteration is: gather the facts from the debate, and make up new
assumptions. Present the assumptions blankly, as if they were facts. When these
are challenged, accuse the opponents of personal attack. But accept some of
the facts, and iterate.
The name Series Expansion, in fact, is deliberately chosen to represent this
behavior. What is a series expansion? It's a dull, infinite, repetitive
representation of something compact and obvious. No finite portion of the
expansion is true; there is always another term to add to make it more
complete, and that term is predictable. It's so predictable that nobody wants
to add another term after a while. They'd rather move on, or have everyone
refer to the generating closed-form expression. So you must /goad/ others into
writing the next term. You do this by writing an incorrect one, and getting
them to correct it.
How about ``Seamus Macrae''? The given name portion is cleearly a deliberate
farce, since the name means ``modest'' or ``bashful''. MacRae is probably a
play on the word macro (another reference to expansion, note).
Thus, ``Shameful Macro'' -> ``Seamus MacRae''. Wherever he appears,
approximately the same bullshit is substituted, with no possibility
of redefinition.
On 2009-05-26 15:33:19 -0400, Kaz Kylheku <········@gmail.com> said:
> The name Series Expansion, in fact, is deliberately chosen to represent this
> behavior. What is a series expansion? It's a dull, infinite, repetitive
> representation of something compact and obvious. No finite portion of the
> expansion is true; there is always another term to add to make it more
> complete, and that term is predictable. It's so predictable that nobody wants
> to add another term after a while. They'd rather move on, or have everyone
> refer to the generating closed-form expression. So you must /goad/ others into
> writing the next term. You do this by writing an incorrect one, and getting
> them to correct it.
>
> How about ``Seamus Macrae''? The given name portion is cleearly a deliberate
> farce, since the name means ``modest'' or ``bashful''. MacRae is probably a
> play on the word macro (another reference to expansion, note).
> Thus, ``Shameful Macro'' -> ``Seamus MacRae''. Wherever he appears,
> approximately the same bullshit is substituted, with no possibility
> of redefinition.
Another comp.lang.lisp first - deconstructionist literary criticism of
troll posts. Brilliant!
--
Raffael Cavallaro, Ph.D.
On May 26, 5:35 pm, Raffael Cavallaro
<················@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-05-26 15:33:19 -0400, Kaz Kylheku <········@gmail.com> said:
> >The name Series Expansion, in fact, is deliberately chosen to represent this
> > behavior.
It is not. I had no idea that you existed, let alone would exhibit
"this behavior", when I chose that name.
> > [namecalling, aimed at myself and, in absentia, at Seamus MacRae]
>
> Another comp.lang.lisp first - deconstructionist literary criticism of
> troll posts. Brilliant!
His is certainly a troll post, but I did not see any deconstructionist
literary criticism of it.
On May 26, 3:33 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-05-26, Thomas A. Russ <····@sevak.isi.edu> wrote:
> > Series Expansion <·······@gmail.com> writes:
> >> On May 25, 12:08 am, Kaz Kylheku <········@gmail.com> wrote:
> >> > See, you keep assuming that there isn't any more to Lisp than what you have
> >> > read so far in this Usenet thread.
> >> No, I just keep assuming certain baseline, safe assumptions, one of
> >> which is that source code is vanilla ASCII or, at worst (Java),
> >> Unicode.
>
> > The whole problem with this series of threads is that you keep [lying]
I do not.
> A ``safe assumption'' is in fact another word for a ``fact''. All other
> assumptions are mere suppositions pulled from thin air (or, in worse
> cases, from someone's ass: hence ass-umption).
This vulgarity is not helping your case, or your credibility. I do not
understand why several of you are apparently incapable of disagreeing
with someone in a civil fashion, without resort to name-calling or
expletives.
> Series Expansion cannot tell the difference between a fact, and something
> he pulled from his ass.
This is incorrect.
> > When experienced lisp programmers [call me names], you then persist in
> > trying to defend
As any rational person would.
> Not really. The above is the behavior of the Seamus MacRae identity.
Why do you refer to people named X as "the X identity"? Normal human
beings will simply use the name X.
> This one works slightly differently.
Please don't tell me you are some sort of paranoid or delusional
psychotic who believes all the other people in the world are
"identities" of some single master entity constantly plotting against
you?
Because I don't think we have a cure for that one yet.
> It accepts those facts, but then it [etc.]
I am a human being, not some pod person from outer space. Please refer
to me as "he".
> The game plan is obvious: treat the debate as a game of chess, in which
> the only information content is the current configuration of the board,
> your color, whose turn it is, and the set of legal moves.
Is that what you're doing? It explains a few things, though it also
leaves much still mysterious.
> In making your next move, heuristics is fair game. Sacrificing truth
> here and there is like losing a pawn.
That would explain why you and Thomas show a penchant for lying,
especially about me.
> The name Series Expansion, in fact, is deliberately chosen to represent this
> behavior.
No, it is not. How could I possibly have anticipated your behavior
when I first created the account, years ago? I'd never heard of people
behaving like you do at that time.
> [insults]
These tiresome personal attacks do not constitute a rational argument
in favor of either Lisp or Java, Kaz.
> How about ``Seamus Macrae''?
How about him? I don't see that he's at all relevant here.
> The given name portion is cleearly a deliberate farce, since the name
> means ``modest'' or ``bashful''. MacRae is probably a play on the word
> macro (another reference to expansion, note).
Teleology now? By what mechanism are you proposing that his parents,
however many decades ago, would have anticipated this turn of events
and given him a name that resembles "macro"? Or rather, his ancestors
perhaps thousands of years back, whenever the MacRae clan got its
start in the mists of Ireland or Scotland or wherever it is that
MacRaes come from.
Doctor Who's TARDIS?
Gimme a break.
> [calls Seamus names]
Why? He isn't here, he isn't bothering you, why attack him like that?
Your behavior is truly baffling. It will take a major research efforts
by the world's top psychiatrists to figure out what makes you tick.
Series Expansion wrote:
> On May 26, 3:33 pm, Kaz Kylheku <········@gmail.com> wrote:
>> Not really. The above is the behavior of the Seamus MacRae identity.
>
> Why do you refer to people named X as "the X identity"?
Because you are known for using multiple identities.
Arne
On Jul 11, 2:28 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On May 26, 3:33 pm, Kaz Kylheku <········@gmail.com> wrote:
> >> Not really. The above is the behavior of the Seamus MacRae identity.
>
> > Why do you refer to people named X as "the X identity"?
>
> Because you are known for using multiple identities.
I am not.
On May 26, 2:54 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 25, 12:08Ž am, Kaz Kylheku <········@gmail.com> wrote:
> > > See, you keep assuming that there isn't any more to Lisp than what you have
> > > read so far in this Usenet thread.
>
> > No, I just keep assuming certain baseline, safe assumptions, one of
> > which is that source code is vanilla ASCII or, at worst (Java),
> > Unicode.
>
> The whole problem with this series of threads is that you keep [lying]
I do not. You do.
By the way, nice attempt to badmouth me behind my back. It failed.
> When experienced lisp programmers [call me names], you then persist in
> trying to defend
As would any rational individual that came under attack.
> [trimmed a lot of melodrama about how I'm "doomed"]
> your limited imagination
> your ignorance
> you then miss
Argumentum ad hominem again? So tiresome.
> the objections were problems that either never existed or for which
> problems were found long ago.
Oh, yes indeedy, problems were indeed found for your earlier problems.
And those in turn were on earlier problems, and so on and so on ad
infinitum.
> I suppose that would be quite a hoax, if the lisp folks could pull it
> off. To have a language that doesn't really work, but for which we have
> a wide array of talented people who seem to agree that it really does
> work. And to have them agree in their description in so much technical
> detail is truly astonishing.
Apparently you've never gone to a Star Trek convention.
Regardless, I never claimed that it couldn't work at all. That is your
straw-man. I merely claimed that there were some difficulties that
were going to be difficult to avoid, other than by abiding by the age-
old advice, "avoid macros".
On May 24, 10:02 pm, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 24, 2:50 am, Paul Foley <····@below.invalid> (http://
> > public.xdi.org/=pf) wrote:
> >> If each occurrence of #:x is the exact same symbol, then it's the same
> >> variable each time. Problem solved.
>
> > Problem not solved, as I explained further on in my post.
>
> Yes
OK, now that that's straightened out ...
> >> Try it like this:
>
> >> (setq code '(let ((x arg-value)) (somefunc x) (otherfunc x)))
>
> >> Then
>
> >> (setq new-code (subst '#:x 'x code))
>
> >> [that is, replace occurences of X (the variable) in code with #:X (a
> >> different, uninterned symbol...but the same one each time!)] Now
>
> >> new-code => (let ((#:x arg-value)) (somefunc #:x) (otherfunc #:x))
>
> > And you're back where you started. If you pasted that code into the
> > editor from this news-post, saved it to a file, and compiled it,
> > that'd be three separate #:xs there.
>
> Yes..../if/ I pasted it into a text editor, saved it to a file, and
> compiled it, that'd be three separate #:xs there.
And of course a macro processor is supposed to have the same effect:
as though it made its substitution of the macro's output for the
macro's invocation in the source code, after which the compiler
compiles said source code.
> But I wouldn't do that -- I'd compile it in the same Lisp image I did the
> substitution in, where there's only one #:x, and then I wouldn't have a
> problem.
Incoherent. The Lisp image is something that exists once you have a
compiled program and you run it, or you run it in the interpreter to
test it.
> >> Because macros are not just stupid code templates; they're
> >> functions.
>
> > Not relevant. It does not matter how the macro computes an output such
> > as
>
> > (let ((#:x value)))
> > ...
> > (func(#:x))
>
> > all that matters is that when the compiler compiles the above source
> > code the #:xs will not be the same.
>
> Unless you're using Lisp, in which case they will.
As already explained, they won't.
> >> So the variable that has has the name of the temporary
> >> variable is a variable in the macro function, not a variable in the
> >> expansion.
>
> > Almost clever enough to get around it, but it all falls apart when the
> > "#:x" symbols (perhaps the same at this point) in the macro's output
> > are substituted for the macro invocation in the source code. Whereupon
> > they simply become "#:x" occurrences in the source code. Which the
> > compiler will then regard as distinct.
>
> It would, if the source code were text. But it isn't
But it must be. Source code MUST be text. It's not permitted to be
something else, or the sky falls, grep can't be used to search your
source tree, sed and non-Lisp-aware text editors can't safely
manipulate your sources, aliens invade, terminators come back in time
for you, Windows Indexing Service can't search into your source files,
and other such disasters.
> > In fact, such a thing threatens the very sanctity of the definition of
> > "source code" itself, by implying that Lisp source code is really a
> > form of rich-text and not plain ASCII and converting it to the latter
> > loses information.
>
> It's not "rich-text"; it's not *text* at all. It's Lisp objects:
> lists, symbols, numbers, etc. And yes, of course serializing it to
> ASCII loses information.
This is disastrous. Source code should not be that way. Rich text is
bad enough but you're implying it's actually BINARY. I'd like to know
who thought THAT was a good idea.
> >> The "ordinary name" in the above example is "safe-variable". But that
> >> doesn't appear in the macro's expansion, so you can't collide with it.
>
> > (defmacro see-what-I-mean (&body whatever)
> > (let ((safe-variable (gensym)))
> > `(let ((,safe-variable some-value))
> > ,@whatever
> > func(,safe-variable)))
> > (macroexpand '(see-what-I-mean anything-you-like-here))
>
> > => (LET ((#:G1959 SOME-VALUE))
> > ANYTHING-YOU-LIKE-HERE
> > FUNC(#:G1959))
>
> > and compiling the above three lines will not cause func to be invoked
> > on some-value, because the #:G1959s are different again.
>
> The syntax is wrong
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul.
> but if you fix the syntax it /will/ cause FUNC to
> be invoked on some-value because the #:G1959s /are/ the same.
No, they aren't. Try pasting that code at your REPL if you think
otherwise.
> > semantics sometimes being altered. (And then the apparently-widespread
> > Lisper preference for emacs over more advanced editors comes into play
>
> "more advanced editors"...hahah, good one!
It's been repeatedly admitted by emacs PROPONENTS that it is at least
ten years behind the times, interface-wise. (My own personal
experience suggests a value closer to 20.)
Regardless, it is a *text* editor. If, as you say, the source code for
Lisp programs is *not text*, then, without a special-purpose NON-text
editor for them, you're up the proverbial creek.
On May 26, 3:08 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> >> Yes..../if/ I pasted it into a text editor, saved it to a file, and
> >> compiled it, that'd be three separate #:xs there.
>
> > And of course a macro processor is supposed to have the same effect:
> > as though it made its substitution of the macro's output for the
> > macro's invocation in the source code, after which the compiler
> > compiles said source code.
>
> Yes...since the "macro processor" is Lisp, and it doesn't attempt to
> pointlessly write the expansion out to a file only to read it back in
> again, it works fine.
That does not follow. Whether the preprocessed source code is saved to
disk or is passed directly to the compiler in main memory makes no
difference. Source code is source code, and if two successive
occurrences of #:x in source code refer to two different variables,
then two successive occurrences of #:x refer to two different
variables, even if they referred to one while still inside the macro
processor's internal representation of the code. When that
representation is flattened again into source code prior to
compilation, they become distinct. Saving it to a file or not has
nothing to do with it.
> >> > all that matters is that when the compiler compiles the above source
> >> > code the #:xs will not be the same.
>
> >> Unless you're using Lisp, in which case they will.
>
> > As already explained, they won't.
>
> Odd that it seems to have been working on a daily basis for thousands
> of people for several decades.
A claim for which we have only your word, versus a freight of logic
proving otherwise.
> >> >> So the variable that has has the name of the temporary
> >> >> variable is a variable in the macro function, not a variable in the
> >> >> expansion.
>
> >> > Almost clever enough to get around it, but it all falls apart when the
> >> > "#:x" symbols (perhaps the same at this point) in the macro's output
> >> > are substituted for the macro invocation in the source code. Whereupon
> >> > they simply become "#:x" occurrences in the source code. Which the
> >> > compiler will then regard as distinct.
>
> >> It would, if the source code were text. But it isn't
>
> > But it must be. Source code MUST be text. It's not permitted to be
> > something else,
>
> "Not permitted"? Mad as a hatter, aren't you!?
No, I am not. I am merely reiterating common sense. Something that you
apparently completely lack.
> >> > semantics sometimes being altered. (And then the apparently-widespread
> >> > Lisper preference for emacs over more advanced editors comes into play
>
> >> "more advanced editors"...hahah, good one!
>
> > It's been repeatedly admitted by emacs PROPONENTS that it is at least
> > ten years behind the times, interface-wise. (My own personal
> > experience suggests a value closer to 20.)
>
> I've never seen an editor that comes close to Emacs, in terms of
> usability.
You must have "usability" confused with something else, or else
something else confused with emacs. No application that requires a
four-page cheat sheet to even begin using productively merits any
awards on the basis of usability, except perhaps for Worst Ever or
similar "awards" of negative value. Cheat sheets went out with
Wordstar, break-dancing, and Vanilla Ice.
Series Expansion <·······@gmail.com> writes:
> On May 26, 3:08�am, Paul Foley <····@below.invalid> (http://
> public.xdi.org/=pf) wrote:
>> Series Expansion <·······@gmail.com> writes:
>> >> Yes..../if/ I pasted it into a text editor, saved it to a file, and
>> >> compiled it, that'd be three separate #:xs there.
>>
>> > And of course a macro processor is supposed to have the same effect:
>> > as though it made its substitution of the macro's output for the
>> > macro's invocation in the source code, after which the compiler
>> > compiles said source code.
>>
>> Yes...since the "macro processor" is Lisp, and it doesn't attempt to
>> pointlessly write the expansion out to a file only to read it back in
>> again, it works fine.
>
> That does not follow. Whether the preprocessed source code is saved to
> disk or is passed directly to the compiler in main memory makes no
> difference. Source code is source code, and if two successive
> occurrences of #:x in source code refer to two different variables,
> then two successive occurrences of #:x refer to two different
> variables, even if they referred to one while still inside the macro
> processor's internal representation of the code. When that
> representation is flattened again into source code prior to
> compilation, they become distinct.
It doesn't get "flattened again into source code prior to
compilation"; the "macro processor"(that is, Lisp)'s "internal
representation of the code" /is/ the source code. The compiler
operates on that very same "internal representation" (i.e., the source
code).
>> >> > all that matters is that when the compiler compiles the above source
>> >> > code the #:xs will not be the same.
>>
>> >> Unless you're using Lisp, in which case they will.
>>
>> > As already explained, they won't.
>>
>> Odd that it seems to have been working on a daily basis for thousands
>> of people for several decades.
>
> A claim for which we have only your word, versus a freight of logic
> proving otherwise.
ROTFL
"Are you accusing me of lying? These tiresome personal attacks do not
constitute rational arguments in favor of Java, 'Series'"
On May 27, 12:52 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 26, 3:08 am, Paul Foley <····@below.invalid> (http://
> > public.xdi.org/=pf) wrote:
> >> Series Expansion <·······@gmail.com> writes:
> >> >> Yes..../if/ I pasted it into a text editor, saved it to a file, and
> >> >> compiled it, that'd be three separate #:xs there.
>
> >> > And of course a macro processor is supposed to have the same effect:
> >> > as though it made its substitution of the macro's output for the
> >> > macro's invocation in the source code, after which the compiler
> >> > compiles said source code.
>
> >> Yes...since the "macro processor" is Lisp, and it doesn't attempt to
> >> pointlessly write the expansion out to a file only to read it back in
> >> again, it works fine.
>
> > That does not follow. Whether the preprocessed source code is saved to
> > disk or is passed directly to the compiler in main memory makes no
> > difference. Source code is source code, and if two successive
> > occurrences of #:x in source code refer to two different variables,
> > then two successive occurrences of #:x refer to two different
> > variables, even if they referred to one while still inside the macro
> > processor's internal representation of the code. When that
> > representation is flattened again into source code prior to
> > compilation, they become distinct.
>
> It doesn't get "flattened again into source code prior to
> compilation"
That would be incorrect behavior, if so. The compiler, after all, by
definition of "compiler" deals in source code, so if your statement
were correct, the output of a macro would not be in a form amenable to
being compiled.
> the "macro processor"(that is, Lisp)'s "internal
> representation of the code" /is/ the source code.
This statement is incoherent. The source code, by definition, is the
contents of the source files fed to the compiler, in the case of
Common Lisp e.g. by executing compile-file on them from a REPL.
> The compiler operates on that very same "internal representation" (i.e., the
> source code).
This, too, is incoherent, for largely the same reasons. Source code
and compiler internal representations differ by definition, unless the
internal representation at issue is something trivial, such as an
ASCII buffer read from a source file.
> >> >> > all that matters is that when the compiler compiles the above source
> >> >> > code the #:xs will not be the same.
>
> >> >> Unless you're using Lisp, in which case they will.
>
> >> > As already explained, they won't.
>
> >> Odd that it seems to have been working on a daily basis for thousands
> >> of people for several decades.
>
> > A claim for which we have only your word, versus a freight of logic
> > proving otherwise.
>
> ROTFL
I do not find your incoherent arguments, random personal attacks, and
other behaviors amusing. Rather, they concern me, as they may be early
signs of any of a number of serious degenerative neurological
conditions, for which you appear to be making no effort to seek
treatment.
I have deleted your misquotation of the remainder of my post. Suffice
it to say, you are doing a poor job of proving Lisp superior to Java.
And to add to your troubles, now the Lisp version of "computed goto"
has come to light. You have, as my colleagues would put it, "your work
cut out for you".
On May 28, 1:43 am, Series Expansion <·······@gmail.com> wrote:
> On May 27, 12:52 am, Paul Foley <····@below.invalid> (http://
>
>
>
> public.xdi.org/=pf) wrote:
> > Series Expansion <·······@gmail.com> writes:
> > > On May 26, 3:08 am, Paul Foley <····@below.invalid> (http://
> > > public.xdi.org/=pf) wrote:
> > >> Series Expansion <·······@gmail.com> writes:
> > >> >> Yes..../if/ I pasted it into a text editor, saved it to a file, and
> > >> >> compiled it, that'd be three separate #:xs there.
>
> > >> > And of course a macro processor is supposed to have the same effect:
> > >> > as though it made its substitution of the macro's output for the
> > >> > macro's invocation in the source code, after which the compiler
> > >> > compiles said source code.
>
> > >> Yes...since the "macro processor" is Lisp, and it doesn't attempt to
> > >> pointlessly write the expansion out to a file only to read it back in
> > >> again, it works fine.
>
> > > That does not follow. Whether the preprocessed source code is saved to
> > > disk or is passed directly to the compiler in main memory makes no
> > > difference. Source code is source code, and if two successive
> > > occurrences of #:x in source code refer to two different variables,
> > > then two successive occurrences of #:x refer to two different
> > > variables, even if they referred to one while still inside the macro
> > > processor's internal representation of the code. When that
> > > representation is flattened again into source code prior to
> > > compilation, they become distinct.
>
> > It doesn't get "flattened again into source code prior to
> > compilation"
>
> That would be incorrect behavior, if so. The compiler, after all, by
> definition of "compiler" deals in source code, so if your statement
> were correct, the output of a macro would not be in a form amenable to
> being compiled.
>
Most compilers tokenize the source file prior to compilation.
You can think of macros as manipulating the tokens.
(It just happens that lisp is very amenable to this sort of thing).
> > the "macro processor"(that is, Lisp)'s "internal
> > representation of the code" /is/ the source code.
>
> This statement is incoherent. The source code, by definition, is the
> contents of the source files fed to the compiler, in the case of
> Common Lisp e.g. by executing compile-file on them from a REPL.
>
Right.
> > The compiler operates on that very same "internal representation" (i.e., the
> > source code).
>
> This, too, is incoherent, for largely the same reasons. Source code
> and compiler internal representations differ by definition, unless the
> internal representation at issue is something trivial, such as an
> ASCII buffer read from a source file.
>
Right, but the internal representations are isomorphic to the source
file, so with lisp the line is 'blurry'.
(Java is to JVM as lisp is to lisp.)
(Although lisp then goes through another pass to a lower level
'virtual machine' (i.e. assembler, JVM, gcc in some cases))
On May 28, 2:04 am, ··················@gmail.com wrote:
> On May 28, 1:43 am, Series Expansion <·······@gmail.com> wrote:
> > On May 27, 12:52 am, Paul Foley <····@below.invalid> (http://public.xdi.org/=pf) wrote:
> > > Series Expansion <·······@gmail.com> writes:
> > > > That does not follow. Whether the preprocessed source code is saved to
> > > > disk or is passed directly to the compiler in main memory makes no
> > > > difference. Source code is source code, and if two successive
> > > > occurrences of #:x in source code refer to two different variables,
> > > > then two successive occurrences of #:x refer to two different
> > > > variables, even if they referred to one while still inside the macro
> > > > processor's internal representation of the code. When that
> > > > representation is flattened again into source code prior to
> > > > compilation, they become distinct.
>
> > > It doesn't get "flattened again into source code prior to
> > > compilation"
>
> > That would be incorrect behavior, if so. The compiler, after all, by
> > definition of "compiler" deals in source code, so if your statement
> > were correct, the output of a macro would not be in a form amenable to
> > being compiled.
>
> Most compilers tokenize the source file prior to compilation.
> You can think of macros as manipulating the tokens.
That seems acceptable, but it fails to grant macros miraculous powers
of prescience.
> > > The compiler operates on that very same "internal representation" (i.e., the
> > > source code).
>
> > This, too, is incoherent, for largely the same reasons. Source code
> > and compiler internal representations differ by definition, unless the
> > internal representation at issue is something trivial, such as an
> > ASCII buffer read from a source file.
>
> Right, but the internal representations are isomorphic to the source
> file, so with lisp the line is 'blurry'.
I have proven mathematically that if the internal representations ARE
isomorphic to the source file then your asserted miraculous properties
of gensyms are physically impossible.
> (Java is to JVM as lisp is to lisp.)
>
> (Although lisp then goes through another pass to a lower level
> 'virtual machine' (i.e. assembler, JVM, gcc in some cases))
In other words, Java is really to JVM as Lisp is to assembler, JVM, or
even C code.
(Lisp on the JVM. That's gotta be a match made in hell! The JVM is
full of checks and validations, which I'm sure you Lispers would
consider as anal as Java's type safety and similar "bondage and
discipline". I can just imagine the methods needed to tie it up and
gag it into accepting Lisp-derived bytecodes without blowing up in
some manner.)
On May 28, 11:03 pm, Series Expansion <·······@gmail.com> wrote:
> On May 28, 2:04 am, ··················@gmail.com wrote:
>
>
>
> > On May 28, 1:43 am, Series Expansion <·······@gmail.com> wrote:
> > > On May 27, 12:52 am, Paul Foley <····@below.invalid> (http://public.xdi.org/=pf) wrote:
> > > > Series Expansion <·······@gmail.com> writes:
> > > > > That does not follow. Whether the preprocessed source code is saved to
> > > > > disk or is passed directly to the compiler in main memory makes no
> > > > > difference. Source code is source code, and if two successive
> > > > > occurrences of #:x in source code refer to two different variables,
> > > > > then two successive occurrences of #:x refer to two different
> > > > > variables, even if they referred to one while still inside the macro
> > > > > processor's internal representation of the code. When that
> > > > > representation is flattened again into source code prior to
> > > > > compilation, they become distinct.
>
> > > > It doesn't get "flattened again into source code prior to
> > > > compilation"
>
> > > That would be incorrect behavior, if so. The compiler, after all, by
> > > definition of "compiler" deals in source code, so if your statement
> > > were correct, the output of a macro would not be in a form amenable to
> > > being compiled.
>
> > Most compilers tokenize the source file prior to compilation.
> > You can think of macros as manipulating the tokens.
>
> That seems acceptable, but it fails to grant macros miraculous powers
> of prescience.
>
I don't think any computer language ever grant miraculous powers.
You have to recognize that for lisp, 'tokenizing' the code turns the
code into lisp objects (more or less).
> > > > The compiler operates on that very same "internal representation" (i.e., the
> > > > source code).
>
> > > This, too, is incoherent, for largely the same reasons. Source code
> > > and compiler internal representations differ by definition, unless the
> > > internal representation at issue is something trivial, such as an
> > > ASCII buffer read from a source file.
>
> > Right, but the internal representations are isomorphic to the source
> > file, so with lisp the line is 'blurry'.
>
> I have proven mathematically that if the internal representations ARE
> isomorphic to the source file then your asserted miraculous properties
> of gensyms are physically impossible.
>
Isomorphic isn't identical,
Symbols are first class objects.
I'd like to see your proof, it sounds quite impressive.
> > (Java is to JVM as lisp is to lisp.)
>
> > (Although lisp then goes through another pass to a lower level
> > 'virtual machine' (i.e. assembler, JVM, gcc in some cases))
>
> In other words, Java is really to JVM as Lisp is to assembler, JVM, or
> even C code.
I think you could say that both statements are true.
> (Lisp on the JVM. That's gotta be a match made in hell! The JVM is
> full of checks and validations, which I'm sure you Lispers would
> consider as anal as Java's type safety and similar "bondage and
> discipline". I can just imagine the methods needed to tie it up and
> gag it into accepting Lisp-derived bytecodes without blowing up in
> some manner.)
I believe you have to do all sorts of strange things with classes and
casting.
I really wouldn't know beyond the fact that it is doable.
On May 29, 12:07 am, ··················@gmail.com wrote:
> On May 28, 11:03 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 28, 2:04 am, ··················@gmail.com wrote:
> > > Most compilers tokenize the source file prior to compilation.
> > > You can think of macros as manipulating the tokens.
>
> > That seems acceptable, but it fails to grant macros miraculous powers
> > of prescience.
>
> I don't think any computer language ever grant miraculous powers.
>
> You have to recognize that
You have to recognize that taking a condescending tone does not
encourage others to listen to you.
> for lisp, 'tokenizing' the code turns the code into lisp objects (more
> or less).
Not relevant.
> > > Right, but the internal representations are isomorphic to the source
> > > file, so with lisp the line is 'blurry'.
>
> > I have proven mathematically that if the internal representations ARE
> > isomorphic to the source file then your asserted miraculous properties
> > of gensyms are physically impossible.
>
> Isomorphic isn't identical,
> Symbols are first class objects.
The claim made regarding gensyms cannot be correct unless the program
structure in memory (your abstract syntax tree) is not actually a tree
but a directed acyclic graph with undirected cycles. Since the parse
tree of any text source file will be a bona fide tree, it follows that
if the claim regarding gensyms is true, the two representations are
NOT isomorphic; conversely, if as you have claimed the representations
ARE isomorphic the gensym claim is bogus.
> I'd like to see your proof, it sounds quite impressive.
It was in an earlier post of mine. More than one of them in fact; I
kept having to repeat it for the hard of hearing.
> > > (Java is to JVM as lisp is to lisp.)
>
> > > (Although lisp then goes through another pass to a lower level
> > > 'virtual machine' (i.e. assembler, JVM, gcc in some cases))
>
> > In other words, Java is really to JVM as Lisp is to assembler, JVM, or
> > even C code.
>
> I think you could say that both statements are true.
No.
Series Expansion <·······@gmail.com> writes:
>> I'd like to see your proof, it sounds quite impressive.
>
> It was in an earlier post of mine. More than one of them in fact; I
> kept having to repeat it for the hard of hearing.
Your idea of "proof" seems to taken from Lewis Carroll: "what i tell
you three times is true"
On May 30, 12:22 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> Series Expansion <·······@gmail.com> writes:
> >> I'd like to see your proof, it sounds quite impressive.
>
> > It was in an earlier post of mine. More than one of them in fact; I
> > kept having to repeat it for the hard of hearing.
>
> Your idea of "proof" seems to taken from Lewis Carroll: "what i tell
> you three times is true"
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul.
Series Expansion <·······@gmail.com> writes:
> The claim made regarding gensyms cannot be correct unless the program
> structure in memory (your abstract syntax tree) is not actually a tree
> but a directed acyclic graph with undirected cycles. Since the parse
> tree of any text source file will be a bona fide tree, it follows that
> if the claim regarding gensyms is true, the two representations are
> NOT isomorphic; conversely, if as you have claimed the representations
> ARE isomorphic the gensym claim is bogus.
Well, for starters, let's clear up some more misconceptions here.
(1) There is no requirement that the "parse tree" for lisp source has to
be a true tree (as in a directed, acyclic graph). Lisp has read
(and write) syntax for circular structures that allows a source code
to not be a tree at all. But that is mostly an aside, since it
isn't the fundamental misconception.
(2) The fundamental misconception is not realizing the impact that the
ability to execute code as part of the macro-expansion has. It is
precisely this ability to execute code that gives Lisp macros the
power that Series Expansion likes to describe as "magical".
The GENSYM that is created for use as the name of a variable DOESN'T
EXIST IN THE SOURCE CODE. It is created at macro-expansion time by
the running of code in the macro-expansion function. So, it is
quite easy to create a new, unique symbol object. And by not
registering the symbol in a package, there is no way to look it up
by name.
>
> It was in an earlier post of mine. More than one of them in fact; I
> kept having to repeat it for the hard of hearing.
Except that this proof depends on assumptions that are just not true.
And as everyone knows, a proof that proceeds from false premises
establishes nothing.
--
Thomas A. Russ, USC/Information Sciences Institute
On Jun 1, 2:05 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > The claim made regarding gensyms cannot be correct unless the program
> > structure in memory (your abstract syntax tree) is not actually a tree
> > but a directed acyclic graph with undirected cycles. Since the parse
> > tree of any text source file will be a bona fide tree, it follows that
> > if the claim regarding gensyms is true, the two representations are
> > NOT isomorphic; conversely, if as you have claimed the representations
> > ARE isomorphic the gensym claim is bogus.
>
> Well, for starters, let's clear up some more [insult deleted]
Let's not.
I have no interest in your ad hominem "arguments" so you might as well
quit them.
> (1) There is no requirement that the "parse tree" for lisp source has to
> be a true tree (as in a directed, acyclic graph).
Ludicrous.
> Lisp has read
> (and write) syntax for circular structures that allows a source code
> to not be a tree at all.
A source code is a linear sequence of characters (ASCII or, less
often, wide characters). There's a difference between source code and
the parse trees used internally by compilers and similar tools.
> But that is mostly an aside, since it isn't the fundamental misconception.
This insinuation that I have "misconceptions" is unwelcome and untrue.
> It is precisely this ability to execute code that gives Lisp macros the
> power that Series Expansion likes to describe as "magical".
It is rude to address someone, in their presence, in the third person.
(And the rest of what you said is pure nonsense.)
> The GENSYM that is created for use as the name of a variable DOESN'T
> EXIST IN THE SOURCE CODE. It is created at macro-expansion time by
> the running of code in the macro-expansion function. So, it is
> quite easy to create a new, unique symbol object. And by not
> registering the symbol in a package, there is no way to look it up
> by name.
Or ever use the same one twice. Kinda limits their usefulness
methinks.
> > It was in an earlier post of mine. More than one of them in fact; I
> > kept having to repeat it for the hard of hearing.
>
> Except that [calls me a liar]
No, sir, and indeed I submit that if there is a liar here it is you.
Series Expansion wrote:
> On Jun 1, 2:05 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
>> Lisp has read
>> (and write) syntax for circular structures that allows a source code
>> to not be a tree at all.
>
> A source code is a linear sequence of characters (ASCII or, less
> often, wide characters).
I know that Java allows for source code in other encoding than
ASCII and UTF-16 (wide chars are usually UTF-16).
I would expect Lisp to be similar.
Arne
On Sat, 11 Jul 2009 14:24:57 -0400, Arne Vajh�j <····@vajhoej.dk> said:
> Series Expansion wrote:
>> On Jun 1, 2:05 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>>
>>> Lisp has read
>>> (and write) syntax for circular structures that allows a source code
>>> to not be a tree at all.
>>
>> A source code is a linear sequence of characters (ASCII or, less
>> often, wide characters).
> I know that Java allows for source code in other encoding than
> ASCII and UTF-16 (wide chars are usually UTF-16).
> I would expect Lisp to be similar.
No, rather I think only narrow characters are allowed, no more than
7.62 mm.
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
On Jul 11, 3:40 pm, Vassil Nikolov <········@pobox.com> wrote:
> On Sat, 11 Jul 2009 14:24:57 -0400, Arne Vajhøj <····@vajhoej.dk> said:
>
> > Series Expansion wrote:
> >> On Jun 1, 2:05 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> >>> Lisp has read
> >>> (and write) syntax for circular structures that allows a source code
> >>> to not be a tree at all.
>
> >> A source code is a linear sequence of characters (ASCII or, less
> >> often, wide characters).
> > [calls me a liar]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Vassil and Arne.
> No, rather I think only narrow characters are allowed, no more than
> 7.62 mm.
Most illogical.
On Jul 11, 2:24 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On Jun 1, 2:05 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> >> Lisp has read
> >> (and write) syntax for circular structures that allows a source code
> >> to not be a tree at all.
>
> > A source code is a linear sequence of characters (ASCII or, less
> > often, wide characters).
>
> [calls me a liar]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
Series Expansion wrote:
> On Jul 11, 2:24 pm, Arne Vajh�j <····@vajhoej.dk> wrote:
>> Series Expansion wrote:
>>> On Jun 1, 2:05 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>>>> Lisp has read
>>>> (and write) syntax for circular structures that allows a source code
>>>> to not be a tree at all.
>>> A source code is a linear sequence of characters (ASCII or, less
>>> often, wide characters).
>> I know that Java allows for source code in other encoding than
>> ASCII and UTF-16 (wide chars are usually UTF-16).
>>
>> I would expect Lisp to be similar.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, Arne.
No.
But it prevents readers from thinking that source code can only
be ASCII and UTF-16, which is not the case.
Arne
On Jul 12, 10:04 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > On Jul 11, 2:24 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> >> Series Expansion wrote:
> >>> On Jun 1, 2:05 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> >>>> Lisp has read
> >>>> (and write) syntax for circular structures that allows a source code
> >>>> to not be a tree at all.
> >>> A source code is a linear sequence of characters (ASCII or, less
> >>> often, wide characters).
> >> I know that Java allows for source code in other encoding than
> >> ASCII and UTF-16 (wide chars are usually UTF-16).
>
> >> I would expect Lisp to be similar.
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, Arne.
>
> No.
>
> But [calls me a liar]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
On 2009-07-11 14:30:39 +0100, Series Expansion <·······@gmail.com> said:
> Or ever use the same one twice. Kinda limits their usefulness
> methinks.
I know you won't listen [so why am I wasting my time?] but you *really*
need to actually make some effort to understand CL (or Lisp in general)
because this kind of statement is just making you look silly.
For instance, consider this macro:
(defmacro collecting (&body forms)
(let ((ln (make-symbol "LIST"))
(ltn (make-symbol "TAIL")))
`(let ((,ln '())
(,ltn '()))
(flet ((collect (it)
(if (null ,ltn)
(setf ,ln (list it)
,ltn ,ln)
(setf (cdr ,ltn) (list it)
,ltn (cdr ,ltn)))
it))
(progn
,@forms
,ln)))))
This uses two gensyms (I've made them with MAKE-SYMBOL, so I can give
them print names which help, but they are uninterned symbols.
Now, what does the expansion of this look like?
? (macroexpand
'(collecting
(collect 1)
(collect 2)))
(let ((#:list 'nil) (#:tail 'nil))
(flet ((collect (it)
(if (null #:tail)
(setf #:list (list it) #:tail #:list)
(setf (cdr #:tail) (list it) #:tail (cdr #:tail)))
it))
(progn (collect 1) (collect 2) #:list)))
Except, of course, those uninterned symbols are actually *the same two
symbols* each time they are used, as you can see from the macro
definition. Fortunately there is a machanism of showing this: set
*PRINT-CIRCLE* to true:
? (macroexpand
'(collecting
(collect 1)
(collect 2)))
(let ((#2=#:list 'nil) (#1=#:tail 'nil))
(flet ((collect (it)
(if (null #1#)
(setf #2# (list it) #1# #2#)
(setf (cdr #1#) (list it) #1# (cdr #1#)))
it))
(progn (collect 1) (collect 2) #2#)))
Tim Bradshaw wrote:
> On 2009-07-11 14:30:39 +0100, Series Expansion <·······@gmail.com> said:
>
>> Or ever use the same one twice. Kinda limits their usefulness
>> methinks.
>
> I know you won't listen [so why am I wasting my time?] but you *really*
> need to actually make some effort to understand CL (or Lisp in general)
> because this kind of statement is just making you look silly.
Wow. You guys are still arguing with the troll after all this time?
Amazing.
I'm not sure how this topic made it through my filters but I'll block it again.
--
Lew
On Jul 12, 9:49 am, Lew <·····@lewscanon.com> wrote:
> Tim Bradshaw wrote:
> > On 2009-07-11 14:30:39 +0100, Series Expansion <·······@gmail.com> said:
> >> Or ever use the same one twice. Kinda limits their usefulness
> >> methinks.
>
> > I know you won't listen [so why am I wasting my time?] but you *really*
> > need to actually make some effort to understand CL (or Lisp in general)
> > because this kind of statement is just making you look silly.
> Wow. You guys are still arguing with the troll after all this time?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Tim.
Lew wrote:
> Tim Bradshaw wrote:
>> On 2009-07-11 14:30:39 +0100, Series Expansion <·······@gmail.com> said:
>>
>>> Or ever use the same one twice. Kinda limits their usefulness
>>> methinks.
>>
>> I know you won't listen [so why am I wasting my time?] but you
>> *really* need to actually make some effort to understand CL (or Lisp
>> in general) because this kind of statement is just making you look silly.
>
> Wow. You guys are still arguing with the troll after all this time?
>
> Amazing.
>
Good point. Other cll suckers, sure, but Tfb the Elder? I guess the
choppers got repossessed.
kt
On Jul 12, 2:37 pm, Kenneth Tilton <·········@gmail.com> wrote:
> Lew wrote:
> > Tim Bradshaw wrote:
> >> On 2009-07-11 14:30:39 +0100, Series Expansion <·······@gmail.com> said:
> >>> Or ever use the same one twice. Kinda limits their usefulness
> >>> methinks.
> >> I know you won't listen [so why am I wasting my time?] but you
> >> *really* need to actually make some effort to understand CL (or Lisp
> >> in general) because this kind of statement is just making you look silly.
> > Wow. You guys are still arguing with the troll after all this time?
> Good point. Other cll suckers, sure, but Tfb the Elder? I guess the
> choppers got repossessed.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Kenneth, "Lew", and Tim.
On 2009-07-12 19:37:08 +0100, Kenneth Tilton <·········@gmail.com> said:
> Good point. Other cll suckers, sure, but Tfb the Elder? I guess the
> choppers got repossessed.
I'm not an elder as far as I know. We have had certain, um, problems
with the helicopters, it's true. Fixing the banks turned out to
require a whole lot more operational hours than we expected, and parts
availability has become a serious issue (sand gets everywhere). I'd
been assuming that Mr Expansion was actually one of your tentacles
though? If not I'll have to check it's not one of ours: we've had some
problems with some of the more independent subsystems recently.
On Jul 12, 5:48 pm, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-12 19:37:08 +0100, Kenneth Tilton <·········@gmail.com> said:
>
> > Good point. Other cll suckers, sure, but Tfb the Elder? I guess the
> > choppers got repossessed.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim and Thomas.
> I'm not an elder as far as I know. We have had certain, um, problems
> with the helicopters, it's true. Fixing the banks turned out to
> require a whole lot more operational hours than we expected [etc etc]
Seek help.
On Jul 12, 7:01 am, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-11 14:30:39 +0100, Series Expansion <·······@gmail.com> said:
> > Or ever use the same one twice. Kinda limits their usefulness
> > methinks.
>
> I know you won't listen
To ad hominems? No.
> but you *really* need to
I do not "*really* need to" do anything on your say-so, as a matter of
fact.
> because this kind of statement is just making you look silly.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim.
> ? (macroexpand
> '(collecting
> (collect 1)
> (collect 2)))
> (let ((#:list 'nil) (#:tail 'nil))
> (flet ((collect (it)
> (if (null #:tail)
> (setf #:list (list it) #:tail #:list)
> (setf (cdr #:tail) (list it) #:tail (cdr #:tail)))
> it))
> (progn (collect 1) (collect 2) #:list)))
And if what you've said about "uninterned" symbols is correct, this
won't behave as advertised if read in and evaluated.
You now have two options:
1. It just plain doesn't work, and I win.
2. It somehow does work, in which case replacing a macro invocation
with its expansion does NOT work, not always having the same
semantics as leaving the macro invocation as a macro invocation,
because there's some sort of "magic" involved. In which case I win
again because then your "macros" not only aren't true macros, but
furthermore do something very weird, confusing, and therefore
evil.
On 2009-07-12 19:35:59 +0100, Series Expansion <·······@gmail.com> said:
> And if what you've said about "uninterned" symbols is correct, this
> won't behave as advertised if read in and evaluated.
That's correct. But only because the printer, with default settings,
does not attempt to detect all the sharing in structures it prints.
Since, in this code, there is sharing, the printed form does not
properly represent the code. As I said, if you set *PRINT-CIRCLE*
true, then the printer *does* try and detect sharing, and will print
something which can be read in and will work (this is not always the
case, since not all structures can be printed readably at all, but it
is true here). Of course none of this affects the macro's behaviour at
all because it does not rely on the printer or reader.
On Jul 12, 5:58 pm, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-12 19:35:59 +0100, Series Expansion <·······@gmail.com> said:
> > And if what you've said about "uninterned" symbols is correct, this
> > won't behave as advertised if read in and evaluated.
>
> That's correct.
Then why are you still arguing?
On 2009-07-13 15:35:47 +0100, Series Expansion <·······@gmail.com> said:
> Then why are you still arguing?
I don't need to: the macro works, and does the arguing for me.
On Jul 13, 3:29 pm, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-13 15:35:47 +0100, Series Expansion <·······@gmail.com> said:
>
> > Then why are you still arguing?
>
> I don't need to
Then stop already.
Tim Bradshaw <···@cley.com> writes:
> This uses two gensyms (I've made them with MAKE-SYMBOL, so I can give
> them print names which help, but they are uninterned symbols.
Better use (gensym "LIST-") and (gensym "TAIL-") so you can
distinguish them when you macroexpand:
(collecting (collect (collecting (collect 1) (collect 2)))
(collect (collecting (collect 3) (collect 4))))
--
__Pascal Bourguignon__
On 2009-07-12 17:56:12 +0100, ···@informatimago.com (Pascal J.
Bourguignon) said:
> Better use (gensym "LIST-") and (gensym "TAIL-") so you can
> distinguish them when you macroexpand:
Yes, probably.
On Jun 1, 2:05 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > The claim made regarding gensyms cannot be correct unless the program
> > structure in memory (your abstract syntax tree) is not actually a tree
> > but a directed acyclic graph with undirected cycles. Since the parse
> > tree of any text source file will be a bona fide tree, it follows that
> > if the claim regarding gensyms is true, the two representations are
> > NOT isomorphic; conversely, if as you have claimed the representations
> > ARE isomorphic the gensym claim is bogus.
>
> Well, for starters, let's clear up some more misconceptions
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
> (1) There is no requirement that the "parse tree" for lisp source has to
> be a true tree
Sure there is. It's even stated right there in the very name "parse
tree".
> (2) The fundamental misconception is not realizing the impact that the
> ability to execute code as part of the macro-expansion has.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
> The GENSYM that is created for use as the name of a variable DOESN'T
> EXIST IN THE SOURCE CODE.
Did I claim otherwise?
The point is, we have flat ASCII text. Then we have a parse tree (note
"tree"). Then a transformation is apparently made upon this parse tree
(note "tree"). Then you make a bunch of claims that are impossible to
reconcile with the tree-ness of this tree.
> > It was in an earlier post of mine. More than one of them in fact; I
> > kept having to repeat it for the hard of hearing.
>
> Except that this proof depends on [lies] [rest deleted]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
Series Expansion <·······@gmail.com> writes:
> > Most compilers tokenize the source file prior to compilation.
> > You can think of macros as manipulating the tokens.
>
> That seems acceptable, but it fails to grant macros miraculous powers
> of prescience.
...
> I have proven mathematically that if the internal representations ARE
> isomorphic to the source file then your asserted miraculous properties
> of gensyms are physically impossible.
Well, something must be wrong with either your proof or the assumptions,
since GENSYMs are able to create new symbols (objects or tokens, if you
will) that can be inserted into the parse tree that is passed to the
compiler. Those symbols are guaranteed to be unique.
If you think that is incorrect, then here is a challenge. I will write
a simple macro and you can then show that is suffers from one of the
problems that you claim it must have. You won't be able to do it.
So, here is the macro and the challenge:
You are to provide the code for the body that is inserted into the
binding context of the GENSYM and be able to print the value of that
GENSYM.
(defmacro gensym-test (&body body)
(let ((var (gensym)))
`(let ((,var (random 1000000)))
,@body
,var)))
This will return the value with a random number. Your job is to print
that value with something in BODY code. If it's more to your liking,
here is an effectively equivalent version
(defmacro gensym-test (&body body)
(let ((var #:v))
`(let ((,var (random 1000000)))
,@body
,var)))
So, you get to provide the content to replace ... for a call to this
macro that can demonstrate why variable capture has to happen.
(gensym-test ...)
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> ...
> So, here is the macro and the challenge:
>
> You are to provide the code for the body that is inserted into the
> binding context of the GENSYM and be able to print the value of that
> GENSYM.
>
> (defmacro gensym-test (&body body)
> (let ((var (gensym)))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> This will return the value with a random number. Your job is to print
> that value with something in BODY code. If it's more to your liking,
> here is an effectively equivalent version
>
> (defmacro gensym-test (&body body)
> (let ((var #:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> So, you get to provide the content to replace ... for a call to this
> macro that can demonstrate why variable capture has to happen.
>
> (gensym-test ...)
Your second challenge is flawed. Even after I fix the missing quote:
(defmacro gensym-test (&body body)
(let ((var '#:v))
`(let ((,var (random 1000000)))
,@body
,var)))
I can crack it with the following macro:
(defmacro expose-it ()
(let ((var (caddr (macroexpand-1 '(gensym-test)))))
`(format t "The value will be: ~S~%" ,var)))
You might consider calling macroexpand-1 off-limits, but setf does it all
the time, so I don't think you can rule this out.
The moral of the story is that you have to be very careful about designing
challenges like this.
On May 29, 6:25 pm, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
> ····@sevak.isi.edu (Thomas A. Russ) writes:
>
>
>
> > ...
> > So, here is the macro and the challenge:
>
> > You are to provide the code for the body that is inserted into the
> > binding context of the GENSYM and be able to print the value of that
> > GENSYM.
>
> > (defmacro gensym-test (&body body)
> > (let ((var (gensym)))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
>
> > This will return the value with a random number. Your job is to print
> > that value with something in BODY code. If it's more to your liking,
> > here is an effectively equivalent version
>
> > (defmacro gensym-test (&body body)
> > (let ((var #:v))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
>
> > So, you get to provide the content to replace ... for a call to this
> > macro that can demonstrate why variable capture has to happen.
>
> > (gensym-test ...)
>
> Your second challenge is flawed. Even after I fix the missing quote:
>
> (defmacro gensym-test (&body body)
> (let ((var '#:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> I can crack it with the following macro:
>
> (defmacro expose-it ()
> (let ((var (caddr (macroexpand-1 '(gensym-test)))))
> `(format t "The value will be: ~S~%" ,var)))
>
> You might consider calling macroexpand-1 off-limits, but setf does it all
> the time, so I don't think you can rule this out.
>
> The moral of the story is that you have to be very careful about designing
> challenges like this.
I think the moral here is to be careful when 'fixing' things, as you
might break them.
1 and 2 are semantically identical.
Quoting it makes the #:v a literal constant in your version, whereas
it is in 1 and 2, it is not.
(defmacro gensym-test1 (&body body)
(let ((var (gensym)))
`(let ((,var (random 1000000)))
,@body
,var)))
(defmacro gensym-test2 (&body body)
(let ((var #:v))
`(let ((,var (random 1000000)))
,@body
,var)))
(defmacro gensym-test3 (&body body)
(let ((var '#:v))
`(let ((,var (random 1000000)))
,@body
,var)))
(defmacro expose-it (test) (let ((var (caddr (macroexpand-1 `
(,test))))) `(format T "The value will be: ~S~%" ,var)))
(defun exposure-test1 ()
(gensym-test1 (expose-it gensym-test1)))
(defun exposure-test2 ()
(gensym-test2 (expose-it gensym-test2)))
(defun exposure-test3 ()
(gensym-test3 (expose-it gensym-test3)))
Load this code and you will see that 1 & 2 will not run due to an
unbound variable, whereas 3 behaves as you claim.
On May 29, 11:04 pm, ··················@gmail.com wrote:
> On May 29, 6:25 pm, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
>
>
>
> > ····@sevak.isi.edu (Thomas A. Russ) writes:
>
> > > ...
> > > So, here is the macro and the challenge:
>
> > > You are to provide the code for the body that is inserted into the
> > > binding context of the GENSYM and be able to print the value of that
> > > GENSYM.
>
> > > (defmacro gensym-test (&body body)
> > > (let ((var (gensym)))
> > > `(let ((,var (random 1000000)))
> > > ,@body
> > > ,var)))
>
> > > This will return the value with a random number. Your job is to print
> > > that value with something in BODY code. If it's more to your liking,
> > > here is an effectively equivalent version
>
> > > (defmacro gensym-test (&body body)
> > > (let ((var #:v))
> > > `(let ((,var (random 1000000)))
> > > ,@body
> > > ,var)))
>
> > > So, you get to provide the content to replace ... for a call to this
> > > macro that can demonstrate why variable capture has to happen.
>
> > > (gensym-test ...)
>
> > Your second challenge is flawed. Even after I fix the missing quote:
>
> > (defmacro gensym-test (&body body)
> > (let ((var '#:v))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
>
> > I can crack it with the following macro:
>
> > (defmacro expose-it ()
> > (let ((var (caddr (macroexpand-1 '(gensym-test)))))
> > `(format t "The value will be: ~S~%" ,var)))
>
> > You might consider calling macroexpand-1 off-limits, but setf does it all
> > the time, so I don't think you can rule this out.
>
> > The moral of the story is that you have to be very careful about designing
> > challenges like this.
>
> I think the moral here is to be careful when 'fixing' things, as you
> might break them.
> 1 and 2 are semantically identical.
>
> Quoting it makes the #:v a literal constant in your version, whereas
> it is in 1 and 2, it is not.
>
> (defmacro gensym-test1 (&body body)
> (let ((var (gensym)))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> (defmacro gensym-test2 (&body body)
> (let ((var #:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> (defmacro gensym-test3 (&body body)
> (let ((var '#:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> (defmacro expose-it (test) (let ((var (caddr (macroexpand-1 `
> (,test))))) `(format T "The value will be: ~S~%" ,var)))
>
> (defun exposure-test1 ()
> (gensym-test1 (expose-it gensym-test1)))
> (defun exposure-test2 ()
> (gensym-test2 (expose-it gensym-test2)))
> (defun exposure-test3 ()
> (gensym-test3 (expose-it gensym-test3)))
>
> Load this code and you will see that 1 & 2 will not run due to an
> unbound variable, whereas 3 behaves as you claim.
I will note that you may have been confused by the style warning that
you get with #2 (in sbcl at least).
Although you may get this warning, it loads and runs exactly as #1
would have.
On May 29, 11:06 pm, ··················@gmail.com wrote:
> On May 29, 11:04 pm, ··················@gmail.com wrote:
> > On May 29, 6:25 pm, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
> > > ····@sevak.isi.edu (Thomas A. Russ) writes:
> > > > [name-calling]
> > > The moral of the story is that you have to be very careful about designing
> > > challenges like this.
> > I think the moral here is to be careful when 'fixing' things, as you
> > might break them.
> I will note that you may have been confused by the style warning that
> you get with #2 (in sbcl at least).
Namecalling isn't a matter for style warnings, but for etiquette
warnings, IMO.
··················@gmail.com writes:
> I think the moral here is to be careful when 'fixing' things, as you
> might break them.
> 1 and 2 are semantically identical.
>
> Quoting it makes the #:v a literal constant in your version, whereas
> it is in 1 and 2, it is not.
>
> (defmacro gensym-test1 (&body body)
> (let ((var (gensym)))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> (defmacro gensym-test2 (&body body)
> (let ((var #:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
>
> (defmacro gensym-test3 (&body body)
> (let ((var '#:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> (defmacro expose-it (test) (let ((var (caddr (macroexpand-1 `
> (,test))))) `(format T "The value will be: ~S~%" ,var)))
>
> (defun exposure-test1 ()
> (gensym-test1 (expose-it gensym-test1)))
> (defun exposure-test2 ()
> (gensym-test2 (expose-it gensym-test2)))
> (defun exposure-test3 ()
> (gensym-test3 (expose-it gensym-test3)))
>
> Load this code and you will see that 1 & 2 will not run due to an
> unbound variable, whereas 3 behaves as you claim.
Yes, but they get unbound variable errors for different reasons.
gensym-test2 gets an unbound variable error NO MATTER WHAT YOU PUT IN THE
BODY! They are not "semantically identical" -- gensym-test2 is just
broken. Tom pretty clearly intended gensym-test3, which can be attacked as
I demonstrated.
(And yes, my attack does not work on gensym-test1. It does get an unbound
variable error. As near as I can tell, gensym-test1 proves the point that
Tom was trying to make just fine and he should have stopped there!)
On May 30, 1:10 am, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
> ··················@gmail.com writes:
> > I think the moral here is to be careful when 'fixing' things, as you
> > might break them.
> > 1 and 2 are semantically identical.
>
> > Quoting it makes the #:v a literal constant in your version, whereas
> > it is in 1 and 2, it is not.
>
> > (defmacro gensym-test1 (&body body)
> > (let ((var (gensym)))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
>
> > (defmacro gensym-test2 (&body body)
> > (let ((var #:v))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
>
> > (defmacro gensym-test3 (&body body)
> > (let ((var '#:v))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
>
> > (defmacro expose-it (test) (let ((var (caddr (macroexpand-1 `
> > (,test))))) `(format T "The value will be: ~S~%" ,var)))
>
> > (defun exposure-test1 ()
> > (gensym-test1 (expose-it gensym-test1)))
> > (defun exposure-test2 ()
> > (gensym-test2 (expose-it gensym-test2)))
> > (defun exposure-test3 ()
> > (gensym-test3 (expose-it gensym-test3)))
>
> > Load this code and you will see that 1 & 2 will not run due to an
> > unbound variable, whereas 3 behaves as you claim.
>
> Yes, but they get unbound variable errors for different reasons.
> gensym-test2 gets an unbound variable error NO MATTER WHAT YOU PUT IN THE
> BODY! They are not "semantically identical" -- gensym-test2 is just
> broken. Tom pretty clearly intended gensym-test3, which can be attacked as
> I demonstrated.
>
> (And yes, my attack does not work on gensym-test1. It does get an unbound
> variable error. As near as I can tell, gensym-test1 proves the point that
> Tom was trying to make just fine and he should have stopped there!)
Hmm, that's wierd.
I had thought John's version of 2 was running in the repl last night,
however this morning it clearly isn't.
I must have forgotten to overwrite an old one.
Now the moral is: 'Don't disagree with Allan, God will smite your
repl'.
Apologies!
Alan Bawden <····@shaggy.csail.mit.edu> writes:
> ··················@gmail.com writes:
> > (defmacro gensym-test1 (&body body)
> > (let ((var (gensym)))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
...
> > (defmacro gensym-test3 (&body body)
> > (let ((var '#:v))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
> (And yes, my attack does not work on gensym-test1. It does get an unbound
> variable error. As near as I can tell, gensym-test1 proves the point that
> Tom was trying to make just fine and he should have stopped there!)
Yes. Reconstructing my reasoning, I think I was trying to set a trap
just to demonstrate that even if you knew the SYMBOL-NAME of the
gensymed variable, it would not work. So that if one tried to do a very
naive
(gensym-test3 (print #:v))
that it would fail. But I hadn't considered the possibility of using
macroexpand to get at the actual form. So, in that sense, the power,
reflectivity and flexibilty of the lisp tools turned out to be greater
than I had anticipated.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 29, 11:04 pm, ··················@gmail.com wrote:
> On May 29, 6:25 pm, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
> > ····@sevak.isi.edu (Thomas A. Russ) writes:
> > > [namecalling]
> > The moral of the story is that you have to be very careful about designing
> > challenges like this.
> I think the moral here is to be careful when 'fixing' things, as you
> might break them.
I think the moral here is that it is not polite, or wise, to badmouth
someone behind his back. Doubly so if it turns out he has very good
hearing.
Alan Bawden <····@shaggy.csail.mit.edu> writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
> > (defmacro gensym-test (&body body)
> > (let ((var #:v))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
> >
> > So, you get to provide the content to replace ... for a call to this
> > macro that can demonstrate why variable capture has to happen.
> >
> > (gensym-test ...)
>
> Your second challenge is flawed. Even after I fix the missing quote:
Hi Alan!
Yes, you are correct that (a) it is missing a quote and (b) is subject
to the flow with using a sort of meta-programming trick to get at the
variable of the expansion.
> (defmacro gensym-test (&body body)
> (let ((var '#:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> I can crack it with the following macro:
>
> (defmacro expose-it ()
> (let ((var (caddr (macroexpand-1 '(gensym-test)))))
> `(format t "The value will be: ~S~%" ,var)))
>
> You might consider calling macroexpand-1 off-limits, but setf does it all
> the time, so I don't think you can rule this out.
>
> The moral of the story is that you have to be very careful about designing
> challenges like this.
How true.
It would have been quite impressive, though, if the target of that
challenge had found that solution.
I guess I'd better stick with #1....
-Tom.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 29, 6:25 pm, Alan Bawden <····@shaggy.csail.mit.edu> wrote:
> ····@sevak.isi.edu (Thomas A. Russ) writes:
> > [name-calling]
> The moral of the story is that you have to be very careful about designing
> challenges like this.
There is no sign of morality in either of you.
On May 29, 5:20 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > I have proven mathematically that if the internal representations ARE
> > isomorphic to the source file then your asserted miraculous properties
> > of gensyms are physically impossible.
>
> Well, [namecalling]
Nice try, but I periodically check other newsgroups than
comp.lang.java.programmer so you can only forestall my rebutting a
post full of personal attacks for a short time by trying to hide it
away in a newsgroup I don't read regularly.
Series Expansion wrote:
> I'm sure Ted Bundy's mother was proud of him, even for a while after
> everyone else started telling her he was a bad seed.
Man, Series, you really are a troll, aren't you?
>> May I suggest reading chapter 7 of "Practical Common Lisp"?
>
> Don't have it and can't be arsed to blow $40 on something I'll
> probably never use, sorry.
Luckily they already provided a link upthread whereby you can read it for free.
<http://www.gigamonkeys.com/book/>
Of course, acknowledging that they gave you a free link would reduce your
opportunities for trollism, wouldn't it?
Dollars to doughnuts you won't be "arsed", as you so charmingly put it, to
read it for free, either. Not that I'm any great fan of Lisp myself, but I'm
really not a fan of your behavior, Series. I think the Lisp proponents make a
fair point with the suggestion that you argue from knowledge rather than
ignorance and a nasty attitude. Now let's see if you are man enough to rise
to that challenge.
--
Lew
If only I could predict the stock market so accurately ...
On May 16, 5:15 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > I'm sure Ted Bundy's mother was proud of him, even for a while after
> > everyone else started telling her he was a bad seed.
>
> Man, Series, you really are a troll, aren't you?
I am here to discuss the relative merits of computer languages. I have
no interest in your flaming and personal attacks.
> >> May I suggest reading chapter 7 of "Practical Common Lisp"?
>
> > Don't have it and can't be arsed to blow $40 on something I'll
> > probably never use, sorry.
>
> Luckily they already provided a link upthread
If they'd provide their credit card number as well, I'd be happy to
follow that link.
> I'm really not a fan of your behavior, Series.
My "behavior", as you put it, is not at issue here. The behavior of
Lisp macros is.
> I think the Lisp proponents make a fair point with the
> suggestion that you argue from knowledge rather than
> ignorance and a nasty attitude.
I do argue from knowledge; not of Lisp particularly but of the
properties all macros have in common. As for a nasty attitude, I'll
leave it to others to decide whose attitude is nasty -- he who argues
rationally based on experience, evidence, and logic, or they whose
arguments consist largely of insults, accusations that their opponents
are "ignorant" or possess "a nasty attitude", and similarly irrelevant
ad-hominem remarks.
Series Expansion wrote:
> On May 16, 5:15 pm, Lew <·····@lewscanon.com> wrote:
>> Series Expansion wrote:
>>> I'm sure Ted Bundy's mother was proud of him, even for a while after
>>> everyone else started telling her he was a bad seed.
>> Man, Series, you really are a troll, aren't you?
>
> I am here to discuss the relative merits of computer languages. I have
> no interest in your flaming and personal attacks.
Oh, boo-hoo-hoo, you liar.
>>>> May I suggest reading chapter 7 of "Practical Common Lisp"?
>>> Don't have it and can't be arsed to blow $40 on something I'll
>>> probably never use, sorry.
>> Luckily they already provided a link upthread
>
> If they'd provide their credit card number as well, I'd be happy to
> follow that link.
Man, you really are a troll. Why would you want to steal their credit card
number to access a free product? You did notice that it was free, didn't you,
or were you too wrapped up in your own nonsense?
>> I'm really not a fan of your behavior, Series.
>
> My "behavior", as you put it, is not at issue here. The behavior of
> Lisp macros is.
Your behavior is at issue here, you foul-mouthed troll. Nothing you said
about Lisp had any merit, you ignoramus.
> I do argue from knowledge; not of Lisp particularly but of the
> properties all macros have in common. As for a nasty attitude, I'll
> leave it to others to decide whose attitude is nasty --
Yours, you unworthy poltroon.
> he who argues rationally based on experience, evidence, and logic, or they whose
That's not you, for sure. Your arguments are irrational, illogical, opposed
to the evidence and devoid of experience. You resort to nasty, nasty little
cusswords when reason fails you, you accuse others of behaviors that are but
pale reflections of yours, you are clearly in this only to boost your own
pathetic little ego.
> arguments consist largely of insults, accusations that their opponents
> are "ignorant" or possess "a nasty attitude", and similarly irrelevant
> ad-hominem remarks.
Awww, is widdoo widdoo "Series Expansion" upset?
You're such a hypocrite. You call people all sorts of foul things, but can't
take it when you are on the receiving end. You can dish it out, but you can't
take it. Coward. Dishonest person. Liar.
Nyaaah, nyaaah!
--
Lew
On May 17, 3:49 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > I am here to discuss the relative merits of computer languages. I have
> > no interest in your flaming and personal attacks.
>
> Oh, boo-hoo-hoo, you liar.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > If they'd provide their credit card number as well, I'd be happy to
> > follow that link.
>
> Man, you really are a troll.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> Why would you want to steal their credit card number
I would not. If they provided me the number of their own volition,
uncoerced, then no theft would have taken place.
> were you too wrapped up in your own nonsense?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> >> I'm really not a fan of your behavior, Series.
>
> > My "behavior", as you put it, is not at issue here. The behavior of
> > Lisp macros is.
>
> Your behavior is at issue here, you foul-mouthed troll. Nothing you said
> about Lisp had any merit, you ignoramus.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > I do argue from knowledge; not of Lisp particularly but of the
> > properties all macros have in common. As for a nasty attitude, I'll
> > leave it to others to decide whose attitude is nasty --
>
> Yours, you unworthy poltroon.
Incorrect. You are the nastiest person in this thread at this time, by
any sane standard.
> > he who argues rationally based on experience, evidence, and logic, or they whose
>
> That's not you, for sure. Your arguments are irrational, illogical, opposed
> to the evidence and devoid of experience. You resort to nasty, nasty little
> cusswords when reason fails you, you accuse others of behaviors that are but
> pale reflections of yours, you are clearly in this only to boost your own
> pathetic little ego.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
> > your arguments consist largely of insults, accusations that their opponents
> > are "ignorant" or possess "a nasty attitude", and similarly irrelevant
> > ad-hominem remarks.
>
> Awww, is widdoo widdoo "Series Expansion" upset?
No, I am disappointed in your failure to grasp the essential nature of
logical argumentation.
> You're such a hypocrite. You call people all sorts of foul things, but can't
> take it when you are on the receiving end. You can dish it out, but you can't
> take it. Coward. Dishonest person. Liar.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".
Note that I have remained calm in the face of your provocations, while
you are reduced to such nonsense as this:
> Nyaaah, nyaaah!
The only person evincing signs of an imminent breakdown is yourself.
On May 20, 3:49 pm, Series Expansion <·······@gmail.com> wrote:
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew".
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew".
>
> I would not. If they provided me the number of their own volition,
> uncoerced, then no theft would have taken place.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew".
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew".
>
> Incorrect. You are the nastiest person in this thread at this time, by
> any sane standard.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew".
>
> No, I am disappointed in your failure to grasp the essential nature of
> logical argumentation.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew".
>
> Note that I have remained calm in the face of your provocations, while
> you are reduced to such nonsense as this:
>
> > Nyaaah, nyaaah!
>
> The only person evincing signs of an imminent breakdown is yourself.
These tiresome repetitions of a formula do not constitute any evidence
that you have looked at Emacs screenshots, or that you have tried to
understand CLOS, Lisp Macros, or Lisp Packages.
Series and Seamus, as the two of you keep demanding more and more
"evidence" and examples of "impossible" things, we keep providing
them. You keep dodging the fact that our examples answer your
questions by posing newer and more ridiculous misunderstandings of
what we explain, and trying to claim the logical high ground for
yourselves. Now it's completely possible that you may be smarter, more
mature, stronger, faster, better, etc, than us, but that has no
bearing on the discussion if you refuse to make a bit of a mental
stretch and check out some examples.
Oh and Seamus, thank you for coming back. Series's humour was starting
to dry up...
- Adlai
On May 20, 9:51 am, Adlai <·········@gmail.com> wrote:
> On May 20, 3:49 pm, Series Expansion <·······@gmail.com> wrote:
[an attribution is missing here]
> > > Nyaaah, nyaaah!
>
> > The only person evincing signs of an imminent breakdown is yourself.
>
> These tiresome repetitions of a formula do not constitute any evidence
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Adlai.
> Series and Seamus, as the two of you keep demanding more and more
> "evidence" and examples of "impossible" things, we keep providing
> them.
What you keep providing are assertions, personal attacks, and
irrelevancies like this latest post of yours, Adlai.
When (if) I do see some actual evidence I will let you know.
> You keep dodging the fact that our examples answer your
> questions by posing newer and more ridiculous misunderstandings of
I do not.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Adlai.
> Oh and Seamus, thank you for coming back. Series's humour was starting
> to dry up...
This post is in reply to me, not Seamus, so this remark is illogical.
Not to mention that these tiresome personal attacks do not constitute
rational arguments in favor of either Lisp or Java, Adlai.
Series Expansion <·······@gmail.com> writes:
> On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
>> On 16 May, 04:54, Series Expansion <·······@gmail.com> wrote:
>>
>> > Five-minute quick hacks are another story, and unfortunately, it's in
>> > the nature of macros to potentially interact with practically the
>> > entire code base.
>>
>> No
>
> Yes
It bears saying again that you don't have the faintest idea how Lisp
macros work.
>> macros only interact with the code which uses them in much the
>> same way that functions only interact with code which uses them.
>
> The problem is that "the code which uses them" includes any code that
> contains the text that triggers the macro and that occurs after the
> macro in evaluation by the compiler.
It bears saying again that you don't have the faintest idea how Lisp
macros work.
> I've written lots of macros, though, in a variety of places and
> contexts.
It bears saying again that you don't have the faintest idea how Lisp
macros work. They don't work like C macros, and they don't work like you
think they do. May I suggest reading chapter 8 of "Practical Common
Lisp"? Here's a link to it:
http://gigamonkeys.com/book/macros-defining-your-own.html
>> May I suggest reading chapter 7 of "Practical Common Lisp"?
>
> Don't have it and can't be arsed to blow $40 on something I'll
> probably never use, sorry.
It's free online. Do you see the link?
On 16 maio, 21:28, Paul Donnelly <·············@sbcglobal.net> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
> >> On 16 May, 04:54, Series Expansion <·······@gmail.com> wrote:
>
> >> > Five-minute quick hacks are another story, and unfortunately, it's in
> >> > the nature of macros to potentially interact with practically the
> >> > entire code base.
>
> >> No
>
> > Yes
>
> It bears saying again that you don't have the faintest idea how Lisp
> macros work.
>
> >> macros only interact with the code which uses them in much the
> >> same way that functions only interact with code which uses them.
>
> > The problem is that "the code which uses them" includes any code that
> > contains the text that triggers the macro and that occurs after the
> > macro in evaluation by the compiler.
>
> It bears saying again that you don't have the faintest idea how Lisp
> macros work.
>
I am starting to think that what he fails to see is that Lisp has a
uniform interface (someone already said that, but he probably didn't
pay much attention). And he probably thinks that the compiler will
look for texts that look like macro and expand them. So there is no
place where something else can be mistaken with a macro call.
Just trying to make things clear now, lispers don't need to read it
because they already know all of what I am explaining here. Lisp code
is a bunch of nested lists - that is why Lisp has so much parenthesis
(I won't be mad if anyone say this is not very good, I respect
everyone's opinion, but I PERSONALLY prefer code filled with
parenthesis then code filled with a non-uniform syntax like C or
Java). When we type
(+ 1 (* 2 3))
this is text that actually represents a tree. There is the outer list
whose elements are the symbol +, the number 1 and another inner list.
The inner list is composed by the symbol * and the numbers 2 and 3.
The compiler and all macros work based one that tree. Assuming that m
is a macro, when you write
(m (+ 1 (* 2 3)))
the compiler will parse the outer list and see that it is composed by
two elements: the symbol m and a inner list. Then the compiler will
think "oh, the symbol m names a macro." (ok, not exactly think, but
you get the point, right?). The compiler will call that macro the
exact way that it would call a function, but, instead of evaluating
the list (+ 1 (* 2 3)) to the value 7 and call the macro with the
value 7, it will call the macro with the list itself, without
evaluating it. It is just a list, a well known and very simple data
structure that even a beginner in programming with a minimal knowledge
of data structures know how to manipulate. And what does the macro
return? Another list, to be evaluated instead of the expression (+ 1
(* 2 3)).
For instance, if the job of the macro m was to print the values
returned by the expressions returned by 1 and (* 2 3) before return
the value of the entire expression, it would probably be expanded into
something like this:
(let ((#:g1 1)
(#:g2 (* 2 3)))
(print #:g1)
(print #:g2)
(+ #:g1 #:g2))
Don't worry about scope or collisions, the symbols #:g1 and #:g2 are
what we call gensyms, they are auto-generated symbols that can't
collide with your own symbols, even if you explicitly call, for
instance:
(m (+ #:g1 #:g2))
This is because they are what we call uninterned symbols - the only
way to reference an already existing uninterned symbol is to have its
value already inside some variable and get the value of that variable.
But this is another subject I will not get into now, just take my word
when I say that this works. And the new variables #:g1 and #:g2 only
exist during the execution of the code - once the code has finished
running (that code implicitly bounded inside the macro call), they are
either garbage collected or stack deallocated or something in that
sense.
The sequence of characters "(+ 1 (* 2 3))" were previously read and
transformed into a list long before the macro was called. Yes, BEFORE,
not during nor after. The entire form is read and parsed into lists,
and only then the macros found are expanded. Only after the macros did
their job the compiler finally takes the resulting form (guess what?
another bunch of nested lists) and compiles it, produced the well
known machine code or byte code that I am sure everyone here is
familiar with and I don't need to get into details.
On May 16, 9:28 pm, gugamilare <··········@gmail.com> wrote:
> On 16 maio, 21:28, Paul Donnelly <·············@sbcglobal.net> wrote:
> > Series Expansion <·······@gmail.com> writes:
> > > On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
> > >> macros only interact with the code which uses them in much the
> > >> same way that functions only interact with code which uses them.
>
> > > The problem is that "the code which uses them" includes any code that
> > > contains the text that triggers the macro and that occurs after the
> > > macro in evaluation by the compiler.
>
> > [Paul's thrice-repeated boilerplate insult removed in the interests of
> > preserving some semblance of decorum]
>
> I am starting to think that what he fails to see is ...
So your arguments, too, have now devolved into personal attacks
against the opposition.
It seems, then, there is very little left for me to do in this thread.
Most disappointing.
> And he probably thinks that the compiler will look for texts that
> look like macro and expand them.
That is what macro processors do, although more specifically the texts
must look like the macro's *name*.
> Just trying to make things clear now, lispers don't need to read it
> because they already know all of what I am explaining here. Lisp code
> is a bunch of nested lists - that is why Lisp has so much parenthesis
> (I won't be mad if anyone say this is not very good, I respect
> everyone's opinion, but I PERSONALLY prefer code filled with
> parenthesis then code filled with a non-uniform syntax like C or
> Java).
You have a peculiar method of demonstrating that you respect
everyone's opinion. Ordinarily, one would not express such by means of
petty namecalling.
> When we type
>
> (+ 1 (* 2 3))
>
> this is text that actually represents a tree.
I'm well aware of this; in fact, I probably know considerably more
about Lisp than you have given me credit for.
> The inner list is composed by the symbol * and the numbers 2 and 3.
> The compiler and all macros work based one that tree.
That the macro operates upon trees rather than linear strings does not
alter its fundamental nature as a macro.
> Assuming that m
> is a macro, when you write
>
> (m (+ 1 (* 2 3)))
>
> the compiler will parse the outer list and see that it is composed by
> two elements: the symbol m and a inner list. Then the compiler will
> think "oh, the symbol m names a macro." (ok, not exactly think, but
> you get the point, right?).
This leads to one of the three major issues under discussion. If m
were a function, and someone were to add a macro named m in the right
place, it would alter the behavior of much of the code-base. This
could result from a typo or other accident, and might prove difficult
to debug.
> The compiler will call that macro the exact way that it would call a
> function, but, instead of evaluating the list (+ 1 (* 2 3)) to the
> value 7 and call the macro with the value 7, it will call the macro
> with the list itself, without evaluating it. It is just a list, a well known and very simple data
> structure that even a beginner in programming with a minimal knowledge
> of data structures know how to manipulate. And what does the macro
> return? Another list, to be evaluated instead of the expression (+ 1
> (* 2 3)).
Which ordinarily will contain that expression, wrapped in other code.
This causes the second of those three issues, namely, depending on
when, how often, and in what order the macro uses its arguments,
argument expressions with side effects may occur zero or more times in
any sequence. If foo(x,y) is a function call, the side effects of x
and y will occur once each, and in many languages, in that order. If
foo(x,y) is a macro call, it is possible for y's side effects not to
occur at all, or for the side effects to occur multiple times and in
an arbitrary sequence, for instance yxyyx. Worse, changes in the
macro's implementation may alter this, even changes that weren't
supposed to make a semantic difference, such as performance
optimizations.
It also causes the third: when the macro's result takes its place,
variables it uses may collide with variables around the call site.
Creating a nested scope, equivalent to using a {} block in C, inside
the macro to avoid this results in those variables now hiding
variables around the call site. If one of the hidden variables is used
in one of the call's argument expressions, it will fail to have the
intended effect.
> The sequence of characters "(+ 1 (* 2 3))" were previously read and
> transformed into a list long before the macro was called. Yes, BEFORE,
> not during nor after. The entire form is read and parsed into lists,
> and only then the macros found are expanded.
I already knew this, and it does not materially alter the points
raised above.
> Only after the macros did
> their job the compiler finally takes the resulting form (guess what?
> another bunch of nested lists) and compiles it, produced the well
> known machine code or byte code that I am sure everyone here is
> familiar with and I don't need to get into details.
This presents a fourth potential issue. Macros cannot vary at run
time, nor can their argument lists. Those lists may operate upon
variables, but cannot themselves be variable.
Indeed, what macros do, some other languages do more cleanly using
closures. Instead of a macro m(x,y) there would be a function f(x,y)
whose arguments were closures. The function f would run the closures
amid running its own code and then return. Where a macro processor
would replace m with its expansion at compile time, the call to f
would be left alone.
With respect to issue one, f would lie in the namespace of ordinary
functions and any code declaring a different f would trigger an error
from the name collision.
With respect to issue two, f would still cause the side effects of x
and y in arbitrary number and order. However, f's arguments would be
syntactically recognizable as closures, for example Smalltalk blocks,
rather than being ordinary expressions in only ordinary function-call
syntax, mitigating issue two.
With respect to issue three, f would have its own local scope, not
nested in the scope of any call site, and therefore would be
"hygienic".
With respect to issue four, f could be called with closure-valued
variables instead of only with a closure literal, and would behave as
one would hope and expect.
The downside is performance: f could not be inlined by the compiler if
called with run-time-variable closures instead of run-time-constant
ones.
It seems that the macro m is therefore just an auto-inlining version
of f that cannot have run-time-variable closures, lacks a separate
naming scope from its call sites, and lacks a syntax to distinguish it
from an ordinary function call, allowing for both accidental
substitutions and confusion regarding sequencing and number of
occurrences of argument expression side effects.
In other words, m seems to lack advantages over f, whereas f has clear
advantages over m. Whenever m could work at all f could be inlined so
m does not even have a performance advantage; indeed sometimes f will,
whenever inlining it would bloat the object code enough to cause cache
misses but the compiler was smart enough to avoid inlining it under
those circumstances.
On May 16, 8:28 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 16, 1:42 am, Spiros Bousbouras <······@gmail.com> wrote:
> >> On 16 May, 04:54, Series Expansion <·······@gmail.com> wrote:
>
> >> > Five-minute quick hacks are another story, and unfortunately, it's in
> >> > the nature of macros to potentially interact with practically the
> >> > entire code base.
>
> >> No
>
> > Yes
>
> It bears saying again that [irrelevant personal attack]
Your penchant for posting personal attacks is becoming tiresome.
Please refrain from doing so again. It does not bolster your
arguments; rather, it just serves to make you look petty.
> >> macros only interact with the code which uses them in much the
> >> same way that functions only interact with code which uses them.
>
> > The problem is that "the code which uses them" includes any code that
> > contains the text that triggers the macro and that occurs after the
> > macro in evaluation by the compiler.
>
> It bears saying again that [irrelevant personal attack]
It bears saying again that your penchant for posting personal attacks
is becoming tiresome. Please refrain from doing so again. It does not
bolster your arguments; rather, it just serves to make you look petty.
> > I've written lots of macros, though, in a variety of places and
> > contexts.
>
> It bears saying again that [irrelevant personal attack]
Insults and repetition are the last desperate resort of a debater who
has realized that he's losing the argument. You can't win on logical
grounds, so you respond with emotional outpourings of faith. When that
in turn proves futile, you change to a different form of emotional
argument, one that attacks the character or person of one of your
opponents and says nothing whatsoever about the actual subject of the
debate.
It would serve you better to remain silent once you have exhausted
your logical arguments regarding the topic. After that point, those
you have not convinced you will not convince and no amount of kicking
and screaming and throwing of temper tantrums will change that fact.
Since you are clearly uninterested in continuing to debate Lisp's
qualities logically, I see no point in continuing. The rest of your
post has been ignored. Have a nice day.
Series Expansion <·······@gmail.com> writes:
>> macros only interact with the code which uses them in much the
>> same way that functions only interact with code which uses them.
>
> The problem is that "the code which uses them" includes any code that
> contains the text that triggers the macro and that occurs after the
> macro in evaluation by the compiler.
This is false.
Haven't you read the tutorials on lisp macros at the URIs I gave?
> That's still compiling, and it can be made silent easily enough:
>
> #define malloc(x) ((void *)1)
And this is something that you may try to do in Lisp, but which will
pose absoltely no problem because it has a very well defined and sane
semantic:
(defun malloc (size) (make-array size :element-type '(unsigned-byte 8) :initial-element 0))
(defvar malloc 1)
(list malloc (malloc 20))
--> (1 #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0))
Why do you insist talking about things you don't know?
>> > And that's macro mischief in a "safe" (well, type-safe) language.
>>
>> C is not type safe because it has casts
>
> It's type safe compared to Lisp!
No it is not.
-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Sat May 16 22:53:56
SRC="/tmp/a.c" ; EXE="a" ; gcc -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} && ( cat ${SRC}; ./${EXE}) && echo status = $?
#include <stdio.h>
int main(){
printf("\"one\"+2=%d\n","one"+2);
return(0);
}
"one"+2=8175
status = 0
Compilation finished at Sat May 16 22:53:56
C/USER[31]> (+ "one" 2)
*** - +: "one" is not a number
> The problem with macros that I've been getting it is their inherent
> ability to alter the behavior of far-away code from pretty much
> anywhere. A function has to be intentionally invoked by some code to
> have effect there; a macro has to be coded to operate ON some other
> code to have effect there.
We are discussing Lisp macros and this is false.
Of course a macro can be programmed to expand to code that modify the
global state, for example, it could define a new global variable, or
it could define (or redefine) a function or a macro.
But if you don't want your macro to define a function, then you don't
program it to do so, and it won't have that global effect.
Then the effects of a macro invocation will be strictly localized.
Notice that defining global variables or (re)definining functions or
macros can also be done by functions in Lisp.
> It's easy to whip up a C macro that affects
Forget all you know about C macros, we're not discussing cpp, we're
talked about Lisp macros.
--
__Pascal Bourguignon__
On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> >> macros only interact with the code which uses them in much the
> >> same way that functions only interact with code which uses them.
>
> > The problem is that "the code which uses them" includes any code that
> > contains the text that triggers the macro and that occurs after the
> > macro in evaluation by the compiler.
>
> This is false.
I have just spent quite a while demonstrated otherwise.
> > That's still compiling, and it can be made silent easily enough:
>
> > #define malloc(x) ((void *)1)
>
> And this is something that you may try to do in Lisp, but which will
> pose absoltely no problem because it has a very well defined and sane
> semantic:
>
> (defun malloc (size) ...
That's a function, not a macro. Now watch what happens when someone
makes a macro with the same name and hides it away somewhere.
> Why do you insist talking about things you don't know?
But I know a great deal about macros, and the pitfalls thereof.
> >> > And that's macro mischief in a "safe" (well, type-safe) language.
>
> >> C is not type safe because it has casts
>
> > It's type safe compared to Lisp!
>
> No it is not.
Sure it is. In
int x;
x has to be an integer, at least unless you use wacky casts, which
will earn you a compiler warning. In
(defun foo (x) (do something with x))
x can be absolutely anything whatsoever -- integer, rational, decimal,
list, and so forth. If it's the wrong thing, the best you can probably
hope for is that the "do something with x" part will throw some kind
of run-time exception. Silent data corruption is more likely. It's
like if you had some C code with only one pointer type used anywhere,
void *, except it probably can't outright crash the runtime by goofing
up, just dump you into the REPL with a cryptic error message.
> "one"+2=8175
> status = 0
>
> *** - +: "one" is not a number
So you found one instance where C quietly generates a logic error but
Lisp's REPL produces a run-time exception.
And it looks like you may have done something to suppress the warnings
from the C compiler.
> > The problem with macros that I've been getting it is their inherent
> > ability to alter the behavior of far-away code from pretty much
> > anywhere. A function has to be intentionally invoked by some code to
> > have effect there; a macro has to be coded to operate ON some other
> > code to have effect there.
>
> [calls me a liar]
If you're going to do that, then we're done here.
> Of course a macro can be programmed to expand to code that modify the
> global state, for example, it could define a new global variable, or
> it could define (or redefine) a function or a macro.
Well, there you go, then.
> But if you don't want your macro to define a function, then you don't
> program it to do so, and it won't have that global effect.
Unless a mistake is made.
> Then the effects of a macro invocation will be strictly localized.
Unless a mistake is made.
> Notice that defining global variables or (re)definining functions or
> macros can also be done by functions in Lisp.
Maybe Lisp macros aren't more dangerous than Lisp functions after all,
then -- but because Lisp makes functions MORE dangerous instead of
macros LESS!
> > It's easy to whip up a C macro that affects
>
> Forget all you know about C macros
Why should I? It's a useful job skill.
On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:
> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Series Expansion <·······@gmail.com> writes:
> > >> macros only interact with the code which uses them in much the
> > >> same way that functions only interact with code which uses them.
>
> > > The problem is that "the code which uses them" includes any code that
> > > contains the text that triggers the macro and that occurs after the
> > > macro in evaluation by the compiler.
>
> > This is false.
>
> I have just spent quite a while demonstrated otherwise.
>
But used only invalid arguments, at least in the contest of Lisp.
On 17 maio, 04:13, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> > > Series Expansion <·······@gmail.com> writes:
> > > >> macros only interact with the code which uses them in much the
> > > >> same way that functions only interact with code which uses them.
>
> > > > The problem is that "the code which uses them" includes any code that
> > > > contains the text that triggers the macro and that occurs after the
> > > > macro in evaluation by the compiler.
>
> > > This is false.
>
> > I have just spent quite a while demonstrated otherwise.
>
> But used only invalid arguments, at least in the contest of Lisp.
ConteXt, before you flame me again for writing wrong English.
gugamilare wrote:
> On 17 maio, 04:13, gugamilare <··········@gmail.com> wrote:
>> On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>>>> Series Expansion <·······@gmail.com> writes:
>>>>>> macros only interact with the code which uses them in much the
>>>>>> same way that functions only interact with code which uses them.
>>>>> The problem is that "the code which uses them" includes any code that
>>>>> contains the text that triggers the macro and that occurs after the
>>>>> macro in evaluation by the compiler.
>>>> This is false.
>>> I have just spent quite a while demonstrated otherwise.
>> But used only invalid arguments, at least in the contest of Lisp.
>
> ConteXt, before you flame me again for writing wrong English.
Hey, Guga, Series's sentence,
>>> I have just spent quite a while demonstrated otherwise.
was grammatically incorrect. He's in no position to judge you.
--
Lew
On May 17, 1:11 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > On 17 maio, 04:13, gugamilare <··········@gmail.com> wrote:
> >> But used only invalid arguments, at least in the contest of Lisp.
>
> > ConteXt, before you flame me again for writing wrong English.
>
> Hey, Guga, Series's sentence,
> >>> I have just spent quite a while demonstrated otherwise.
> was grammatically incorrect. He's in no position to judge you.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and gugamilare.
Furthermore, I said I had spent quite a while demonstrat*ing*
otherwise. Misquoting me does not prove me an idiot; rather, it proves
you a liar.
Series Expansion wrote:
> On May 17, 1:11 pm, Lew <·····@lewscanon.com> wrote:
>> gugamilare wrote:
>>> On 17 maio, 04:13, gugamilare <··········@gmail.com> wrote:
>>>> But used only invalid arguments, at least in the contest of Lisp.
>>> ConteXt, before you flame me again for writing wrong English.
>> Hey, Guga, Series's sentence,
>> >>> I have just spent quite a while demonstrated otherwise.
>> was grammatically incorrect. He's in no position to judge you.
>
> These tiresome personal attacks do not constitute rational arguments
> in favor of either Lisp or Java, "Lew" and gugamilare.
>
> Furthermore, I said I had spent quite a while demonstrat*ing*
> otherwise. Misquoting me does not prove me an idiot; rather, it proves
> you a liar.
Nope. You wrote:
#I have just spent quite a while demonstrated otherwise.
http://groups.google.com/group/comp.lang.lisp/msg/c5faf5f283f19ac6?hl=da
Arne
On May 20, 9:32 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > Misquoting me does not prove me an idiot; rather, it proves you a liar.
> Nope.
Oh, yes it does.
On May 17, 3:25 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 04:13, gugamilare <··········@gmail.com> wrote:
>
>
>
> > On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
>
> > > > Series Expansion <·······@gmail.com> writes:
> > > > >> macros only interact with the code which uses them in much the
> > > > >> same way that functions only interact with code which uses them.
>
> > > > > The problem is that "the code which uses them" includes any code that
> > > > > contains the text that triggers the macro and that occurs after the
> > > > > macro in evaluation by the compiler.
>
> > > > This is false.
>
> > > I have just spent quite a while demonstrated otherwise.
>
> > But used only invalid arguments, at least in the contest of Lisp.
>
> ConteXt, before you flame me again for writing wrong English.
(I note the irony of your making this remark in the context of
correcting a spelling error that happens to be located in one of
*your* flames.)
I have not flamed you much, if at all, compared to your flamage of me,
and likewise, my arguments have been valid reasoning based on sound
premises, rather than largely consisting of exhortations, expletives,
exclamations, name-calling, denials, and bald assertions unsupported
by evidence or logic.
Based on this last, particularly, one suspects you had particular
difficulty in school with that subset of math teachers who grade a
flat zero on any question where the student didn't show his work, even
when the answer he'd arrived at was correct.
On May 17, 3:13 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> > > Series Expansion <·······@gmail.com> writes:
> > > >> macros only interact with the code which uses them in much the
> > > >> same way that functions only interact with code which uses them.
>
> > > > The problem is that "the code which uses them" includes any code that
> > > > contains the text that triggers the macro and that occurs after the
> > > > macro in evaluation by the compiler.
>
> > > This is false.
>
> > I have just spent quite a while demonstrated otherwise.
>
> 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*.
On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:
> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Series Expansion <·······@gmail.com> writes:
> > > It's easy to whip up a C macro that affects
>
> > Forget all you know about C macros
>
> Why should I? It's a useful job skill.
He meant that a C macro is so much different from a Lisp macro that,
to understand a Lisp macro, you need not to take any knowledge you
already have using C macros.
gugamilare wrote:
> On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:
>> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
>> wrote:
>>
>>> Series Expansion <·······@gmail.com> writes:
>>>> It's easy to whip up a C macro that affects
>>> Forget all you know about C macros
>> Why should I? It's a useful job skill.
>
> He meant that a C macro is so much different from a Lisp macro that,
> to understand a Lisp macro, you need not to take any knowledge you
> already have using C macros.
And none of this has anything to do with Java. Buh-bye.
--
Lew
On May 17, 1:12 pm, Lew <·····@lewscanon.com> wrote:
> gugamilare wrote:
> > He meant that a C macro is so much different from a Lisp macro that,
> > to understand a Lisp macro, you need not to take any knowledge you
> > already have using C macros.
This is incorrect. Both sorts of macro have key features in common,
such as that the macro's evaluation results in substitution of the
invocation with some other code, and the substitution within that code
of the argument code-fragments for some placeholders.
Furthermore, my arguments have relied on these commonalities, rather
than on any idiosyncrasies of either type of macro.
> And none of this has anything to do with Java. Buh-bye.
This, also, is incorrect. While the first sentence is technically
accurate, the debate over macros arose within the broader context of a
debate about whether Lisp was superior to Java (it is not). The second
sentence meanwhile appears to be an outright lie, since there are
numerous additional posts by "Lew" following the one containing it.
On May 17, 3:30 am, gugamilare <··········@gmail.com> wrote:
> On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:
>
> > On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> > > Series Expansion <·······@gmail.com> writes:
> > > > It's easy to whip up a C macro that affects
>
> > > Forget all you know about C macros
>
> > Why should I? It's a useful job skill.
>
> He meant that
I am quite certain that Pascal is capable of speaking for himself.
> a C macro is so much different from a Lisp macro that,
> to understand a Lisp macro, you need not to take any knowledge you
> already have using C macros.
This is clearly incorrect. They are still both macros, which means
that a certain intersection of their natures exists. Particularly,
those things that follow unassailably from the fundamental definition
of "macro", independently of implementation details, will lie within
that intersection, and it is those things that form the basis of my
macro-related arguments here.
On May 18, 10:25 am, Series Expansion <·······@gmail.com> wrote:
> On May 17, 3:30 am, gugamilare <··········@gmail.com> wrote:
>
> > On 17 maio, 04:08, Series Expansion <·······@gmail.com> wrote:
>
> > > On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
>
> > > > Series Expansion <·······@gmail.com> writes:
> > > > > It's easy to whip up a C macro that affects
>
> > > > Forget all you know about C macros
>
> > > Why should I? It's a useful job skill.
>
> > He meant that
>
> I am quite certain that Pascal is capable of speaking for himself.
>
> > a C macro is so much different from a Lisp macro that,
> > to understand a Lisp macro, you need not to take any knowledge you
> > already have using C macros.
>
> This is clearly incorrect. They are still both macros, which means
> that a certain intersection of their natures exists. Particularly,
> those things that follow unassailably from the fundamental definition
> of "macro", independently of implementation details, will lie within
> that intersection, and it is those things that form the basis of my
> macro-related arguments here.
Series, I wish I had the time to respond in detail to each of your
posts and provide you with material so you could keep on lighting fire
to your pink bunny boxers. However, time is limited, and I have a busy
day ahead. I look forward to reading your inspired verbal diarrhea
when I return from my LIFE at the end of the day. With some amount of
good fortune, there will be another 15 minutes of pure joy waiting.
I'm loving it.
- Adlai
On Mon, 18 May 2009 19:47:30 -0400, Lew wrote:
> Adlai wrote:
>> diarrhea
>
> Off topic in a Java newsgroup.
Strange that you post about 20 completely off-topic messages in C.L.L,
then complain about this.
Tamas
On May 18, 3:49 am, Adlai <·········@gmail.com> wrote:
> On May 18, 10:25 am, Series Expansion <·······@gmail.com> wrote:
> > On May 17, 3:30 am, gugamilare <··········@gmail.com> wrote:
> > > a C macro is so much different from a Lisp macro that,
> > > to understand a Lisp macro, you need not to take any knowledge you
> > > already have using C macros.
>
> > This is clearly incorrect. They are still both macros, which means
> > that a certain intersection of their natures exists. Particularly,
> > those things that follow unassailably from the fundamental definition
> > of "macro", independently of implementation details, will lie within
> > that intersection, and it is those things that form the basis of my
> > macro-related arguments here.
>
> Series, I wish I had the time to respond in detail to each of your
> posts and provide you with material so you could keep on lighting fire
> to your pink bunny boxers.
I do not have pink bunny boxers.
> However, time is limited, and I have a busy day ahead. I look forward
> to reading your inspired verbal diarrhea
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Adlai.
> I'm loving it.
>
> - Adlai
Does that mean that your post was a McFlame?
Series Expansion <·······@gmail.com> writes:
> On May 16, 5:00�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Series Expansion <·······@gmail.com> writes:
>> > It's easy to whip up a C macro that affects
>>
>> Forget all you know about C macros
>
> Why should I? It's a useful job skill.
Because we're talking about lisp macros and they have nothing in common with C macros.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Series Expansion <·······@gmail.com> writes:
>
>> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
>> wrote:
>>> Series Expansion <·······@gmail.com> writes:
>>>> It's easy to whip up a C macro that affects
>>> Forget all you know about C macros
>> Why should I? It's a useful job skill.
>
> Because we're talking about lisp macros and they have nothing in common with C macros.
And neither has anything in common with Java. Hint, hint.
--
Lew
On May 17, 1:11 pm, Lew <·····@lewscanon.com> wrote:
> Pascal J. Bourguignon wrote:
> > Series Expansion <·······@gmail.com> writes:
>
> >> On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> >> wrote:
> >>> Series Expansion <·······@gmail.com> writes:
> >>>> It's easy to whip up a C macro that affects
> >>> Forget all you know about C macros
> >> Why should I? It's a useful job skill.
>
> > Because we're talking about lisp macros and they have nothing in common with C macros.
Incorrect. Both sorts of macro are evaluated in some way and the
result substituted, as code, for the invocation; both sorts also have
the actual arguments, as code, substituted for placeholders of some
sort in the macro body.
And my arguments are based entirely upon these common features.
> And neither has anything in common with Java.
That much is true, but the larger context is a debate about which is
better, Lisp or Java. The problematical consequences of macros are
part of a refutation of an assertion fronted earlier to the effect
that Lisp was superior. The probable truth is that neither is strictly
superior to the other.
Series Expansion wrote:
> That much is true, but the larger context is a debate about which is
> better, Lisp or Java. The problematical consequences of macros are
> part of a refutation of an assertion fronted earlier to the effect
> that Lisp was superior. The probable truth is that neither is strictly
> superior to the other.
What - a taste of common sense??
Arne
On May 20, 9:36 pm, Arne Vajhøj <····@vajhoej.dk> wrote:
> Series Expansion wrote:
> > That much is true, but the larger context is a debate about which is
> > better, Lisp or Java. The problematical consequences of macros are
> > part of a refutation of an assertion fronted earlier to the effect
> > that Lisp was superior. The probable truth is that neither is strictly
> > superior to the other.
>
> What - a taste of common sense??
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
On May 17, 8:47 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Series Expansion <·······@gmail.com> writes:
> > On May 16, 5:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> Series Expansion <·······@gmail.com> writes:
> >> > It's easy to whip up a C macro that affects
>
> >> Forget all you know about C macros
>
> > Why should I? It's a useful job skill.
>
> Because we're talking about lisp macros and they have nothing in common with C macros.
That is incorrect. They have in common the basic properties all macros
have, and all logical consequences deriving therefrom. Particularly, a
macro is a piece of code that, where invoked, replaces its invocation
with its own output, embedded in which are copies of the arguments it
was called with.
On May 15, 3:34 pm, Kenneth Tilton <·········@gmail.com> wrote:
> Series Expansion wrote:
> > Java is Turing-complete, so it can probably be done.
>
> And before the universe comes to an end. But *just* before.
What are you using, Java 1.1? We're at Java 6 now and have had JIT and
near-C-speed performance for quite some time now.
Series Expansion wrote:
> On May 15, 3:34 pm, Kenneth Tilton <·········@gmail.com> wrote:
>> Series Expansion wrote:
>>> Java is Turing-complete, so it can probably be done.
>> And before the universe comes to an end. But *just* before.
>
> What are you using, Java 1.1? We're at Java 6 now and have had JIT and
> near-C-speed performance for quite some time now.
I was referring to development time, not runtime. You *have* programmed
a Turing machine, haven't you?
HLLs exist because we do not want to program in assembler, let alone the
Turing instruction set. Thus when comparing HLLs, citing Turing
equivalence is... oh, wait, you did that, I better not say what I think.
hth,kzo
On May 15, 8:15 pm, Kenneth Tilton <·········@gmail.com> wrote:
> Series Expansion wrote:
> > On May 15, 3:34 pm, Kenneth Tilton <·········@gmail.com> wrote:
> >> Series Expansion wrote:
> >>> Java is Turing-complete, so it can probably be done.
> >> And before the universe comes to an end. But *just* before.
>
> > What are you using, Java 1.1? We're at Java 6 now and have had JIT and
> > near-C-speed performance for quite some time now.
>
> I was referring to development time, not runtime.
So, now the "Java is slow" myth is having new life breathed into it by
claiming it makes *development* slow.
I guess there's no stopping people from believing the worst about
Java, if they're really determined to do so...
gugamilare wrote:
> 1) Java does not have dynamically created functions (or am I wrong?)
That depends on what you mean by "dynamically created". If you mean by the
program at run time, no, not without considerable effort. If you mean at need
at a point in the source code, yes, it does, although the signature must be
known beforehand.
> 2) Java Code is not an easy manipulable data
That's a design feature of Java, not a problem.
> 3) Java doesn't have macros.
That's a design feature of Java, not a problem.
> As you can see, macros not only provide a way to make your
> applications shorter or more readable, but they also make it possible
> to do somethings that otherwise couldn't be done.
I have yet to find any program requirement that couldn't be done in Java
without too much effort. As to readability, that's in the eye of the
beholder. Some Java adherents believe shorter is necessarily more readable
also, but sometimes verbosity increases readability.
Hemingway and Dickens were both powerful writers.
--
Lew
On 15 May, 14:47, ····@zedat.fu-berlin.de (Stefan Ram) wrote:
This isn't so much a direct response as a tangential comment
hence I'm not quoting any text.
I remember reading somewhere on the internet that the reason
Java does not have macros is because the creators of Java were
worried that it would lead to the creation of many mutually
incompatible and incomprehensible dialects. I remember that what
I read contained the phrase "we may even have heard of Lisp" or
something similar but a Google search did not find it. I did
find the following blog post though which compares syntactic
abstractions through macros with OO abstractions. Quite
interesting.
http://debasishg.blogspot.com/2007/01/syntax-extensibility-ruby.html
The argument that macros might lead to incomprehensible
subdialects of a language has been put forward on
comp.lang.python on some occasions when macros were discussed. I
haven't kept any links but if you search for "macros" on
comp.lang.python you'll find such threads. On at least 2
occasions a story was presented where someone was working in
some university department , a few research teams were working
on the same problem , each team had written their own macro
extensions to address this problem and because of that each
group could not understand the code of the other groups. Lisp
people who participated in such discussions pointed out that
this can happen with functions just as well as it can happen
with macros.
I'm on the Lisp side of this. As long as one doesn't
intentionally write obfuscated code and documents one's macros I
don't believe that macros present any greater dangers of
incomprehensibility than any other programming construct.
--
Become a human being through great effort to purge yourself of
your hatred and insanity.
Erik Naggum
From: Tamas K Papp
Subject: Re: macros (was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <775al2F1g583nU1@mid.individual.net>
On Fri, 15 May 2009 13:47:00 +0000, Stefan Ram wrote:
> The macro here is marked by the occurence of »=?«, which is not a
> regular Java operator, but part of my hypothetical macro call pattern.
>
> The problem here is readability:
>
> Can others know, what »=?« means in my macro package? Can they know
> how to immediately find its documentation?
Yes, of course. You should name your macro informatively (CL
programmers usually do), and with a decent IDE, you should have no
problem accessing documentation with a few keystrokes.
> If I invent and use this macro now, will even I myself remember its
> meaning a year later?
You could say the same about functions. Then you should not use them,
because who knows if you will remember what they do in a year :-)
Generally, this is not a problem.
> The same coded in Java without macros /is/ more verbose, but also more
> readable to someone who knows Java:
Macros provide abstraction: the idea is that you do not have to parse
the code mentally if you know what it _does_. Abstraction makes code
more readable.
It is very strange how some programmers resist the abstraction
provided by macros. I would be surprised if a mathematician argued
that one should not prove new theorems, because it is hard to remember
what they show a year later. Yet I see this attitude with non-Lisp
programmers. Weird.
Tamas
On 15 maio, 10:56, Tamas K Papp <······@gmail.com> wrote:
> On Fri, 15 May 2009 13:47:00 +0000, Stefan Ram wrote:
> > The macro here is marked by the occurence of »=?«, which is not a
> > regular Java operator, but part of my hypothetical macro call pattern.
>
> > The problem here is readability:
>
> > Can others know, what »=?« means in my macro package? Can they know
> > how to immediately find its documentation?
>
> Yes, of course. You should name your macro informatively (CL
> programmers usually do), and with a decent IDE, you should have no
> problem accessing documentation with a few keystrokes.
>
> > If I invent and use this macro now, will even I myself remember its
> > meaning a year later?
>
> You could say the same about functions. Then you should not use them,
> because who knows if you will remember what they do in a year :-)
>
> Generally, this is not a problem.
>
> > The same coded in Java without macros /is/ more verbose, but also more
> > readable to someone who knows Java:
>
> Macros provide abstraction: the idea is that you do not have to parse
> the code mentally if you know what it _does_. Abstraction makes code
> more readable.
>
> It is very strange how some programmers resist the abstraction
> provided by macros. I would be surprised if a mathematician argued
> that one should not prove new theorems, because it is hard to remember
> what they show a year later. Yet I see this attitude with non-Lisp
> programmers. Weird.
>
> Tamas
I agree with you. As a mathematician, I believe that CL macros are to
programming as abstractions are to mathematics. For instance,
mathematical induction is a kind of abstraction (a very simple and
useful one). This means that languages like Java can't be used to
"prove anything by induction" ;-) it must do everything from bare
metal (just like formal mathematics, and by formal mathematics I mean
http://us.metamath.org/mpegif/zorn2.html ).
["Followup-To:" header set to comp.lang.lisp.]
On 2009-05-15, Stefan Ram <···@zedat.fu-berlin.de> wrote:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>Well at that point I can only say that, well over here we're not (all)
>>raving maniacs, that we have useful tools that help solve or obviate a
>>lot of problems found with other programming languages, and point to
>>that tutorial: http://www.lisperati.com/casting.html
>
> Assume for a moment I had advanced macro capabilities in Java.
> I'd write:
>
> public static String getMultiValue( Object valueObject )
> { String result = null;
> if( valueObject == null )result = null;
>
> else if( StringValue stringValue =? valueObject )
> result = getStringValue( stringValue );
>
> else if( SprayValue sprayValue =? valueObject )
> result = getSetValue( setValue );
>
> return result; }
>
> The macro here is marked by the occurence of »=?«, which is
Please don't use non-USASCII characters in comp. discussion groups.
The = character will do.
> not a regular Java operator, but part of my hypothetical macro
> call pattern.
>
> The problem here is readability:
Is it?
> Can others know, what = means in my macro package?
> Can they know how to immediately find its documentation?
You should be prepared to raise exactly the same objection for any other
identifier you define: class, function, variable, etc.
Do others know what getMultiValue means in your library?
Can they immediately find its documentation?
Obviously not if there is no documentation, and not
immediately if it's not indexed and cross-referenced.
What does that have to do with anything?
> If I invent and use this macro now, will even I myself
> remember its meaning a year later?
>
If you invent a function now, will you remember its meaning?
> The same coded in Java without macros /is/ more verbose,
> but also more readable to someone who knows Java:
By this logic, the code behind a function is also more readable.
> public static String getMultiValue( Object valueObject )
Similarly, I have no clue what this call means:
getMultiValue(valueObject)
Of coruse the name suggests that it gets a multi value, whatever
that is. But macros also have suggestive names just like that.
So now if you replace all occurences of that function
by the following code, it's more obvious:
> { String result = null;
> if( valueObject == null )result = null;
>
> else if( valueObject instanceof StringValue )
> { StringValue stringValue =( StringValue )valueObject;
> result = getStringValue( stringValue ); }
>
> else if( valueObject instanceof SprayValue )
> { SprayValue setValue =( SprayValue )valueObject;
> result = getSetValue( setValue ); }
>
> return result; }
So like, let's not use functions; they obfuscate code.
We should also recursively expand getSetValue too in the above.
Basically, code is only readable when it uses only the built-in syntax, and
only standard library functions that come from the language specification.
Thus, everything should be written as one large brace statement with no
confusing named abstractions that invoke something elsewhere.
A novel reads nicely from cover to cover in one pass, and a program should be
similarly readable from opening brace to closing brace.
···@zedat.fu-berlin.de (Stefan Ram) writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>Well at that point I can only say that, well over here we're not (all)
>>raving maniacs, that we have useful tools that help solve or obviate a
>>lot of problems found with other programming languages, and point to
>>that tutorial: http://www.lisperati.com/casting.html
>
> Assume for a moment I had advanced macro capabilities in Java.
> I'd write:
>
> public static String getMultiValue( Object valueObject )
> { String result = null;
> if( valueObject == null )result = null;
>
> else if( StringValue stringValue =? valueObject )
> result = getStringValue( stringValue );
>
> else if( SprayValue sprayValue =? valueObject )
> result = getSetValue( setValue );
>
> return result; }
>
> The macro here is marked by the occurence of �=?�, which is
> not a regular Java operator, but part of my hypothetical macro
> call pattern.
>
> The problem here is readability:
>
> Can others know, what �=?� means in my macro package?
> Can they know how to immediately find its documentation?
>
> If I invent and use this macro now, will even I myself
> remember its meaning a year later?
These are valid questions.
Happily they have been solved by Lisp programmers, perhaps even before
you were born.
To help knowing what =? means, lisp programmers tend to avoid using
punctuation character in their operator names. They rather use
english words (separated by dashes). For example, they would have
used 'equivalent' instead of '=?'.
Do you think Java programmers would be able to use this advanced
technology? The reference manuals you need to consult to use it are
rather thick. Cf. http://www.merriam-webster.com/
More over, to help knowing what arguments a new operator such as
'equivalent' may take, they use another technological advancement :
the parentheses. Stand with me, it's rather complicated. They use
two (*TWO* !) special characters, named 'open parenthesis' and 'close
parenthesis' that look like: '(' and ')'. The trick here is that
they put all the arguments used by the new operators 'inside' the
parentheses. This means that they write: the open parenthesis '(',
the operator (eg. 'equivalent'), and the arguments separated by
spaces, and finally the close parenthesis ')'. This may sound
complicated as explained here, but it's rather simple:
(equivalent stringValue valueObject)
So there you can see clearly that the operator is meant to indicate
whether the _two_ arguments (in this case) stringValue and valueObject
are equivalent.
Notice that if you have a keyboard of the most recent generation you
may be lucky to be able to enter them directly with a special movement
of the fingers: first press one of the two "shift" keys, keep one
finger on the shift key pressed, and then type either 9 or 0. You
should get an open parenthesis for 9, and a close parenthesis for 0.
You may laugh at my explications here, but this is really quite
advanced a technology. They are a lot of happy consequences from the
use of these "parentheses". To answer your second question, one of
the consequences is that parsing lisp expressions is trivial; the
grammar is:
expression ::= atom | '(' { expression } ')' .
Yes, only one non-terminal, only one terminal (plus the two
parentheses), and only one grammar rule. It's can hardly be simplier.
So this grammar can easily be implemented in any tool such as in
editors. And therefore editors can easily provide support for
syntactic editing. Since the operator is always placed in the first
position of a form (a code expression), the editors can easily find
it, and then call up the documentation about the operator.
And finally, using these two advanced technologies, your third
question becomes irrelevant. One year later, you won't need to
remember what it is, you will just read the expression and be able to
understand what it does without even needing to check the source of
the macro.
But notice that if you have some doubt, you may:
- ask the editor to show you the documentation.
- ask the editor to show you the source.
- ask the lisp system to expand the macro call, so you can see the
code that's generated, and if you can understand it, you will
understand the meaning of the macro.
> The same coded in Java without macros /is/ more verbose,
> but also more readable to someone who knows Java:
>
> public static String getMultiValue( Object valueObject )
> { String result = null;
> if( valueObject == null )result = null;
>
> else if( valueObject instanceof StringValue )
> { StringValue stringValue =( StringValue )valueObject;
> result = getStringValue( stringValue ); }
>
> else if( valueObject instanceof SprayValue )
> { SprayValue setValue =( SprayValue )valueObject;
> result = getSetValue( setValue ); }
>
> return result; }
Why do you stop there? Why don't you read the JVM byte code to
understand the method? It would be more readable and more
understandable, wouldn't it?
--
__Pascal Bourguignon__
eric-and-jane-smith <·······@nospam.com> wrote:
+---------------
| ···@informatimago.com (Pascal J. Bourguignon) wrote:
| > Lisp macros are just a much simplier and much more powerful to archive
| > the same results much faster.
|
| It's hard to make the power of CL macros clear to non-Lispers. They think
| in terms of the macros of other programming languages, and have no idea
| what CL macros are. From their point of view, we seem to be telling them
| we want to use macros as a klugey substitute for C++ templates, or for the
| Java type system, or whatever.
+---------------
Oddly enough, it is *much* easier to explain Lisp macros to those
who have experience with assembly language macros in such "antiques"
as the DEC PDP-10 or IBM 360/370 mainframes which supported looping,
deconstruction/construction of symbol names (down to individual
characters), definition of new macros *by* macros, access to the
assembler's symbol table at compile time (accessing & mutating the
values of symbols and tags), "pass1" vs. "pass2" conditionals
(collect data from the whole program in pass 1 and drop it into
instruction and/or data locations in pass 2), etc., etc.[1]
But for those whose first or only experience of "macros" came from
the crippled incarnation of them in C, well, you are quite correct,
sadly.
-Rob
[1] I have spoken at length here several times previously on the
wonders of PDP-10 assembler macros, so won't bore you again. For
the curious, search for "rpw3", "FOCAL" & "PDP-10".
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> eric-and-jane-smith <·······@nospam.com> wrote:
> +---------------
> | ···@informatimago.com (Pascal J. Bourguignon) wrote:
> | > Lisp macros are just a much simplier and much more powerful to archive
> | > the same results much faster.
> |
> | It's hard to make the power of CL macros clear to non-Lispers. They think
> | in terms of the macros of other programming languages, and have no idea
> | what CL macros are. From their point of view, we seem to be telling them
> | we want to use macros as a klugey substitute for C++ templates, or for the
> | Java type system, or whatever.
> +---------------
>
> Oddly enough, it is *much* easier to explain Lisp macros to those
> who have experience with assembly language macros in such "antiques"
> as the DEC PDP-10 or IBM 360/370 mainframes which supported looping,
> deconstruction/construction of symbol names (down to individual
> characters), definition of new macros *by* macros, access to the
> assembler's symbol table at compile time (accessing & mutating the
> values of symbols and tags), "pass1" vs. "pass2" conditionals
> (collect data from the whole program in pass 1 and drop it into
> instruction and/or data locations in pass 2), etc., etc.[1]
>
> But for those whose first or only experience of "macros" came from
> the crippled incarnation of them in C, well, you are quite correct,
> sadly.
The preprocessor in gcc lets you write macros that glue symbol names
together out of pieces. I think it's not an ANSI-standard feature
though. On the other hand, gcc-only compatibility is enough to get you
pretty wide operating-system and hardware portability these days.
On 16 May, 03:18, Seamus MacRae <··········@live.ca.nospam> wrote:
>
> The preprocessor in gcc lets you write macros that glue symbol names
> together out of pieces. I think it's not an ANSI-standard feature
> though. On the other hand, gcc-only compatibility is enough to get you
> pretty wide operating-system and hardware portability these days.
If you are referring to the ## operator it exists in the C99
standard.
Seamus MacRae <··········@live.ca.nospam> wrote:
+---------------
| Rob Warnock wrote:
| > Oddly enough, it is *much* easier to explain Lisp macros to those
| > who have experience with assembly language macros in such "antiques"
| > as the DEC PDP-10 or IBM 360/370 mainframes which supported looping,
| > deconstruction/construction of symbol names (down to individual
| > characters), definition of new macros *by* macros, access to the
| > assembler's symbol table at compile time (accessing & mutating the
| > values of symbols and tags), "pass1" vs. "pass2" conditionals
| > (collect data from the whole program in pass 1 and drop it into
| > instruction and/or data locations in pass 2), etc., etc.[1]
| >
| > But for those whose first or only experience of "macros" came from
| > the crippled incarnation of them in C, well, you are quite correct,
| > sadly.
|
| The preprocessor in gcc lets you write macros that glue symbol names
| together out of pieces. I think it's not an ANSI-standard feature
| though.
+---------------
As far as I know, the # (stringify) and ## (concat) macro expansion
operators now *are* a part of ANSI C. I think they came in with C99,
but I'm not sure.
+---------------
| On the other hand, gcc-only compatibility is enough to get you
| pretty wide operating-system and hardware portability these days.
+---------------
(*yawn*) Come back when macros in GCC (or any other C compiler)
can take a symbol name *apart*, and place the characters of the
name in individual locations, generating new variable names to
disambiguate dups, counting the length of the symbol, and computing
a hash of the name, and other things like that; e.g. a macro XPLOD(x)
that can do this:
XPLOD(hello)
expands to:
int var_h = 104;
int var_e = 101;
int var_l = 108;
int var_l2 = 108;
int var_o = 111;
int num_hello_vars = 5;
int hash_of_hello = 25120; /* hash = ((hash * 85) + char[i]) & 0xffff; */
char upcase_HELLO[] = {72, 69, 76, 76, 79, 0};
PDP-10 assembler macros could do that; so can Lisp macros.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> As far as I know, the # (stringify) and ## (concat) macro expansion
> operators now *are* a part of ANSI C. I think they came in with C99,
> but I'm not sure.
They were described in the gcc docs as nonportable. This was probably
before C99 though.
The C world moves slowly. C99 was in the making for ages and still isn't
100% supported. The full C++ spec likewise. There are a lot of compilers
that deal very poorly with even simple use of templates, many producing
duplicate symbol errors if you use a template with the same args in more
than one compilation unit, which is valid C++ but which a lot of linkers
still don't like.
> +---------------
> | On the other hand, gcc-only compatibility is enough to get you
> | pretty wide operating-system and hardware portability these days.
> +---------------
>
> (*yawn*) Come back when macros in GCC (or any other C compiler)
> can do this:
>
> XPLOD(hello)
>
> expands to:
>
> int var_h = 104;
> int var_e = 101;
> int var_l = 108;
> int var_l2 = 108;
> int var_o = 111;
> int num_hello_vars = 5;
> int hash_of_hello = 25120; /* hash = ((hash * 85) + char[i]) & 0xffff; */
> char upcase_HELLO[] = {72, 69, 76, 76, 79, 0};
How useless.
Seamus MacRae wrote:
> Rob Warnock wrote:
>> As far as I know, the # (stringify) and ## (concat) macro expansion
>> operators now *are* a part of ANSI C. I think they came in with C99,
>> but I'm not sure.
>
> They were described in the gcc docs as nonportable. This was probably
> before C99 though.
Both # and ## are required by C89.
> The C world moves slowly. C99 was in the making for ages and still isn't
> 100% supported. The full C++ spec likewise. There are a lot of compilers
> that deal very poorly with even simple use of templates, many producing
> duplicate symbol errors if you use a template with the same args in more
> than one compilation unit, which is valid C++ but which a lot of linkers
> still don't like.
True.
But I have not seen a compiler where # and ## were not working for
a couple of decades.
Arne
On May 15, 3:38 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
> > The intent could be made clear by adding comments, but now the same
> > information is in two places: in the code and in comments, and they
> > can get out of synch.
>
> > Or you can use static type checking. Then the types in the code
> > document the intent, and the things that have to be consistent (the
> > information about intent, and the actual objects put in the list and
> > actions performed on the items taken out) are checked for consistency
> > automatically by the computer to boot. They can't get out of
> > synch. And if there's an error, the intent is clear. If a List<Object>
> > item is assumed Runnable assuming they're runnable is the error. If a
> > non-Runnable is put in a List<Runnable> putting in a non-runnable is
> > the error.
>
> > Problem solved.
>
> There's a easier and more powerful way to solve that kind of problem.
> It is to write a DSL (ie. macros) in Lisp, to generate correct code in
> the first place.
>
> Of course, you will object how to be sure the macros are correct?
> I'll object how to be sure your type expressions are correct?
The compiler checks them. The type and object system ends up being a
DSL, but one whose syntax and type-semantics can be checked by
automation. Your DSL will just crash with some run-time error if you
goofed.
The major benefit is with later, incremental changes rather than
during system design though. Making the incremental change to the
static-type system is like plugging something in where, if you get the
plug backwards, it won't fit. Making the incremental change to the
dynamic-type system is like plugging something in where, if you get
the plug backwards, it seems fine until you flip the on switch, and
then you have inconvenienced the local fire brigade.
There's a tradeoff, to be sure. Dynamic seems to beat static for small
jobs and certain kinds of tinkering, and for things that are used
interactively by a hacker that can fix or reprogram them on the fly.
For stand-alone deployments of large systems to non-developer users,
on the other hand, static seems to win out.
Static does mean spending some time figuring out and then coding the
type system. However, the time spent *figuring out* the type system
needs to be spent no matter what, or the durn thing won't work. The
time spent *coding* the type system does two things:
1. It documents the types of things in the code. If the code will
ever have to be maintained by someone unfamiliar with it,
including perhaps your own future self after a hiatus, this will
need to be done anyway or the code won't be maintainable.
2. It lets the compiler catch type errors quickly, and locate them
quickly. With dynamic typing, a type error will produce a
run-time error that may appear far from the actual location of
the bug, for instance of the wrong sort of object is added to
a collection and much later removed, then an operation invoked
on it that it doesn't support. I'm not sure what you'd get in
lisp, probably a logic error rather than an exception; Smalltalk
would produce the dreaded "doesNotUnderstand" box and Java a
ClassCastException or NoSuchMethodError (Object taken from
raw List and either cast or operated on reflectively).
Java with a List<Foo> is another story: as soon as you write a
line of code that tries to put a non-Foo into the list, it
gets a red wavy underline in your IDE!
This gets into the flip-side of the tradeoff. Besides developing the
type system and documenting the types of values and variables in the
code, which probably needed to be done in some manner anyway, you've
traded off a bit more coding time for a lot less debugging time. Some
errors you will discover within *seconds* of making them that would
have required *hours* to hunt down otherwise. That's savings you can
take to the bank. Literally, if you're a manager paying a bunch of
coders' salaries, and their productivity has just shot up through the
roof.
The system size is probably key, and whether the end-user can be
expected to interactively debug and tinker with it. For small systems,
the code base is not large enough for hunting down the type error to
take hours, and dynamic languages seem to better support on-the-fly
modification for various reasons. Glue scripts are another case in
point.
Furthermore, it's worth noting that most "statically typed" languages
give you the option to take or leave compiler validation of your type
logic, while most dynamically typed languages are exactly that -- no
such option, you can't have it even if you want it.
C lets you dodge the type system completely with arbitrary casts and
the "union" construct. So does C++, though C++ adds a dynamic_cast
operator that acts like Java's cast (i.e. is a type-checking cast).
Java, as noted, lets you use nothing but Object and reflection, or
lots of casting and untyped collections, if you want to (most Java
programmers don't, though -- I wonder why?). All of them let you
eschew object orientation and just have structs/classes with public
fields and external functions to manipulate these if you want to, for
that matter. Heck, you can defeat the type system in Java almost
entirely by using arrays of Objects, eschewing named fields and the
primitive types like int and double.
Nobody does this though.
> And unless your type system is Turing Complete, there are necessarily
> specifications you cannot write.
The type system doesn't need to be Turing-complete unless it needs to
be genuinely dynamic, changing at run-time, or else essentially
embodying the entire semantics of the code.
Type systems normally embody the *static* aspects of the code only --
what sorts of things go here, what this thing can do rather than what
specific thing is here, what this thing is currently doing.
When a complex relationship exists, like "this should be an integer
unless that's null, and then it should be a Rocket instead" are better
expressed with an encapsulated object, with an integer field, a Rocket
field, and some other field, and the other field determining which of
the first two are in use. Callers to the object needn't concern
themselves with this internal matter, and the preservation of the
required invariants is the responsibility of the small amount of code
in one single class. If the invariant is ever violated, you can
immediately narrow down the location of at least one bug to that small
bit of the codebase.
If a similar invariant is ever violated in a dynamic system that
accesses those fields from all over and has complex, Turing-complete
type-system rules of some sort, you'll have to hunt for it all over
the place, by contrast. Any code that touches those fields is suspect.
Indeed, since the object with these fields could have snuck into
someplace it didn't belong, without a peep from the compiler, any code
at all is suspect, since code meant to store an integer in a hash
field in something else might have accidentally overwritten your
Rocket after being passed the wrong type of object. And of course the
code that represents the Turing-complete type-system rule might
contain the error. Maybe the fields didn't get monkeyed with at all,
and the run-time error claiming they did was itself issued in error.
> And when your type system is Turing Complete, there are necessarily
> bugs written in it, and a lot of time spend on it, because of the
> syntactic complexity (eg. C++ templates!).
Upfront cost, downstream savings (if done right).
> Lisp macros are just a much simplier and much more powerful to archive
> the same results much faster.
What results? Compile-time type safety? I doubt it, unless you're
writing a C or Java compiler in Lisp. :)
Maybe you mean to suggest that the type-checking be done dynamically,
at run-time, with type-checking code everywhere when things are added
to/retrieved from collections, passed as parameters, and everything.
Java does this to some extent, when there's a need to cast something
or when something's taken out of a generic collection. However, in
many circumstances like parameter-passing the type-checking has no
runtime overhead because the compiler was able to verify everything
before the program ran.
This is another area where dynamic tends to lose to static:
performance. In the absence of dynamic type checking, the system is
probably somewhat buggy and unstable, which costs in downtime. In the
presence of dynamic type checking, the system may be more robust,
because bugs were easier to find and fix during testing, but areas not
covered by testing will be dodgy and the dynamic type checking takes
its toll on speed. In the presence of static type checking, 100% of
the code is free of type errors according to the compiler, before it's
even run, so areas not covered by testing still won't contain type
errors (though they may contain logic errors). The smaller amount of
dynamic type checking takes much less of a toll on performance. Last,
but certainly not least, because your compiler actually groks the type
system it may be able to make all kinds of clever optimizations that
would not be safe to make on dynamically-typed code. The speed boost
from this alone could be the deciding factor for CPU-bound tasks, or
for systems with strict real-time requirements (which, in practice,
are almost always coded in C).
Seamus MacRae <··········@live.ca.nospam> wrote in
·················@news.motzarella.org:
> If it merely transforms the list, and doesn't care whether they're
> runnable, it should not matter. Suppose it sorts the list by priority.
But what if it does care? What if it takes a list of a million objects,
and deletes 17 of them from that list, because those 17 aren't runnable?
In Common Lisp, deleting 17 objects from a list of a million can be done
quickly and efficiently. But you seem to be implying you have to copy the
other 999983 objects to a list of runnables, because otherwise they would
be in a list of objects, even though they're all runnable.
eric-and-jane-smith wrote:
> Seamus MacRae <··········@live.ca.nospam> wrote in
> ·················@news.motzarella.org:
>
>> If it merely transforms the list, and doesn't care whether they're
>> runnable, it should not matter. Suppose it sorts the list by priority.
>
> But what if it does care? What if it takes a list of a million objects,
> and deletes 17 of them from that list, because those 17 aren't runnable?
>
> In Common Lisp, deleting 17 objects from a list of a million can be done
> quickly and efficiently. But you seem to be implying you have to copy the
> other 999983 objects to a list of runnables, because otherwise they would
> be in a list of objects, even though they're all runnable.
Not in Java. In Java, you can use:
/**
* Removes non-<code>Runnable</code> objects from <code>list</code>
* and returns pruned list as a <code>List<Runnable></code>;
* caller is responsible for synchronizing the list if necessary.
*/
@SuppressWarnings("unchecked")
/*
* Justification: the only unchecked cast is in the return
* line, and all non-Runnables have been removed from the
* list at that time. The returned list is a list of
* Runnables unless a data race occurred. Correct behavior,
* as ever, depends on the caller synchronizing where
* appropriate.
*/
public List<Runnable> pruneList (List<?> list) {
for (Iterator<?> i = list.iterator(); i.hasNext();) {
// Old "for" used intentionally
Object o = i.next();
if (!(o instanceof Runnable)) i.remove();
}
return (List<Runnable>)list;
}
Untested. The intent should be pretty clear, though. The reason for
using the old "for" is to get efficient removal. Performance is O(n) for
a LinkedList, and no copying is done.
A version that copies the list would be thread-safer:
/**
* Makes and returns a copy of <code>list</code> with only the
* <code>Runnable</code> objects, whose order is preserved;
* caller is responsible for synchronizing the list if necessary.
*/
public List<Runnable> pruneList2 (List<?> list) {
List<Runnable> ret = new ArrayList<Runnable>(list.size());
for (Object o : list) {
if (o instanceof Runnable) ret.add((Runnable)o);
}
return ret;
}
This makes a copy with only the runnable objects. Copy cost is O(number
of runnables in source list). Only pointers are copied, rather than the
actual objects in the list. The cast to Runnable should never fail. No
unchecked cast is used in this version. With respect to threading, since
the result list is local until the method exits and the object is local
from before the instanceof test until insertion in the result list:
1. The result list will never, EVEN WITH a data race, come out
containing a non-Runnable.
2. A weak consistency may apply to concurrent use of the source list:
an object in the output list will have been in the input list at the
time of the method call or added while it was running, and an object
not in the output list either was not in the input list at the
time of the method call, was removed while it was running, or was not
Runnable. Whether this actually works depends on whether the source
list has (at least) weakly consistent concurrent iteration and
modification. The java.util lists don't; this method may throw
ConcurrentModificationException. The java.util.concurrent lists are
another matter (for instance, CopyOnWriteArrayList).
On 2009-05-15, Seamus MacRae <··········@live.ca.nospam> wrote:
> eric-and-jane-smith wrote:
>> Seamus MacRae <··········@live.ca.nospam> wrote in
>> ·················@news.motzarella.org:
>>
>>> If it merely transforms the list, and doesn't care whether they're
>>> runnable, it should not matter. Suppose it sorts the list by priority.
>>
>> But what if it does care? What if it takes a list of a million objects,
>> and deletes 17 of them from that list, because those 17 aren't runnable?
>>
>> In Common Lisp, deleting 17 objects from a list of a million can be done
>> quickly and efficiently. But you seem to be implying you have to copy the
>> other 999983 objects to a list of runnables, because otherwise they would
>> be in a list of objects, even though they're all runnable.
>
> Not in Java. In Java, you can use:
>
> /**
> * Removes non-<code>Runnable</code> objects from <code>list</code>
> * and returns pruned list as a <code>List<Runnable></code>;
> * caller is responsible for synchronizing the list if necessary.
> */
> @SuppressWarnings("unchecked")
> /*
> * Justification: the only unchecked cast is in the return
> * line, and all non-Runnables have been removed from the
> * list at that time. The returned list is a list of
> * Runnables unless a data race occurred. Correct behavior,
> * as ever, depends on the caller synchronizing where
> * appropriate.
> */
> public List<Runnable> pruneList (List<?> list) {
> for (Iterator<?> i = list.iterator(); i.hasNext();) {
> // Old "for" used intentionally
> Object o = i.next();
> if (!(o instanceof Runnable)) i.remove();
> }
> return (List<Runnable>)list;
> }
>
> Untested.
The above vomit maens:
;; By default, all things are assumed non-runnable.
(defmethod is-runnable (obj) nil)
;; But things subclassed from runnable, well, are.
(defmethod is-runnable ((obj runnable-class)) t)
;; Function call to remove non-runnables from a some-list, returning
;; a new list with only runnables in it:
(remove-if-not 'is-runnable some-list)
REMOVE-IF-NOT is a functional construct which leaves the old list alone
(but the new list may share substructure with the old). If you
want to modify the original list, use DELETE-IF-NOT.
(setf some-list (delete-if-not 'is-runnable some-list))
Obviously correct by inspection.
Kaz Kylheku wrote:
> On 2009-05-15, Seamus MacRae <··········@live.ca.nospam> wrote:
>> eric-and-jane-smith wrote:
>>> Seamus MacRae <··········@live.ca.nospam> wrote in
>>> ·················@news.motzarella.org:
>>>
>>>> If it merely transforms the list, and doesn't care whether they're
>>>> runnable, it should not matter. Suppose it sorts the list by priority.
>>> But what if it does care? What if it takes a list of a million objects,
>>> and deletes 17 of them from that list, because those 17 aren't runnable?
>>>
>>> In Common Lisp, deleting 17 objects from a list of a million can be done
>>> quickly and efficiently. But you seem to be implying you have to copy the
>>> other 999983 objects to a list of runnables, because otherwise they would
>>> be in a list of objects, even though they're all runnable.
>> Not in Java. In Java, you can use:
>>
>> /**
>> * Removes non-<code>Runnable</code> objects from <code>list</code>
>> * and returns pruned list as a <code>List<Runnable></code>;
>> * caller is responsible for synchronizing the list if necessary.
>> */
>> @SuppressWarnings("unchecked")
>> /*
>> * Justification: the only unchecked cast is in the return
>> * line, and all non-Runnables have been removed from the
>> * list at that time. The returned list is a list of
>> * Runnables unless a data race occurred. Correct behavior,
>> * as ever, depends on the caller synchronizing where
>> * appropriate.
>> */
>> public List<Runnable> pruneList (List<?> list) {
>> for (Iterator<?> i = list.iterator(); i.hasNext();) {
>> // Old "for" used intentionally
>> Object o = i.next();
>> if (!(o instanceof Runnable)) i.remove();
>> }
>> return (List<Runnable>)list;
>> }
>>
>> Untested.
>
> The above vomit
Fascinating. An illogical, emotional outburst in response to ordinary
computer code.
> maens:
>
> ;; By default, all things are assumed non-runnable.
>
> (defmethod is-runnable (obj) nil)
>
> ;; But things subclassed from runnable, well, are.
>
> (defmethod is-runnable ((obj runnable-class)) t)
>
> ;; Function call to remove non-runnables from a some-list, returning
> ;; a new list with only runnables in it:
>
> (remove-if-not 'is-runnable some-list)
>
> REMOVE-IF-NOT is a functional construct which leaves the old list alone
> (but the new list may share substructure with the old). If you
> want to modify the original list, use DELETE-IF-NOT.
>
> (setf some-list (delete-if-not 'is-runnable some-list))
>
> Obviously correct by inspection.
Whoops. There are at least two things missing from your version:
1. Type-safety. There's nothing to identify the output list as
containing only runnables. Therefore there's nothing to identify
the input list to someplace else as containing only runnables. So
the compiler won't catch it if the wrong list gets used there.
2. Documentation. About half my code was documentation. The first
comment would be processed by the Java tool-chain to produce
an HTML file documenting the method, its behavior, and the
conditions under which it was guaranteed to do the right thing.
Your code has no such documentation, and indeed you didn't
even define a callable function prune-list or whatever, let
alone make it so that anyone could right click on the word
"prune-list" in some code subsequently and get a concise little
pop-up telling them exactly what it did and what its preconditions
were. Certainly I haven't a clue how thread-safe your
implementation is just from looking at the code.
Your remove-if-not version sounds like it might be thread-safe, because
it sounds like it behaves like my second (and not-quoted-by-you) code
sample, which copies the list. Someone else expressed concern about the
time spent copying objects (though in Java, at least, you'd be copying
pointers rather than whole objects).
Your delete-if-not version sounds like it probably is not thread-safe.
Is there a way to associate a monitor with the list and lock it in lisp?
There is in Java, and it's very simple:
synchronized (list) {
runnableList = pruneList(list);
for (Runnable r : runnableList) {
r.run();
}
}
This removes the non-runnables and runs the runnables in sequence, while
holding a monitor associated with the list.
As an aside, your version seems to be prescriptive rather than
descriptive -- def statements that execute rather than declarations of
classes and methods. If so, this points to a different problem: what
happens if there are circular dependencies? In Java, if two classes or
other chunks of code need to refer to one another they can. In Lisp, it
sounds like an imperative interpreter runs down a list of def-foo
commands to actually build the program structure. If it executes the
statement that creates the foo-bar function first, and this references
the baz-quux function, the latter will still be undefined.
This can also happen in C but C lets you declare a function prototype
without specifying its implementation, or name a struct or similarly, so
you can subsequently reference it; you would ordinarily prototype foobar
and bazquux together in a header and then provide their implementations
in a .c file, which would include that header; the foobar implementation
can then refer to the bazquux one without any problems. C++ is similar,
though you can also implement them as inlines in the header:
int bazquux(string);
inline bool foobar(string s) { return bazquux(s) == 0; }
inline int bazquux(string s) {
int r = get_length(s);
if (r == 0) return 0;
return r + foobar(get_prefix(s))?1:0;
}
(with get_length and get_prefix presumed defined somewhere else, and
get_prefix(s) always shorter than s).
Java is even smarter: you can just have methods, classes, and suchlike
refer to each other, click build in your IDE, and off you go.
Java also acknowledges that the "shift" key has other uses than just
with the 9 and 0 keys. :)
Seamus MacRae <··········@live.ca.nospam> writes:
> Frank GOENNINGER wrote:
>>
>> Well, it does tell that you rely on the compiler to check the type of an
>> object. I do say that a pure static typing is a PITA when aiming at
>> reusable code. I had to do coding where I could not foresee all possible
>> data types being used - just "objects".
>
> That's why we Java programmers have the Object class, generics, and
> other goodies. For example if we want to require that some objects
> have a run() method, but nothing else, we can use a List<Runnable> to
> hold them, and they can be of many different actual types. And the
> compiler will alert us if we try to put something non-runnable into
> the list.
No dynamically (= at run time) created classes? Rare case, you say?
So many opinions ...
Frank
Frank GOENNINGER wrote:
> Seamus MacRae <··········@live.ca.nospam> writes:
>
>> Frank GOENNINGER wrote:
>>> Well, it does tell that you rely on the compiler to check the type of an
>>> object. I do say that a pure static typing is a PITA when aiming at
>>> reusable code. I had to do coding where I could not foresee all possible
>>> data types being used - just "objects".
>> That's why we Java programmers have the Object class, generics, and
>> other goodies. For example if we want to require that some objects
>> have a run() method, but nothing else, we can use a List<Runnable> to
>> hold them, and they can be of many different actual types. And the
>> compiler will alert us if we try to put something non-runnable into
>> the list.
>
> No dynamically (= at run time) created classes? Rare case, you say?
>
> So many opinions ...
Java can create classes at run time. As a rule, these will implement an
interface, so existing interface but novel implementation of it.
Sometimes, an abstract superclass.
PropertyResourceBundle is one example. Any dynamically-loaded
implementation of a service-provider interface, such as in JAI and a lot
of JavaEE and networking stuff, will provide more examples. You can even
generate Java source code and invoke the compiler classes to compile
them on the fly, then use a classloader to instantiate the results.
Last but not least, Java can even use a completely unfamiliar class that
implements no known interface, but you'll have to use reflection to do
anything with it at all, and reflection is slow and brittle.
In fact, using nothing but Object-type references and reflection, with
no interfaces, and having a lot of NoSuchMethodExceptions and the like
to handle, resembles trying to do OO programming in many of your
dynamically-typed languages.
Java 6's inclusion of a compiler API means it's relatively easy to
translate almost arbitrary Smalltalk code into Java. (Blocks need to be
faked, but can be; you can use objects and reflection, or use arrays to
fake mutable local variables visible inside the closure and some sort of
exception to fudge the nonlocal returns.)
However, trying to actually code that way in Java will give you a headache.
In article <··············@goenninger.net>,
Frank GOENNINGER <······@googlemail.com> wrote:
> > Seed7 Homepage: http://seed7.sourceforge.net
> > Seed7 - The extensible programming language: User defined statements
> > and operators, abstract data types, templates without special
> > syntax, OO with interfaces and multiple dispatch, statically typed,
> > interpreted or compiled, portable, runs under linux/unix/windows.
>
> Ah - Mac OS X?
It has a makefile, but I haven't tried building with it:
<http://seed7.sourceforge.net/faq.htm>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
On 13 Mai, 23:15, "John B. Matthews" <······@nospam.invalid> wrote:
> In article <··············@goenninger.net>,
> Frank GOENNINGER <······@googlemail.com> wrote:
>
> > > Seed7 Homepage: http://seed7.sourceforge.net
> > > Seed7 - The extensible programming language: User defined statements
> > > and operators, abstract data types, templates without special
> > > syntax, OO with interfaces and multiple dispatch, statically typed,
> > > interpreted or compiled, portable, runs under linux/unix/windows.
>
> > Ah - Mac OS X?
>
> It has a makefile, but I haven't tried building with it:
Can you do me a favor and try it (I have no possibility to do).
I would be interested to know whether it compiles without
changes and wether some explanations are needed in the
file src/read_me.txt .
Thanks for your effort in advance.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
In article
<····································@o30g2000vbc.googlegroups.com>,
·············@gmx.at wrote:
> On 13 Mai, 23:15, "John B. Matthews" <······@nospam.invalid> wrote:
> > In article <··············@goenninger.net>,
[...]
> > > Ah - Mac OS X?
> >
> > It has a makefile, but I haven't tried building with it:
>
> Can you do me a favor and try it (I have no possibility to do).
> I would be interested to know whether it compiles without
> changes and wether some explanations are needed in the
> file src/read_me.txt .
>
> Thanks for your effort in advance.
Using Mac OS X 10.5.7, gcc version 4.0.1 (Apple Inc. build 5490), I did
this:
tar -zxf seed7_05_20090510.tgz
cd seed7/src/
cp mk_osx.mak makefile
make depend
make
cd ../prg
I got 147 warnings and the following result:
./hi hello.sd7
HI INTERPRETER Version 4.5.4741 Copyright (c) 1990-2009 Thomas Mertes
262 /Users/matthews/Desktop/seed7/lib/syntax.s7i
3518 /Users/matthews/Desktop/seed7/lib/seed7_05.s7i
30 hello.sd7
3810 lines total
224117 lines per second
1694928 bytes
hello world
[Details sent via email.]
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
> From: Lew <·····@lewscanon.com>
> A good book will give an accurate picture of the language, its
> capabilities and its shortcomings. Whether it's trying to convince
> someone not to use the language or to use it is irrelevant; an
> honest assessment might well convince someone not to use it.
I agree. But in the case of Lisp I respectfully submit that any
such book might recommend not using Lisp specifically to earn lots
of money as "software engineer" but would surely recommend using
Lisp for writing your own software applications, taking advantage
of rapid development of code in a wide variety of data-processing
areas. Any book that flat out advised never using Lisp for any
purpose couldn't possibly be "good" as you described.
Please look at:
<http://www.rawbw.com/~rem/HelloPlus/hellos.html#s4outl>
and scroll down to Lesson 6 (comparison of languages) and tell me
if you disagree with my main point that Lisp is great overall,
except for specific areas where one of the other languages might be
better. IMO the "good book" you described ought to say something
approximately like what I say there.
Note, if you have suggestions for additions to what I wrote there,
such as additional problem domains where some other language is
much better than Lisp, please tell me!!
Note that for embedded systems, C used to be the only mainstream
language available (with Forth being better for some purposes
although not "mainstream" IMO), but nowadays Java is used a lot in
embedded systems such as cell-phones. I'm not sure what if anything
I should say about this topic in Lesson 6.
Robert Maas, http://tinyurl.com/uh3t wrote:
>> From: Lew <·····@lewscanon.com>
>> A good book will give an accurate picture of the language, its
>> capabilities and its shortcomings. Whether it's trying to convince
>> someone not to use the language or to use it is irrelevant; an
>> honest assessment might well convince someone not to use it.
>
> I agree. But in the case of Lisp I respectfully submit that any
> such book might recommend not using Lisp specifically to earn lots
> of money as "software engineer" but would surely recommend using
> Lisp for writing your own software applications, taking advantage
> of rapid development of code in a wide variety of data-processing
> areas. Any book that flat out advised never using Lisp for any
> purpose couldn't possibly be "good" as you described.
Irrelevant. We aren't talking about books that recommend, but books that
describe.
> Please look at:
> <http://www.rawbw.com/~rem/HelloPlus/hellos.html#s4outl>
> and scroll down to Lesson 6 (comparison of languages) and tell me
> if you disagree with my main point that Lisp is great overall,
I'm not looking at the page, being already familiar with Lisp.
> except for specific areas where one of the other languages might be
> better. IMO the "good book" you described ought to say something
> approximately like what I say there.
Whatever. I am not at all concerned with whether Lisp or any other language
is "great overall" - there are lots of "great" languages that I don't use.
Being "great" is not a criterion for whether to use it. A good book will
teach the language well enough that one can assess its utility in the context
of one's own needs, partisanship aside.
My context is along the lines of, "Would Lisp be suitable for a large-scale
insurance claim-processing system built by a team of a dozen programmers of
varying experience, maintained over several years, compared to alternatives
like C# or Java?"
--
Lew
Lew <·····@lewscanon.com> wrote in ·················@news.albasani.net:
> My context is along the lines of, "Would Lisp be suitable for a
> large-scale insurance claim-processing system built by a team of a
> dozen programmers of varying experience, maintained over several
> years, compared to alternatives like C# or Java?"
A typical highly effective use of Common Lisp for that would be that the
Lisp programmer would develop and maintain domain specific languages for
the various parts of the insurance business, and there would be people
whose expertise is in those parts of the business, who would write the
programs in those languages. The languages could be made to look more
like entering data in forms than writing programs, if that would be the
appropriate interface for the people who would do that particular work.
I don't know the insurance business well enough to give good examples,
but, as another example, suppose you have a big telephone company, that
provides both landline and wireless service to a number of cities and
states in the USA. Suppose you want to write a call center application,
so business and residential phone customers could call and make changes
to their phone service, and the call center employee could enter the
changes in real time, notifying the customer during the same call of all
the relevant details, such as their local taxes on various parts of their
service, etc. The phone company might provide thousands of different
items of phone equipment to businesses, and have a huge database of rules
and logic to determine what equipment will work together, what rates will
apply in different places at different times, etc.
A Common Lisp programmer could provide domain specific languages for
various aspects of the system, such as the database entry for the logic
rules. The people doing the database entry could be construed to be
programming the database. All other parts of the system could be
construed to be variations of the same theme. In a typical big phone
company, a system such as that is being changed constantly, to accomodate
new equipment, new taxes, changes in temporary promotions, etc. They
would typically have a large number of people spending full time entering
changes into the various databases that compose the system, such as the
above-mentioned logic rules database, etc.
By using application-specific languages, the work of all those people
could be done better and faster than if they had to struggle with
interfaces that weren't designed for their specific application.
Programmers in Java etc. often have to learn a lot of business rules and
how to implement them in Java etc. But the rules should have their own
language, so they can be stated clearly and concisely by people who are
already experts in those rules, rather than by programmers who have to
learn the rules to do the work. Common Lisp makes that kind of stuff
much easier, and can save a big company a huge amount of money, and give
them much higher quality software much sooner.
On May 13, 1:32 pm, "eric-and-jane-smith" <·······@nospam.com> wrote:
> Lew <·····@lewscanon.com> wrote ···················@news.albasani.net:
>
> > My context is along the lines of, "Would Lisp be suitable for a
> > large-scale insurance claim-processing system built by a team of a
> > dozen programmers of varying experience, maintained over several
> > years, compared to alternatives like C# or Java?"
>
> A typical highly effective use of Common Lisp for that would be that the
> Lisp programmer would develop and maintain domain specific languages for
> the various parts of the insurance business...
(yadda, yadda, yadda)
Yes, but can you write a GUI app in any dialect of Lisp and port it
easily to Windows, MacOS, and Linux, and distribute it as a simple run-
this-installer-and-away-you-go form convenient for end-users?
This is the test a language or implementation must pass before it will
see much use outside of academia and unique deployments (like that
insurance company's internal systems).
It's a test that Java, as well as (with some third-party libraries
like SDL) C and C++ have passed. I'm not aware of any Lisp that has
passed it. If there is one, I would be very interested to hear about
it, however!
Series Expansion wrote:
> On May 13, 1:32 pm, "eric-and-jane-smith" <·······@nospam.com> wrote:
>> Lew <·····@lewscanon.com> wrote ···················@news.albasani.net:
>>
>>> My context is along the lines of, "Would Lisp be suitable for a
>>> large-scale insurance claim-processing system built by a team of a
>>> dozen programmers of varying experience, maintained over several
>>> years, compared to alternatives like C# or Java?"
>> A typical highly effective use of Common Lisp for that would be that the
>> Lisp programmer would develop and maintain domain specific languages for
>> the various parts of the insurance business...
>
> (yadda, yadda, yadda)
>
> Yes, but can you write a GUI app in any dialect of Lisp and port it
> easily to Windows, MacOS, and Linux, and distribute it as a simple run-
> this-installer-and-away-you-go form convenient for end-users?
Yes.
>
> This is the test a language or implementation must pass before it will
> see much use outside of academia and unique deployments (like that
> insurance company's internal systems).
Passed the test, didn't help. No, the test it must pass is is it The
Latest Thing. We're thinking maybe on our hundredth anniversary we'll
get there.
>
> It's a test that Java, as well as (with some third-party libraries
> like SDL) C and C++ have passed. I'm not aware of any Lisp that has
> passed it. If there is one, I would be very interested to hear about
> it, however!
Common Lisp. You have a few portable GUIs to choose, one
commercial/supported.
Oh, sorry, does that destroy your point?
kt
On May 14, 2:06 am, Kenneth Tilton <·········@gmail.com> wrote:
> Series Expansion wrote:
> > Yes, but can you write a GUI app in any dialect of Lisp and port it
> > easily to Windows, MacOS, and Linux, and distribute it as a simple run-
> > this-installer-and-away-you-go form convenient for end-users?
>
> Yes.
With what variant?
> > It's a test that Java, as well as (with some third-party libraries
> > like SDL) C and C++ have passed. I'm not aware of any Lisp that has
> > passed it. If there is one, I would be very interested to hear about
> > it, however!
>
> Common Lisp. You have a few portable GUIs to choose, one
> commercial/supported.
Common Lisp? I recall not long ago doing a search on that. I couldn't
find a single free Windows implementation. I found a single free
implementation TOTAL, Linux-only. Nothing there suggested the use of
their development tools could produce stand-alone deployable
applications, either.
> Oh, sorry, does that destroy your point?
I had no point. I had a question. You have partially answered it. A
URL to a free Windows implementation that produces apps that can be
easily installed on machines without a development kit and can be
ported to MacOS and Linux, and that has GUI capabilities (and other
stuff, such as at least as much ability to access the host filesystem,
network, and similar infrastructure as Java can) would be nice.
Furthermore, such a URL would be smoking-gun evidence to support
*your* point.
On May 14, 2:37 am, Series Expansion <·······@gmail.com> wrote:
> On May 14, 2:06 am, Kenneth Tilton <·········@gmail.com> wrote:
> > Series Expansion wrote:
> > > Yes, but can you write a GUI app in any dialect of Lisp and port it
> > > easily to Windows, MacOS, and Linux, and distribute it as a simple run-
> > > this-installer-and-away-you-go form convenient for end-users?
> > Yes.
> With what variant?
LispWorks,
> > > It's a test that Java, as well as (with some third-party libraries
> > > like SDL) C and C++ have passed. I'm not aware of any Lisp that has
> > > passed it. If there is one, I would be very interested to hear about
> > > it, however!
> > Common Lisp. You have a few portable GUIs to choose, one
> > commercial/supported.
> Common Lisp? I recall not long ago doing a search on that. I couldn't
> find a single free Windows implementation.
You didn't mention the "free" requirement the first time through.
Cheers,
Pillsy
[...]
From: Thomas A. Russ
Subject: More CL bashing. [Was Re: Seeking computer-programming job (Sunnyvale, CA)]
Date:
Message-ID: <ymi7i0jpn5j.fsf_-_@blackcat.isi.edu>
Series Expansion <·······@gmail.com> writes:
> Common Lisp? I recall not long ago doing a search on that. I couldn't
> find a single free Windows implementation. I found a single free
> implementation TOTAL, Linux-only.
I think you need to upgrade your search skills. ;-)
> Nothing there suggested the use of
> their development tools could produce stand-alone deployable
> applications, either.
>
> > Oh, sorry, does that destroy your point?
>
> I had no point. I had a question. You have partially answered it. A
> URL to a free Windows implementation that produces apps that can be
> easily installed on machines without a development kit and can be
> ported to MacOS and Linux, and that has GUI capabilities (and other
> stuff, such as at least as much ability to access the host filesystem,
> network, and similar infrastructure as Java can) would be nice.
Um, I don't see how Java fits the criteria of either:
"stand-alone deployable applications"
or
"Windows implementation that produces apps that can be easily
installed on machines without a development kit"
of have I been somewhat misled by all of the URL links that tell Windows
users how to install Java on their machine, so they can run Java
applications? Either that or the use of some type of installer program
that does all of that behind the scenes. But then you can use a similar
installer for Common Lisp.
BTW, I do know of one IDE that can produce stand-alone deployable Java
applications, but it only works on Macs.
So, you seem to want more from Common Lisp than from Java. Why?
--
Thomas A. Russ, USC/Information Sciences Institute
On May 14, 2:14 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Series Expansion <·······@gmail.com> writes:
> > Common Lisp? I recall not long ago doing a search on that. I couldn't
> > find a single free Windows implementation. I found a single free
> > implementation TOTAL, Linux-only.
>
> I think you need to upgrade your search skills. ;-)
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
> > > Oh, sorry, does that destroy your point?
>
> > I had no point. I had a question. You have partially answered it. A
> > URL to a free Windows implementation that produces apps that can be
> > easily installed on machines without a development kit and can be
> > ported to MacOS and Linux, and that has GUI capabilities (and other
> > stuff, such as at least as much ability to access the host filesystem,
> > network, and similar infrastructure as Java can) would be nice.
>
> Um, I don't see how Java fits the criteria of either:
>
> "stand-alone deployable applications"
The JVM is pretty widely available and supported, besides which there
are some tools to compile Java to native code out there.
> or
>
> "Windows implementation that produces apps that can be easily
> installed on machines without a development kit"
It's easy to deploy Java apps to machines that lack development tools,
using JWS.
> BTW, I do know of one IDE that can produce stand-alone deployable Java
> applications, but it only works on Macs.
Yuck.
> So, you seem to wantmorefrom Common Lisp than from Java.
No, I don't.
In article <····································@q14g2000vbn.googlegroups.com>,
Series Expansion <·······@gmail.com> wrote:
>On May 13, 1:32=A0pm, "eric-and-jane-smith" <·······@nospam.com> wrote:
>> Lew <·····@lewscanon.com> wrote ···················@news.albasani.net:
>>
>> > My context is along the lines of, "Would Lisp be suitable for a
>> > large-scale insurance claim-processing system built by a team of a
>> > dozen programmers of varying experience, maintained over several
>> > years, compared to alternatives like C# or Java?"
>>
>> A typical highly effective use of Common Lisp for that would be that the
>> Lisp programmer would develop and maintain domain specific languages for
>> the various parts of the insurance business...
>
>(yadda, yadda, yadda)
>
>Yes, but can you write a GUI app in any dialect of Lisp and port it
>easily to Windows, MacOS, and Linux, and distribute it as a simple run-
>this-installer-and-away-you-go form convenient for end-users?
>
>This is the test a language or implementation must pass before it will
>see much use outside of academia and unique deployments (like that
>insurance company's internal systems).
Oh, hardly. C and C++ barely pass this (unless you use a third party
library which (a) hardly anyone ever does and (b) could be used from
Common Lisp as well with the appropriate bindings) and there are *plenty*
of programs that are designed to run on one OS or don't have much of
a GUI or, perhaps, have a small amount of OS specific code in one little
area. That assumes that you care about the non-Windows section of the
market, which most people don't.
Lisp may not meet your needs, but the fact that it doesn't does't make
it useful only for a bunch of pencil necked geeks in their ivory towers.
Alan
--
Defendit numerus
Lew <·····@lewscanon.com> wrote in ·················@news.albasani.net:
> I'm not looking at the page, being already familiar with Lisp.
Being familiar with Lisp is not as straightforward as it seems. Synergy of
the different aspects of Common Lisp plays a key role in its power. You
can have a fairly broad overview and still not have the slightest hint of
its real power. You have to have a lot of experience with it before you
get the full benefit of it.
A lot of the mediocre reputation of CL comes from the fact that the people
who evangelize it the most are the ones who are excited about learning it.
They discover new programming concepts, not just new features. They get
all excited and try to explain to the world why it's so great. But they
miss most of its real power, because they're still beginners.
On Wed, 13 May 2009 01:06:13 -0700, ·············@rem.intarweb.org
(Robert Maas, http://tinyurl.com/uh3t) wrote:
>Note that for embedded systems, C used to be the only mainstream
>language available (with Forth being better for some purposes
>although not "mainstream" IMO), but nowadays Java is used a lot in
>embedded systems such as cell-phones. I'm not sure what if anything
>I should say about this topic in Lesson 6.
I used to work in embedded systems. While C is the dominant player,
C++ is increasingly used today. There is a long history of embedded
devices being programmed in Pascal (and variants such as Modula-2). In
many industries, safety critical control systems are developed in Ada.
WRT Java, it is somewhat of an exaggeration to claim that it can be
used for embedded programming. Mostly it is used to develop hosted
user interfacing applications that are run on embedded devices.
Embedded programming, per se, is about direct hardware control and
coordination. With restrictions Java can sometimes be used for higher
level coordination software, but it can't be used for direct device
control nor can it realistically be used for most kinds of time
sensitive coordination software.[*]
[*] There is a so-called "real time Java specification", but to use RT
Java, the programmer must deal with a different concurrency model, and
give up GC and most of the standard libraries ... things which combine
to make time sensitive coding very different and very painful for Java
programmers. RT Java requires a special RT-JVM, which serves to limit
Java to programming mass produced devices for which a manufacturer has
made a RT-JVM available.
George
> From: ·············@gmx.at
> ... I had discussions with several Lisp enthusiast which did not
> show any people skills. The habbit to suppose that everybody, who
> doesn't have the same opinion is an idiot, is not really helpful to
> convince people.
What you describe there is not so much a lack of a people skill but
the presence of a distinctly un-skill. Fortunately I don't have
that un-skill. My approach is to try to find when a person has time
to listen to my idea, then to present my idea and express my belief
that it's a great idea and ask what they think of it. Then I try to
reasonably deal with any problems they see, for example by
proposing a possible solution to the problem. Unfortunately even
the several people who claimed to really like my idea, don't have
any time to spend working with me on developing the idea, and don't
have time to proofread my preliminary idea-specs, etc., so their
liking the idea doesn't turn out to be of any practical use to me.
As for the several pitches I've made in various threads in several
newsgroups, and on Twitter, for my tinyurl.com/NewEco and its
various individual services, not one person has sent me e-mail
expressing interest much less willingness to work with me on
developing the idea. But when I checked my tinyurl.com/Portl1
shortly after I got the connection-logger running, I saw that
connections had come in from several places around the world:
Cablecom GmbH, Zuerich, CH
NTL Infrastructure, Leeds, GB
Milanese, Italy
Hamburg, Germany
Buenos Aires, AR
Oslo, NO
Barnaul, RU
Jazztel, ES
Tampere, FI
as well as various places in the USA:
Northwestern University, Evanston, IL
PaeTec, Fairport, NY / Saffron Technologies, Morrisville, NC
University of New Mexico / CS
Activision, Santa Monica, CA
Google Inc.
Comcast
The hit from Google was obviously an attempt to spider my site,
which isn't possible beyond the first stage of logging portal
because of the Turing test to protect all access beyond that point,
so Google probably didn't get much to put in their index. I haven't
checked back since May.03 to see if any new IP numbers connected
since then, from even more places around the world. Hmm, would it
be perverse to compare the number of countries connecting to my
tinyurl.com/Portl1 to the number of countries with confirmed cases
of Mexican A-H1N1 flu, and notice that as of May.03 they were
approximately the same number although different in details? (For
example, my site had Italy Argentina and Norway, which the flu had
not yet reached, but lacked New Zealand France and most notably
Mexico!)
Hmm, I did a Google search for text in the contents of the PHP
script that was spidered via tinyurl.com/Portl1, and there were no
matches, so why did Google spider it but not yet include it in
their index nearly a week later? Was it deemed not worth including?
Or was the logged connection *not* their spider but actually some
real live person at Google interested in my NewEco portal?
> Discussions are about exchanging opinions and not about forcing
> an opinion to others.
Yes. Unfortuately in RL I have been unable to find anybody with
enough intelligence and presence of mind to understand my ideas yet
enough spare time to seriously discuss them with me.
> By pure coincidence I just bought a book about Lisp a few days
> ago. I had some Lisp knowledge already and wanted more
> information. From what I have seen so far I can tell you:
> I will not turn into a Lisp fan. :-)
Reading a book is just about the worst possible way to become
enlightened as to the value of *totally* interactive development of
computer software made possible by the R-E-P loop together with
identical seantics between typed-in-REP-code an compiled code
(unlike Java, where BeanShell REP is grossly different in semantics
from compiled code).
If and when I get tinyurl.com/NewEco up&running, whereby anyone can
get an account and log in and browse Requests For Bids (RFBs) and
post bids in response and the lowest bidder then works for "pay"
(credit on the system that can't be cashed out at present but can
be used to purchase services from the system or from other
laborers), would you be willing to try your hand at bidding on some
Lisp software contracts (tasks I could do myself but I have far too
much "on my plate" to have time to write *all* the code myself),
little tasks that take a few seconds or up to five minutes, where
you write just a couple lines of Lisp code, or maybe you write one
complete function per spec. Alternately would you be willing to bid
on contracts for writing Seed7 code? Or is Seed7 incapable of
easily being programmed to do most of the data-processing tasks I'd
be wanting done? Or are you collecting $50/hr for Seed7 coding
already so you wouldn't waste your valuable time writing Seed7 code
for anything less than $50/hr?
Here are examples of small tasks I might submit for bids (in Seed7 or whatever):
- Given a large integer, break it into byte-fields per some spec,
such as some fixed-width fields and some UTF-8 variable-length
values. (Inverse of the next task.)
- Given various fields as small integers, express each as
fixed-width or UTF-8 code and append together to make a large
integer. (Inverse of the previous task.)
- Given an associative array containing the decoded HTML FORM contents,
check whether a particular field is present, and if not go down
one branch (stub for the present), else check several specific
possible values for that field and dispatch to appropriate branch
(each stub for present).
- Given the timestamp A3 when a particular "card" was last
finished, and the timestamp B1 when that "card" was scheduled to
be re-started, and the timestamp B2 when that "card" was
actually re-started (sometime after schedule if the system was
busy with something else so it had to be queued for later),
calculate the delta-time from A3 to each of B1 and B2 and
compute the geometric mean ABG of those two delta-times.
- Given the timestamp B3 when the "card" was just now finished
again, and the ABG computed earlier, multiple ABG times a
randomly generated scale factor per a formula I provide, and add
that to B3, to generate the expected time C1 when this "card" is
scheduled to be started *next* time.
- Given a set of "cards", each with scheduled time to be processed
next, all in one table within a MySQL database, determine which
are already (over-)due and which are not yet due, count the due
set, and choose the "card" in the due set that is most overdue.
(2 return values: count, and most-overdue card)
Do you think it would take longer than 5 minutes to write and test
and submit the code for any of those single tasks in Seed7?
This would probably take longer than 5 minutes to code, so I'd need
to break it down into smaller tasks before posting RFBs for each,
or else wait until I have procedures that would support such larger
tasks and a user-base large enough that I'd get more than one bid
for such a large task:
- Given two strings (of text), find the largest matching
sub-string, and from what remains (no overlap allowed)
recursively find the next-largest matching sub-string, providing
that each match is at least two characters long. Return list of
triples showing sub-string and location within each of the two
given strings.
How long do you think it would take to program that in Seed7?
How efficient would it be for moderate-sized strings (appx. 50 to
200 characters in each of the given strings, with matching segments
of all possible lengths, sometimes most of the strings match as one
huge single sub-string, sometimes there are lots of tiny
3-character and 2-character pieces matching but the sequence of
them is scrambled from one input string to the other)?
> From: "eric-and-jane-smith" <·······@nospam.com>
> I'm not saying he does or doesn't have such competence, but just
> that it's unrelated to the real reason why he can't get a job.
According to most of the experts, getting a job depends almost not
at all on what you can do and almost all on whom you know.
Unfortunately I don't know anyone, so all my skills at writing
software go unnoticed. Starting in early 2001 I put up CGI demos so
that people on the net could look at samples of what I can do, thus
become familiar with my abilities to develop working software
applications, but I don't know how to find anyone in the local area
willing to look at my demos and discuss them with me. Several total
strangers I've never met, living thousands of miles from me, have
tried my demos and said they liked them, but they were of no help
in setting me up with local employers. The one local person who was
willing to experience a demo of my very first CGI demo in early
2001, a recruiter at Volt in Mountain View, really liked my demo,
but said his agency recruits *only* for MicroSoft, and they aren't
hiring. When I contacted him again in more recent years, he said
that MicroSoft still wasn't hiring. I haven't yet found even one
person with connections in industry in the local area to let me
show a demo of my more recent and serious CGI applications.
> > > But it is the best language to stay unemployed.
> > Even better than Seed7?
> From: ·············@gmx.at
> Yes, in this regard I consider Lisp as the best language ever.
> At least I have never heard of a person being unemployed
> for more than a dozen years because of Seed7 ...
That's a bogus argument, claiming a brand new language like Seed7
is better because it has a shorter history of unemployment. That's
like claiming that 2-yr-old babies are better software programmers
than I am because they've been unemployed only two years.
Perhaps a better way to calculate this is to go all the way back to
most recent employment, sort of like finding the highest-order bit
of a twos-compliment number. A negative number has an infinite
number of high-order negative bits (extended sign), just like how
Seed7 has an infinitely long extended period of unemployment before
it was invented. But Lisp has *some* employment (17.7 years ago) to
break the long stretch of unemployment, so Lisp is better than
Seed7, having *only* 17.7 years unemployment compared to an
infinite amount of unemployment.
Or we could do a proportional way of calculating merit over the
lifetime of the language. Lisp is 50 years old, and I was earning
money at Lisp for about 10 of those years (and using it for 35 of
those years), so Lisp is 20% good per employment and 70% good per
usefulness, whereas Seed7 is 0% good per employment. (YMMV. Is
there anyone who was using the very first implementation of Lisp
for productive work and has continued to use various versions of
Lisp for the whole 50 years thus getting 100% usefulness out of
it?)
On 13 Mai, 08:07, ·············@rem.intarweb.org (Robert Maas,
http://tinyurl.com/uh3t) wrote:
> > > > But it is the best language to stay unemployed.
> > > Even better than Seed7?
> > From: ·············@gmx.at
> > Yes, in this regard I consider Lisp as the best language ever.
> > At least I have never heard of a person being unemployed
> > for more than a dozen years because of Seed7 ...
>
> That's a bogus argument, ...
The dialog above uses a concept which might be unknown
to you. Look at http://en.wikipedia.org/wiki/Humour
for an explanation of this concept.
[snip paragraph because keyword 'Lisp' was used]
And now for something completely different.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
> > > > > But it is the best language to stay unemployed.
> > > > Even better than Seed7?
> > > Yes, in this regard I consider Lisp as the best language ever.
> > > At least I have never heard of a person being unemployed
> > > for more than a dozen years because of Seed7 ...
> > That's a bogus argument, ...
> From: ·············@gmx.at
> The dialog above uses a concept which might be unknown
> to you. Look at http://en.wikipedia.org/wiki/Humour
> for an explanation of this concept.
Oh no, you're mistaken. I am quite familiar with humor. One of my
favorite TV programs this past season is intensely full of humor.
"The Big Bang Theory"
It was just that after all these months of you hawking Seed7 as
better than Lisp, seriously, not as a joke, it was such a surprise
for you to have given up that and now just make a *joke* about
Seed7 being better than Lisp, not to be taken seriously, that such
an unexpected event completely missed being treated by my mind as a
likely event. Well, then, I'm very pleased you are now treating
Seed7 as a joke rather than a serious programming language.
Note: You have not yet provided an online demo of how Seed7 can be
used as a CGI application, many months after I challenged you to do
so, so at this point I am quite sure either Seed7 isn't a serious
language for such purposes or you are ashamed to show the ugly code
in Seed7 that would be required for such a demo. So maybe it's just
as well that you now accept Seed7 as just a joke.
By the way, what do you think of the Flaming Thunder CGI demo that
was posted sometime last year (or maybe the year before)? Flaming
Thunder succeeds where Seed7 failed.
BTW, if you change your mind again, want to treat Seed7 as serious
again, that CGI-demo challenge remains, so any time you want to
demonstrate that Seed7 can do CGI, feel free to contact me to show
me your demo. Until then, enjoy your humor.
On 13 Mai, 10:22, ·············@rem.intarweb.org (Robert Maas,
http://tinyurl.com/uh3t) wrote:
> > > > > > But it is the best language to stay unemployed.
> > > > > Even better than Seed7?
> > > > Yes, in this regard I consider Lisp as the best language ever.
> > > > At least I have never heard of a person being unemployed
> > > > for more than a dozen years because of Seed7 ...
> > > That's a bogus argument, ...
> > From: ·············@gmx.at
> > The dialog above uses a concept which might be unknown
> > to you. Look athttp://en.wikipedia.org/wiki/Humour
> > for an explanation of this concept.
>
> Oh no, you're mistaken. I am quite familiar with humor. One of my
> favorite TV programs this past season is intensely full of humor.
> "The Big Bang Theory"
> It was just that after all these months of you hawking Seed7 as
> better than Lisp, ...
In most cases I don't see a language superior to another.
Languages are just different and have different purposes.
There are different philosophies behind languages. If you
compare languages this philosophies must be taken into
account. Such a philosopy can be a dynamic or a static
type system. There can be endles flamewars about such
issues but they lead to nowhere. When a language
uses some philosophies as base it is interesting how far
you can go with that. The same words can mean different
things to different people. So unified syntax or user defined
syntax can both have their advantages.
> Note: You have not yet provided an online demo of how Seed7 can be
> used as a CGI application, many months after I challenged you to do
> so, ...
Sorry, but I have many things to do. Wife, children, work,
garden and other hobbies beside Seed7 all take time.
BTW: Persons who accept every challenge are busy with
duels all the time...
When I have time I will add CGI examples to the release
(Note that I didn't mention when it will happen).
> so at this point I am quite sure either Seed7 isn't a serious
> language for such purposes or you are ashamed to show the ugly code
> in Seed7 that would be required for such a demo. So maybe it's just
> as well that you now accept Seed7 as just a joke.
Your people skills should definitely be improved.
You cannot manipulate me this way. I am too much
self-confident for this tactic to work.
> By the way, what do you think of the Flaming Thunder CGI demo that
> was posted sometime last year (or maybe the year before)? Flaming
> Thunder succeeds where Seed7 failed.
At least I succeeded in finding a job last year.
BTW: Several people in this discussion made suggestions
how you could get a job. I noticed that you don't seem to
follow the suggestions. Some of them seem pretty reasonable.
So take my advice: Try to improve your people skills,
concentrate on things searched by companies and follow
the reasonable suggestions given by other people in
this discussion.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
(After claim that Common Lisp is best language for not getting a paying job:)
> From: "eric-and-jane-smith" <·······@nospam.com>
> Even better than Seed7?
AFAIK Seed7 can't be used to write WebServer applications,
rendering it moot in discussions between Common Lisp or Java or C
or C++ etc. all of which can. There is actually one *new* (unknown)
language which has passed the test of 3-steps-past-hello-CGI (full
HTML FORM decoding), namely Flaming Thunder. For all 7 languages
that pass that test, see:
<http://www.rawbw.com/~rem/HelloPlus/hellos.html#step3>
I'd really like somebody to volunteer demos of JSP and ASP to
include there, but so-far nobody with access to either has offered
a demo.
On 13 Mai, 07:52, ·············@rem.intarweb.org (Robert Maas,
http://tinyurl.com/uh3t) wrote:
> (After claim that Common Lisp is best language for not getting a paying job:)
>
> > From: "eric-and-jane-smith" <·······@nospam.com>
> > Even better than Seed7?
>
> AFAIK Seed7 can't be used to write WebServer applications, ...
Well, Seed7 can be used for WebServer applications, but I admit
that the release does not contain CGI examples. I have to polish
my CGI examples a little bit before I release them. Additionally
I need to write documentation how to write CGI programs in Seed7.
I also plan to extend Comanche, the WebServer for static pages,
released with seed7_05_20090510 such that it is capable to
execute CGI programs.
> rendering it moot in discussions between Common Lisp or Java or C
> or C++ etc. all of which can.
I thought this is not a language comparison discussion.
> There is actually one *new* (unknown)
> language which has passed the test of 3-steps-past-hello-CGI (full
> HTML FORM decoding), namely Flaming Thunder. For all 7 languages
> that pass that test, see:
> <http://www.rawbw.com/~rem/HelloPlus/hellos.html#step3>
After looking at your page for 10 seconds I found the following:
There is a switch to bold (with <b>), probably to highlight
a Warning, but it never switches back to normal. Maybe you
should fix that bug.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
> From: ·············@gmx.at
> ... Seed7 can be used for WebServer applications, but I admit
> that the release does not contain CGI examples. I have to polish
> my CGI examples a little bit before I release them.
I'm looking forward to when you do that. But note that the CGI
examples in my helloCGI+steps document are very simple, completely
toy, trivial, just to demonstrate the one principle without mixing
in a bunch of Red Herrings. If you can just translate my demos
directly to Seed7, that would be best.
For more serious CGI examples, showing major things a CGI
application needs in addition to just decoding the HTML FORM
contents, such as validating contents of textfield to be an
integer, or handling cookies, see:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/h4s.html>
After you get the super-basic toy demo of CGI FORM decoding, I hope
you go ahead to also translate those more serious cookbook examples
to Seed7.
> Additionally I need to write documentation how to write CGI
> programs in Seed7.
IMO, once a student knows how to do general D/P software in Seed7
(or any language), all it takes to learn CGI programming is a set
of trivial demos of major aspects (HTML FORM decoding, validating
various kinds of fields from the form, handling cookies, generating
output of HTML either by inline spewing or by DOM, etc.) with very
little additional text needed to explain what each unit of code is
doing. There's a PHP tutorial I like, see tinyurl.com/phptut, which
is one possible amount/style of documentation for how to do various
things. It's divided into just-starting tutorials about each
different *kind* of thing being handled, and corresponding manual
listing *every* function available for such kind of thing being
handled. I'm not saying that's the best way to do such a tutorial,
but it's a good starting point for thinking of how you want to do
it. I seem to recall your Seed7 tutorial is actually somewhat
similar in verbosity/style. Sun's J2SE JavaDoc is another good
example.
If and when I find time to re-do my cookbook/matrix, it'll be
somewhat different, heavily emphasizing the concept of intentional
datatypes, making clear distinction between the intentional
datatype that expresses what you need and the actual datatype that
affects speed of various operations. For example, Lisp uses binary
integers, which make bit/byte-extraction/building fast but decimal
I/O and digit-extracting slow, whereas PHP uses decimal-digit
strings to represent big integers, making bit/byte
extraction/building rather slow but decimal I/O and digit
extraction fast. Same intentional data type (unsigned integer), two
different actual datatypes that make different operations fast. For
another example, a *set* can be implemented as array or linked list
or hash table or self-balancing binary-search tree, each with its
own particular sets of operations that are fast vs. slow. Finally,
there's UTF-8 (usually compact, but variable length) vs.
fixed-length 32-bit UniCodes (takes more space, but is easier to
scan and count length of string etc.).
> > ... see: <http://www.rawbw.com/~rem/HelloPlus/hellos.html#step3>
> After looking at your page for 10 seconds I found the following:
> There is a switch to bold (with <b>), probably to highlight
> a Warning, but it never switches back to normal. Maybe you
> should fix that bug.
Thanks for the heads up. I ran the W3C validator on that WebPage,
and found that (missing 'b' character so I had </> instead of </b>)
as well as two other errors (<br> in wrong place just after </li>
instead of earlier, because the </li> was misplaced). Fixed all
three, so it now validates fine. In all the months since I
previously edited that file and screwed up those three places, you
are the first to find one of them and tell me. If you happen to
notice any other of my active Web pages that fail validation,
please let me know.
Never mind checking the HTML in my PHP scripts for now, because
calls to 'die' don't add the </body></html> that they really
should, so there's no way a PHP script that uses die can pass
validation. And on the free PHP/MySQL hosting sites I'm using, it's
even worse: JavaScript and advertisements are added by the server
in ways that totally break the almost-valid HTML that my PHP script
is generating, for example:
<http://validator.w3.org/check?uri=http%3A%2F%2Fcalrobert.freehost10.com%2Fportal1.php&charset=%28detect+automatically%29&doctype=Inline&group=0>
On May 8, 8:36 am, 1Z <···········@yahoo.com> wrote:
> No, no, no! Stick to LiSP, it is The Best Language.
Actually, LISP is good for impressing potential employers. It's like
Assembly. The unspoken message here is: "I learned thomething that
nobody needth. Imagine how well I might know thingth that people do
need! However, I will not lower mythelf by lithting thothe things"
From: Tamas K Papp
Subject: Re: comparing Java with Lisp (was: Seeking computer-programming job (Sunnyvale, CA))
Date:
Message-ID: <77e87dF1h4ollU1@mid.individual.net>
On Mon, 18 May 2009 22:29:08 +0000, Stefan Ram wrote:
> 1Z <···········@yahoo.com> writes:
>>No, no, no! Stick to LiSP, it is The Best Language.
>
> I like to give adult evening classes on programming that I get paid
> for. I can give Java classes because there is demand for Java classes.
> I cannot give Lisp classes because there is not sufficient demand for
> Lisp classes.
>
> Insofar, in my realm, Java is more useable to me than Lisp.
That's pretty much irrelevant. The usefulness of something does not
depend on whether you can teach evening classes on it. For example, I
am pretty sure that very few of your students would sign up for an
evening class on differential topology. Does that make it useless?
Programming languages are used to program computers. That's the realm
where their usefulness should be judged, not whether students in
evening classes demand them (and let's face it, most of the people in
evening classes are not exactly on the right edge of the Bell curve).
> Because of the wide distribution of Java SE, I can expect the platform
> to be still available and maintained in the future. I cannot expect
> the same for third-party extension libraries. Therefore, I like a
> language with a rich standard library.
Huh? Languages and libraries survive in the long run because they are
useful, not because they are widespread. The graveyards of IT are
full of languages which were extremely widespread at one point.
If I had a penny for every time I hear this "safety in numbers"
argument... well, maybe it would buy me a fancy bar of dark chocolate
:-P
Tamas
On 8 Mai, 17:10, Patricia Shanahan <····@acm.org> wrote:
> Robert Maas,http://tinyurl.com/uh3twrote:
>
> ...> As for jobs I really qualify for, I haven't seen one in more than a
> > dozen years.
>
> ...
>
> If I wanted a job, and was not qualified for any recently advertised
> jobs, I would do the following:
>
> 1. Pick a skill set that is needed both for advertised jobs, and for at
> least one major, well-known, active open source project.
What about the Seed7 project?
There are some open issues:
- Seed7 needs a database interface.
Not a simple one which is just moving SQL strings to the DB.
Something which integrates with the language such that syntax
checks can check for correct SQL syntax and static type checking
can help to find some errors. I think a database interface could
be inspired by some ideas from LINQ/C#.
- Seed7 needs a foreign function interface (to C and maybe to other
languages) which allows easy definition of interfaces and deals
with conversions between char * and the Seed7 string type. Other
type conversions may be necessary as well. The foreign function
interface should also protect against buffer overflows (as much
as possible).
- The Seed7 to C compiler (comp.sd7) needs better support for local
functions which use local variables from outer functions.
Currently comp.sd7 supports this feature in many cases, but when
compiling the P4 Pascal compiler (rewritten in Seed7, currently
not released) comp.sd7 will fail. Since C does not support local
functions the current implementation makes all functions global
and adds additional parameters to emulate the use of local
variables over several levels. It is necessary to check out if
this concept covers all possibilitys and to improve the current
solution or to write a new one instead.
- Support for 64 bit integers is needed and a concept how to work
with integers of different sizes. An interesting part of the
challenge is a hopefully portable solution for C to recognice
integer overflow. This would be needed for the Seed7 to C
compiler.
- I am trying to introduce lambda expression, functions as
parameters as well as variable functions to Seed7 while retaining
static type checks and overloading. See the thread:
"Overloading, lambda expression and functions as parameters."
in "comp.programming". I am in the middle of discussing issues.
A functional programming expert could help to get the design
right.
> 2. Get studying. Study the chosen skill set, and also the open source
> project.
>
> 3. As soon as possible, start contributing to the project. In the early
> stages, use general programming skills to analyze bugs. As I built
> knowledge of the project and the skills, I would expect to be able to
> propose implementations of requested enhancements.
>
> The objective would be to simultaneously build three things: in-demand
> skills, a body of code to which I had made significant contributions
> using those skills, and set of programmers with whom I had good
> cooperative relationships.
>
> 4. Apply for jobs that need the skill set, pointing to the open source
> contributions as evidence of recent experience, and asking other
> participants to act as references.
To Robert Maas:
Patricia suggests that you improve towards the skills searched in
job describtions. This is formulated in a much more friendly way
than I did: "You have to change, the world will not change for you".
She (I hope this is correct) suggests even a way to do this change.
Take her advice, it is a good one.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
·············@gmx.at wrote:
> On 8 Mai, 17:10, Patricia Shanahan <····@acm.org> wrote:
>> Robert Maas,http://tinyurl.com/uh3twrote:
>>
>> ...> As for jobs I really qualify for, I haven't seen one in more than a
>>> dozen years.
>> ...
>>
>> If I wanted a job, and was not qualified for any recently advertised
>> jobs, I would do the following:
>>
>> 1. Pick a skill set that is needed both for advertised jobs, and for at
>> least one major, well-known, active open source project.
>
> What about the Seed7 project?
...
Here are a some questions I would ask. They are nothing to do with
the inherent merit or long term usefulness of the project, just its
potential as a stepping stone to a job:
1. How many people are currently actively contributing to the project?
A large team has several advantages. Being part of a team would help
with demonstrating ability to work in a team. A large team also presents
better networking opportunities, increasing the probability that someone
on the team knows someone who knows someone who knows about a suitable job.
2. How many users does the project currently have? How many discussions
of it in newsgroups or blogs that were not initiated by participants?
A hiring manager is more likely to be impressed by contributions to a
project if the manager uses it, knows someone who uses it, or at least
has heard of it, and can read a variety of opinions about it.
3. What resume buzzwords would work on the project justify? What is the
intersection with buzzwords in advertisements for suitable jobs?
Patricia
On 9 Mai, 01:23, Patricia Shanahan <····@acm.org> wrote:
> ·············@gmx.at wrote:
> > On 8 Mai, 17:10, Patricia Shanahan <····@acm.org> wrote:
> >> Robert Maas,http://tinyurl.com/uh3twrote:
>
> >> ...> As for jobs I really qualify for, I haven't seen one in more than a
> >>> dozen years.
> >> ...
>
> >> If I wanted a job, and was not qualified for any recently advertised
> >> jobs, I would do the following:
>
> >> 1. Pick a skill set that is needed both for advertised jobs, and for at
> >> least one major, well-known, active open source project.
>
> > What about the Seed7 project?
>
> ...
>
> Here are a some questions I would ask. They are nothing to do with
> the inherent merit or long term usefulness of the project, just its
> potential as a stepping stone to a job:
I think it was clear that Seed7 is not the optimal project to get a
job.
> 1. How many people are currently actively contributing to the project?
I have recieved contributions of approximately a dozen persons.
The contributions are currently not at a regular basis.
Believe it or not: I expect that this and other things will change.
Current popular programming languages took 10 or more years to get
popular. I announced Seed7 in october 2005 so there is still much
time.
> A large team has several advantages. Being part of a team would help
> with demonstrating ability to work in a team.
This is a good argument for taking a big project. But without
personal skills it might be hard to be recogniced by senior team
members.
> A large team also presents
> better networking opportunities, increasing the probability that someone
> on the team knows someone who knows someone who knows about a suitable job.
On the other hand: Entering a big project with a large team will not
allow you to easy get a status where each staff manager knows your
name. Mr. Torvalds, Cox, Molnar, ... I have already heard about you.
Just the most prominent team members are known to outsiders (you can
be sure that staff managers are outsiders). E.g.: You probably have
more knowledge than a typical staff manager, but did you know that I
contributed to the Wine project?
Unless you are so prominent that the manager already knows your name
it can IMHO backfire if you put too much emphasis on an open source
participation. Many managers have doubts about open source and/or
are fans of a monopolists proprietory software. The FUD tactics
still work for some managers. I once had a manager questioning my
skills just because I mentioned that Linux could possibly be
better than M$ in some areas. For this manager such an idea was
unimaginable and talking about it was blasphemy. He even came back
several times to show me articles in his manager magazines,
> 2. How many users does the project currently have?
There are between 200 and 600 downloads every month.
> How many discussions
> of it in newsgroups or blogs that were not initiated by participants?
I am busy programming and do not watch blogs. At least there is
reasonable traffic at the Seed7 homepage.
> A hiring manager is more likely to be impressed by contributions to a
> project if the manager uses it, knows someone who uses it, or at least
> has heard of it, and can read a variety of opinions about it.
Well, I already talked about staff managers. Unless you are one of
the most prominent members of one of the most prominent projects it
will not help.
> 3. What resume buzzwords would work on the project justify? What is the
> intersection with buzzwords in advertisements for suitable jobs?
I thought the goal was to aquire skills not buzzwords? :-)
But you are right that a good buzzword list is important for
managers. IMHO buzzwords requested and skills needed to do a job
have almost no relationship. But I admit that buzzwords are
important to get a job.
For a list of Seed7 buzzwords see my signature. :-)
BTW.: Everybody is invited to help the Seed7 project.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
> From: Patricia Shanahan <····@acm.org>
> If I wanted a job, and was not qualified for any recently advertised
> jobs, I would do the following:
> 1. Pick a skill set that is needed both for advertised jobs, and for at
> least one major, well-known, active open source project.
I don't know of any open-source projects using WebSphere and JBoss. Do you?
> 2. Get studying. Study the chosen skill set, and also the open
> source project.
I don't know any way to get access to a computer that is running
WebSphere and JBoss, so my "studying" would be just reading
tutorials without any hands-on practice at what I'm reading.
For me, that's a very ineffective way to learn a software system.
> 3. As soon as possible, start contributing to the project.
I don't know how I could possibly contribute to a WebSphere/JBoss
project without access to any machine that could test the code I
would write. I would not at all be comfortable editing a wiki of
source-code where I have not *ever* tested even one line of code in
WebSphere or JBoss much less the actual made-up code I'm adding to
the wiki. Most likely I'd be banned from the open source project if
I started editing the group-source to have never-tested code,
because it's extremly unlikely that code I just type in without
even a syntax check could possibly be even close to correct.
Robert Maas, http://tinyurl.com/uh3t wrote:
>> From: Patricia Shanahan <····@acm.org>
>> If I wanted a job, and was not qualified for any recently advertised
>> jobs, I would do the following:
>> 1. Pick a skill set that is needed both for advertised jobs, and for at
>> least one major, well-known, active open source project.
>
> I don't know of any open-source projects using WebSphere and JBoss. Do you?
Any open-source Java EE server will work for learning; JBoss is a good one,
and the open-source core of WebSphere is Geronimo. Naturally you wouldn't use
both together.
>> 2. Get studying. Study the chosen skill set, and also the open
>> source project.
>
> I don't know any way to get access to a computer that is running
> WebSphere and JBoss, so my "studying" would be just reading
> tutorials without any hands-on practice at what I'm reading.
> For me, that's a very ineffective way to learn a software system.
If you have a computer, preferably one with at least 2GB RAM by the way, then
all you have to do is download Geronimo, JBoss, and/or GlassFish, follow the
installation instructions, and Bob's your uncle.
>> 3. As soon as possible, start contributing to the project.
>
> I don't know how I could possibly contribute to a WebSphere/JBoss
> project without access to any machine that could test the code I
Do you own a computer?
How much RAM does it have?
> would write. I would not at all be comfortable editing a wiki of
> source-code where I have not *ever* tested even one line of code in
> WebSphere or JBoss much less the actual made-up code I'm adding to
So test what you write.
> the wiki. Most likely I'd be banned from the open source project if
> I started editing the group-source to have never-tested code,
So test your code.
> because it's extremly unlikely that code I just type in without
> even a syntax check could possibly be even close to correct.
So test your code.
I would offer different advice from contributing to JBoss or WebSphere,
though. I'd use them to practice Java EE coding and deployment skills, not to
contribute to the platforms themselves. One would need experience relying on
the platforms before daring to modify them.
Your caution about contributing to projects without actual deployment is well
founded. Your concern that you can't download or run a Java EE web server is not.
<http://geronimo.apache.org/>
<http://www.jboss.org/>
<https://glassfish.dev.java.net/>
--
Lew
> From: Lew <·····@lewscanon.com>
> If you have a computer, preferably one with at least 2GB RAM by
> the way, then all you have to do is download Geronimo, JBoss,
> and/or GlassFish, follow the installation instructions, and Bob's
> your uncle.
My computer has only 8 MB of RAM, and the 160MB hard disk has less
than 9 MB empty at the moment.
> Do you own a computer?
> How much RAM does it have?
See above, or see:
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
> > would write. I would not at all be comfortable editing a wiki of
> > source-code where I have not *ever* tested even one line of code in
> > WebSphere or JBoss much less the actual made-up code I'm adding to
> So test what you write.
How would you propose I do that on my Macintosh Performa with only
8 MB RAM?
> I would offer different advice from contributing to JBoss or WebSphere,
> though. I'd use them to practice Java EE coding and deployment
> skills, not to contribute to the platforms themselves. One would
> need experience relying on the platforms before daring to modify
> them.
My assumption is those help-wanted ads that require 3 years
experience programming in/with JBoss and WebSphere involve *using*
them rather than *implementing/modifying* them per se. But to tell
the truth, since I have never even **seen** either much less used
either in any way whatsoever, it didn't seem important to waste the
hiring manager's time with attempts to learn more about the jobs I
grossly didn't qualify for in the first place.
> Your caution about contributing to projects without actual
> deployment is well founded. Your concern that you can't download
> or run a Java EE web server is n ot.
Neither the public library, nor CONNECT/NOVA in the EDD building,
nor the semi-public lab in my apartment complex, would allow me to
download **anything** whatsoever, never mind something as major as
J2EE. And as I implied above, 8 MB RAM on my own personal Macintosh
isn't enough to even boot up J2EE never mind no disk space to put
it in the first place.
For the time being, I'll stick to PHP/MySQL and CGI/CMUCL where I
can implement my tinyurl.com/NewEco + tinyurl.com/Portl1, where if
it succeeds I'll be as famous as Adam Smith or Thomas Jefferson or
FDR, a lot more famous than Bill Gates or Alan Greenspan or Richard
Stallman. (If Bill and Melinda manage to completely wipe out
HIV/AIDS in Africa, then worldwide, maybe they'll be as famous as
Salk and Sabin, but I seriously doubt they'll succeed that
completely, but it's nice that they're trying.)
From: Lew
>> So test what you write.
Robert Maas, http://tinyurl.com/uh3t wrote:
> How would you propose I do that on my Macintosh Performa with only
> 8 MB RAM?
Upgrade.
You can't learn to be a carpenter using only a toy hammer. You either need
better tools yourself or find someone who has them and is willing to let you
use them to learn.
You can't use excuses like, "My computer only has 8 MB RAM" to avoid learning
your skills, then complain that employers won't hire you because you lack
those skills.
You will make no progress in life until you stop making excuses and start
taking responsibility.
--
Lew
From: Tamas K Papp
Subject: Re: [OT - job seeking] Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <76vvlsF1f3sf3U1@mid.individual.net>
On Wed, 13 May 2009 08:54:11 -0400, Lew wrote:
> From: Lew
>>> So test what you write.
>
> Robert Maas, http://tinyurl.com/uh3t wrote:
>> How would you propose I do that on my Macintosh Performa with only 8 MB
>> RAM?
>
> Upgrade.
>
> You can't learn to be a carpenter using only a toy hammer. You either
> need better tools yourself or find someone who has them and is willing
> to let you use them to learn.
>
> You can't use excuses like, "My computer only has 8 MB RAM" to avoid
> learning your skills, then complain that employers won't hire you
> because you lack those skills.
>
> You will make no progress in life until you stop making excuses and
> start taking responsibility.
I think you misunderstand his intentions. Making excuses and avoiding
responsibility is precisely his purpose.
A while ago he started a similar thread, and not being aware of who he
was I tried to help him with his CV. All I got in reply was verbal
abuse and excuses.
Similarly, one can get a 2-4 year old PC that is perfectly suitable
for programming in Lisp (or whatever language) with a CRT screen for
peanuts. It is just more convenient to keep the old one and complain
about what he cannot do with it. Sad, but you cannot help him.
Tamas
Tamas K Papp <······@gmail.com> writes:
> [...] Similarly, one can get a 2-4 year old PC that is perfectly suitable
> for programming in Lisp (or whatever language) with a CRT screen for
> peanuts. It is just more convenient to keep the old one and complain
> about what he cannot do with it. Sad, but you cannot help him.
I'm tending to the opinion that he is simply a troll - his Mac Performa
obsessiveness sounds way too ridiculous. And for a troll, he is VERY
successful. Xah Lee would be proud of such a thread.
Nicolas
Tamas K Papp wrote:
> I think you misunderstand his intentions. Making excuses and avoiding
> responsibility is precisely his purpose.
Perhaps you misunderstand my intentions. You're certainly entitled to think
what you will about what I understand, but don't be surprised if you miss the
mark.
> A while ago he started a similar thread, and not being aware of who he
> was I tried to help him with his CV. All I got in reply was verbal
> abuse and excuses.
I've been around Usenet a little while. Even had I not seen messages from the
OP before, I would still understand what I was dealing with. This does not
preclude a straightforward response to what was, after all, a perfectly
reasonable request for advice and opinions. I do not expect nor require that
anyone on Usenet accept advice that I've given.
For the record, in this thread at least I see no evidence of "verbal abuse"
from the OP, but I do see judgmental remarks from you, Tamas.
--
Lew
On May 13, 8:54 am, Lew <·····@lewscanon.com> wrote:
> From: Lew
>
> >> So test what you write.
> Robert Maas,http://tinyurl.com/uh3twrote:
> > How would you propose I do that on my Macintosh Performa with only
> > 8 MB RAM?
>
> Upgrade.
Let's see: he needs money to buy a newer computer, a job to get money,
and a newer computer to get a job. Eh. Thorny problem. I'll post again
when I've figured out how he can escape this catch-22.
Series Expansion wrote:
> Let's see: he needs money to buy a newer computer, a job to get money,
> and a newer computer to get a job. Eh. Thorny problem. I'll post again
> when I've figured out how he can escape this catch-22.
You can get a Pentium computer for a couple bucks at a swap meet, and a Ubuntu
CD for free. Boom - a fully modern OS with every programming tool known to humanity.
Oh, then he needs a network connection. Hayes modem?
On May 14, 9:42 am, Phlip <·········@gmail.com> wrote:
> Series Expansion wrote:
> > Let's see: he needs money to buy a newer computer, a job to get money,
> > and a newer computer to get a job. Eh. Thorny problem. I'll post again
> > when I've figured out how he can escape this catch-22.
>
> You can get a Pentium computer for a couple bucks at a swap meet, and a Ubuntu
> CD for free. Boom - a fully modern OS with every programming tool known to humanity.
>
> Oh, then he needs a network connection.
Which costs, and through the nose. A cheap, barely-usable dialup
connection starts at $20/mo. Robert's gonna have to cut out eating
meat and just have bread and potatoes, at least until he lands that
job.
Broadband will cost more than twice that, and to do any sort of client/
server stuff will probably be necessary. Where can Robert get that
much money out of his budget? Broadband, cable/satellite TV, phone
service, and other utilities all tend to cost around $50/mo so he
could try cutting another one of those. Not power, though, he needs it
for the computer. Nor phone service, without which how will he phone
up companies applying for a job? Or arrange interviews, or do a lot of
ordinary tasks for that matter. Looks like Robert has to cut out TV
entirely, or no broadband, or no food.
Robert has a problem.
This is presupposing he can find all this stuff at "a swap meet". I
don't know about you, but where I live you can't just take a stroll
down the street and find computers going for cheap at garage sales or
similar at any random time. Most likely, Robert will need a car to
have the range needed to obtain and transport this thing. (A bus won't
do -- they probably won't let him carry a bulky box of computer and
parts on it -- and bicycling is clearly out of the question.)
Cars cost through the nose to own and operate.
On May 14, 2:43 pm, Series Expansion <·······@gmail.com> wrote:
> On May 14, 9:42 am, Phlip <·········@gmail.com> wrote:
>
> > Series Expansion wrote:
> > > Let's see: he needs money to buy a newer computer, a job to get money,
> > > and a newer computer to get a job. Eh. Thorny problem. I'll post again
> > > when I've figured out how he can escape this catch-22.
>
> > You can get a Pentium computer for a couple bucks at a swap meet, and a Ubuntu
> > CD for free. Boom - a fully modern OS with every programming tool known to humanity.
>
> > Oh, then he needs a network connection.
>
> Which costs, and through the nose. A cheap, barely-usable dialup
> connection starts at $20/mo. Robert's gonna have to cut out eating
> meat and just have bread and potatoes, at least until he lands that
> job.
My local library offers free Internet access. Many local
establishments offer free wifi. Obviously Robert has an Internet
connection or he wouldn't have posted to Usenet. He must have some
money or someone supporting him, or he'd be dead by now.
Many government programs exist to provide training in things like
computer programming. Sometimes friends or relatives will provide the
necessary equipment. I personally know of people who have had pretty
decent computers donated to them by relatives to help them get a leg
up. (By "pretty decent" I mean powerful enough for the needs Robert
has evinced.) I have read about charitable organizations, churches
and the like who have had equipment donated to them that would meet
Robert's needs.
And this is just off the top of my head. I'm sure there are thousands
more viable options at least some of which would let Robert develop
the skills he would need for the jobs he claims he wants. For sure he
hardly needs you arguing in favor of his continued poverty and holding
him back through your negative thinking.
Why are you giving him more excuses? Everything you object to so far
is solvable for free or close to it.
I notice that you ignored the suggestion that he get a job needing
lesser qualifications to pay for essentials and to give him a basis to
enhance his circumstances.
> Robert has a problem.
He said so himself.
> This is presupposing he can find all this stuff at "a swap meet". I
> don't know about you, but where I live you can't just take a stroll
> down the street and find computers going for cheap at garage sales or
I don't know about you, but some people committed to improving their
circumstances actually take action to do so, instead of ranting about
irrelevancies. The point is that lack of computer equipment and an
Internet connection (which latter, again, Robert clearly has), and
concomitant lack of skills, are solvable problems. Provided a person
wants to spend their energy solving them instead of arguing about why
they can't.
--
Lew
On May 14, 3:16 pm, Lew <····@lewscanon.com> wrote:
> On May 14, 2:43 pm, Series Expansion <·······@gmail.com> wrote:
> > On May 14, 9:42 am, Phlip <·········@gmail.com> wrote:
> > > Oh, then he needs a network connection.
>
> > Which costs, and through the nose. A cheap, barely-usable dialup
> > connection starts at $20/mo. Robert's gonna have to cut out eating
> > meat and just have bread and potatoes, at least until he lands that
> > job.
>
> My local library offers free Internet access. Many local
> establishments offer...
All fine and dandy if all you want to do is a little web surfing. But
developing and testing client/server apps and J2EE stuff?
Somehow I doubt it.
Series Expansion wrote:
> On May 14, 3:16 pm, Lew <····@lewscanon.com> wrote:
>> On May 14, 2:43 pm,
Phlip wrote:
>>>> Oh, then he needs a network connection.
Series Expansion wrote:
>>> Which costs, and through the nose. A cheap, barely-usable dialup
>>> connection starts at $20/mo. Robert's gonna have to cut out eating
>>> meat and just have bread and potatoes, at least until he lands that
>>> job.
Lew wrote:
>> Many local establishments offer free wifi.
Series Expansion wrote:
> All fine and dandy if all you want to do is a little web surfing. But
> developing and testing client/server apps and J2EE stuff?
>
> Somehow I doubt it.
Luckily your doubt does not determine reality.
All I'm saying is that Robert could find a way to learn these skills even if
he is rather tight for money. I know poor people who have enough computer to
learn client/server apps and Java EE "stuff", should that be their bent, even
though they receive public assistance and have rather low-paying jobs. It
might not be the fastest connection or the fastest computer, but it's enough
for a determined person to practice the skills to the point where they'd
qualify for a job in the field. Furthermore there are companies that will
train you in computer programming for free, and if you do well in the training
will pay you during your training period, then farm you out to their clients
for a year after you complete the training. Sure, you're paid less than most
programmers, but you get more money than the night shift at your local
convenience store with much less chance of being held up at gun point, and you
come out with programming training and a solid year of experience, and a lot
more income than earned sitting at home blaming everyone but yourself for your
misfortune.
All the nonsense you've been spouting represents hurdles to be sure, but
surmountable ones. You can choose to be one of the whiners if that's what you
want, but no one else should be fooled by your B.S.
--
Lew
On May 14, 10:28 pm, Lew <·····@lewscanon.com> wrote:
> Series Expansion wrote:
> > On May 14, 3:16 pm, Lew <····@lewscanon.com> wrote:
> >> Many local establishments offer free wifi.
> > All fine and dandy if all you want to do is a little web surfing. But
> > developing and testing client/server apps and J2EE stuff?
>
> > Somehow I doubt it.
>
> Luckily your doubt does not determine reality.
Of course not; it merely reflects it.
> All I'm saying is that Robert could find a way to learn these skills even if
> he is rather tight for money. I know poor people who have enough computer to
> learn client/server apps and Java EE "stuff", should that be their bent, even
> though they receive public assistance and have rather low-paying jobs.
The hypothetical case was someone that was almost totally destitute,
with essentially no disposable income remaining after paying for
shelter, food, other basic consumables (e.g. toothpaste), and basic
utilities.
Someone with a bit of additional money above that can save up for a
computer. Someone with at least $50/mo above that can get their own do-
most-things-with-it broadband and not just leech off a web-only
connection in a cyber-cafe or whatever.
On May 14, 2:43 pm, Series Expansion <·······@gmail.com> wrote:
> On May 14, 9:42 am, Phlip <·········@gmail.com> wrote:
>
> > Series Expansion wrote:
> > > Let's see: he needs money to buy a newer computer, a job to get money,
> > > and a newer computer to get a job. Eh. Thorny problem. I'll post again
> > > when I've figured out how he can escape this catch-22.
Get a job (any job) to pay the bills first.
>
> > You can get a Pentium computer for a couple bucks at a swap meet, and a Ubuntu
> > CD for free. Boom - a fully modern OS with every programming tool known to humanity.
>
> > Oh, then he needs a network connection.
>
> Which costs, and through the nose. A cheap, barely-usable dialup
> connection starts at $20/mo. Robert's gonna have to cut out eating
> meat and just have bread and potatoes, at least until he lands that
> job.
>
> Broadband will cost more than twice that, and to do any sort of client/
> server stuff will probably be necessary. Where can Robert get that
> much money out of his budget? Broadband, cable/satellite TV, phone
> service, and other utilities all tend to cost around $50/mo so he
> could try cutting another one of those. Not power, though, he needs it
> for the computer. Nor phone service, without which how will he phone
> up companies applying for a job? Or arrange interviews, or do a lot of
> ordinary tasks for that matter. Looks like Robert has to cut out TV
> entirely, or no broadband, or no food.
>
> Robert has a problem.
>
> This is presupposing he can find all this stuff at "a swap meet". I
> don't know about you, but where I live you can't just take a stroll
> down the street and find computers going for cheap at garage sales or
> similar at any random time. Most likely, Robert will need a car to
> have the range needed to obtain and transport this thing. (A bus won't
> do -- they probably won't let him carry a bulky box of computer and
> parts on it -- and bicycling is clearly out of the question.)
>
> Cars cost through the nose to own and operate.
Anyway, good luck Robert!
Phlip <·········@gmail.com> writes:
> Oh, then he needs a network connection. Hayes modem?
I think it should even be possible to get a laptop with built-in wifi
for free these days..., and if not, get a laptop with pcmcia slot and a
wifi card for $15, and head off to the nearest starbucks...
--
(espen)
Series Expansion wrote:
> Let's see: he needs money to buy a newer computer, a job to get money,
> and a newer computer to get a job. Eh. Thorny problem. I'll post again
> when I've figured out how he can escape this catch-22.
I suggested one way upthread.
Another way is to get a job in an unrelated discipline to make the
money. A good friend of mine who is a talented programmer but didn't
have a college degree during the 2001 downturn drove a forklift in a
warehouse on the night shift for two years while he completed his
degree. Now he has a good job as a programmer and has purchased a
lovely home for his family.
We either have what we want in life or excuses for why we don't.
--
Lew
Lew wrote:
> Series Expansion wrote:
>> Let's see: he needs money to buy a newer computer, a job to get money,
>> and a newer computer to get a job. Eh. Thorny problem. I'll post again
>> when I've figured out how he can escape this catch-22.
>
> I suggested one way upthread.
>
> Another way is to get a job in an unrelated discipline to make the
> money. A good friend of mine who is a talented programmer but didn't
> have a college degree during the 2001 downturn drove a forklift in a
> warehouse on the night shift for two years while he completed his
> degree. Now he has a good job as a programmer and has purchased a
> lovely home for his family.
>
> We either have what we want in life or excuses for why we don't.
There are exceptions to this. See, for example, Randy Pausch. He was an
extreme example of a problem solving non-complainer who did not get what
he wanted in life. However, it does work that way as a general rule.
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."
Patricia
Patricia Shanahan wrote:
> 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
On Sun, 17 May 2009 22:20:53 -0400, Arne Vajhøj wrote:
> 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.
>
Appropriate software can help too - an 866 MHz P3 with 256 MB RAM
wouldn't have a hope in hell of running Windows XP or later, but is OK
running most current Linuxes including the graphical desk top. Admittedly
having 512 Mb RAM is better but isn't necessary for a Linux development
box.
FWIW I have just such a machine that's currently running Fedora 8 at a
perfectly acceptable speed. Its my main development box for C and Java,
which is done alongside a variety of servers (Postfix [mail], Apache [web
server], Postgres [RDBMS] and with ····@Home in the background to soak up
unused cycles).
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
Martin Gregorie wrote:
> On Sun, 17 May 2009 22:20:53 -0400, Arne Vajhøj wrote:
>> 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.
>>
> Appropriate software can help too - an 866 MHz P3 with 256 MB RAM
> wouldn't have a hope in hell of running Windows XP or later, but is OK
> running most current Linuxes including the graphical desk top. Admittedly
> having 512 Mb RAM is better but isn't necessary for a Linux development
> box.
>
> FWIW I have just such a machine that's currently running Fedora 8 at a
> perfectly acceptable speed. Its my main development box for C and Java,
> which is done alongside a variety of servers (Postfix [mail], Apache [web
> server], Postgres [RDBMS] and with ····@Home in the background to soak up
> unused cycles).
According to MS it will !
http://www.microsoft.com/windowsxp/sysreqs/pro.mspx
But yes - Linux offer you better trimming capabilities.
Arne
On Mon, 18 May 2009 21:03:36 -0400, Arne Vajhøj wrote:
> According to MS it will !
>
D'yer believe them? More to the point, would it do anything useful at an
acceptable speed?
Win 95 runs just fine on a K6/266 with 128 MB RAM, but even it gets very
slow if you put an 8 mPixel image into PaintShop Pro on it. Whole image
operations such as resizing or changing contrast and brightness would
take 2-3 minutes to complete.
It would never occur to me to put XP onto that box - its acceptable but
not what you'd call blindingly fast on a normal 1GHz / 1GB office machine.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
Martin Gregorie wrote:
> On Mon, 18 May 2009 21:03:36 -0400, Arne Vajhøj wrote:
>> According to MS it will !
>>
> D'yer believe them? More to the point, would it do anything useful at an
> acceptable speed?
Most likely not.
> Win 95 runs just fine on a K6/266 with 128 MB RAM, but even it gets very
> slow if you put an 8 mPixel image into PaintShop Pro on it. Whole image
> operations such as resizing or changing contrast and brightness would
> take 2-3 minutes to complete.
Win95 should run fine on 32 MB.
> It would never occur to me to put XP onto that box - its acceptable but
> not what you'd call blindingly fast on a normal 1GHz / 1GB office machine.
I used XP on 512 MB for quite some time. Works fine.
Arne
Arne Vajh�j wrote:
> Patricia Shanahan wrote:
>> 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.
More thinking about the code, yes. More thinking about how to prod the
editor into doing xyzzy, not so much.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Patricia Shanahan wrote:
>>> 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.
>
> More thinking about the code, yes. More thinking about how to prod the
> editor into doing xyzzy, not so much.
If someone can not learn to use an editor, then the code would
not be much worth anyway.
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Patricia Shanahan wrote:
>>>> 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.
>>
>> More thinking about the code, yes. More thinking about how to prod the
>> editor into doing xyzzy, not so much.
>
> If someone can not learn to use an editor, then the code would
> not be much worth anyway.
Who said anything about not being able to learn to use an editor?
Certainly not I. In fact I've learned to use several, and having done
so, noticed that some of them get out of my way and let me work on my
code much more readily than others do. I'm sure all of us have made
similar observations.
Seamus MacRae wrote:
> Arne Vajh�j wrote:
>> Seamus MacRae wrote:
>>> Arne Vajh�j wrote:
>>>> Patricia Shanahan wrote:
>>>>> 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.
>>>
>>> More thinking about the code, yes. More thinking about how to prod
>>> the editor into doing xyzzy, not so much.
>>
>> If someone can not learn to use an editor, then the code would
>> not be much worth anyway.
>
> Who said anything about not being able to learn to use an editor?
You.
"More thinking about how to prod the editor into doing xyzzy"
Arne
Arne Vajh�j wrote:
> Seamus MacRae wrote:
>> Arne Vajh�j wrote:
>>> Seamus MacRae wrote:
>>>> Arne Vajh�j wrote:
>>>>> Patricia Shanahan wrote:
>>>>>> 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.
>>>>
>>>> More thinking about the code, yes. More thinking about how to prod
>>>> the editor into doing xyzzy, not so much.
>>>
>>> If someone can not learn to use an editor, then the code would
>>> not be much worth anyway.
>>
>> Who said anything about not being able to learn to use an editor?
>
> You.
I did not, until I quoted and replied to a remark on that topic by you.
> "More thinking about how to prod the editor into doing xyzzy"
This has nothing to do with any supposed inability to learn to use an
editor, only the limited capacity for memorizing trivia that most human
brains have, along with the complexity of the particular editor in
question and the deficiencies of its help and user-interface.
It is a vast and unsupported leap from "a user finds a particular
editor's interface cumbersome" to "that user is incapable of learning to
use any editors at all".
Please be more careful next time, lest you take another tumble from a
high place. Instead, you leap to the attack without looking before you
leap, and look where it gets you.
If you want a further argument, I have a reductio ad absurdum one for
you: if your logic were sound, it would necessarily follow by the same
kind of reasoning that anyone who found any piece of software whatsoever
difficult to use, and in particular had to sometimes think about how to
make it do a particular task, was incapable of learning to use software.
Yet this conclusion is clearly unreasonable. Obviously, there is
software that you would find cumbersome to use, perhaps due to its
interface or simply its complexity. CAD software, perhaps, or specialist
financial tools. Yet you clearly are capable of using some software.
Your ability to use a newsreader is evident, though unfortunate given
your apparent inability to think of anything to post that makes the
world a better rather than a worse place.
The overall structure of the argument you have made is particularly rotten:
* Seamus has trouble using a particular editor's interface; the editor
in question has a primitive, pre-1990s one.
* Therefore Seamus is incapable of using any text editor.
* Therefore (implied) Seamus is an idiot.
* (established elsewhere) Seamus advocated in favor of Java over Lisp.
* Therefore (the topic of the debate) Lisp is better than Java.
The first statement is true. The second is false, as evidenced by my
composing this post in the one built into Thunderbird, and indeed it
does not follow from the first for the reasons previously outlined. The
third statement is false and furthermore it fails to follow from the
second -- a blind mute quadriplegic would be incapable of using an
editor regardless of his IQ. The fourth statement is true and
independent of the first three; it's the second, and an implied, premise
in your argument. And finally, the statement about Lisp does not follow
from statements three and four, because the syllogism formed by the
final three statements is a fallacious argumentum ad hominem argument
rather than a rational one.
Series Expansion <·······@gmail.com> writes:
> Let's see: he needs money to buy a newer computer, a job to get money,
> and a newer computer to get a job. Eh. Thorny problem. I'll post again
> when I've figured out how he can escape this catch-22.
Oh come on! You don't have to *buy* a computer that has at least 50x the
specs of the one he's got. He's living in Silicon Valley, not on the
Bouvet Island!
--
(espen)
·············@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
writes:
> How would you propose I do that on my Macintosh Performa with only
> 8 MB RAM?
Good grief. Go to the nearest trash dump and pick up something from this
millenium!
--
(espen)
On May 8, 8:10 am, Patricia Shanahan <····@acm.org> wrote:
> Robert Maas,http://tinyurl.com/uh3twrote:
>
> ...> As for jobs I really qualify for, I haven't seen one in more than a
> > dozen years.
>
> ...
>
> If I wanted a job, and was not qualified for any recently advertised
> jobs, I would do the following:
>
> 1. Pick a skill set that is needed both for advertised jobs, and for at
> least one major, well-known, active open source project.
>
> 2. Get studying. Study the chosen skill set, and also the open source
> project.
>
> 3. As soon as possible, start contributing to the project. In the early
> stages, use general programming skills to analyze bugs. As I built
> knowledge of the project and the skills, I would expect to be able to
> propose implementations of requested enhancements.
>
> The objective would be to simultaneously build three things: in-demand
> skills, a body of code to which I had made significant contributions
> using those skills, and set of programmers with whom I had good
> cooperative relationships.
>
> 4. Apply for jobs that need the skill set, pointing to the open source
> contributions as evidence of recent experience, and asking other
> participants to act as references.
I think this is an excellent plan.
Since you claim to have good math skills and some AI experience, I
will offer a specific suggestion. Data mining is a booming area right
now, and there are open-source data mining packages. Contributing
significantly to one of these, and being familiar with its use, would,
I would expect, get you a far better job than you could ever get doing
ordinary programming.
-- Scott
From: George Peter Staplin
>> There is such an online auction site, or at least was. It was
>> overrun by people that didn't know what they were doing, and the
>> quality was often questionable from what I've heard of the work.
>> Perhaps things have changed by now.
Robert Maas, http://tinyurl.com/uh3t wrote:
> Can you please try to find it and show me where to find it?
GIYF.
> But such skills as needed to hussle [sic] a job under the current system
> are irrelevant to many kinds of work, such as computer programming.
> It really sucks that good skilled people with lots of other skills
> are neglected for employment because they don't have that one
> specific skill job-hustling and none of the employment agencies are
> willing to do their supposed job.
Wow. I'm not sure exactly what you're saying here, but I read it as a
complaint that you have to hustle in order to find work. I got news for you -
lots of people have good computer skills; it's the hustle that distinguishes
them and makes them better than other candidates. If I were a hiring manager
hearing your pitch, which sounds awfully petulant, I'd look for another candidate.
> A few days ago, on recommendation from someody who claimed DICE was
> good, I tried a job search through DICE. I found only a very few
> jobs at all in my category and nearby, with only one that I
> qualified for per the requirements section, which said *nothing*
> except that I needed 4 years experience software programming,
Do you have such experience?
> nothing specific at all, although the job duties section was full
> of stuff I had not the slightest idea how to do them, but just to
If you don't have the slightest idea how to do them, there's a high likelihood
you are not qualified for that particular position. And saying that it had a
"job duties section ... full of stuff" is the exact opposite of that it "said
*nothing*".
> harass them for posting such a stupid ad I applied anyway. I also
That you confess readily that you wanted to harass them, and condemn their ad
as "stupid" is evidence that you have what any hiring manager would consider a
bad attitude and make them very unwilling to hire you.
> applied at a company that is two blocks from where I live despite
> the fact it requires a security clearance plus lots of experience
> with military specs etc., only because they are so very very
> conveniently located that I've been wanting to get my resume to
> them just in case they have some job not requiring security
> clearance, and this was my first chance, a shot in the dark.
You get a job by demonstrating that you have what they want, not by hoping
that they have what you want.
> As for jobs I really qualify for, I haven't seen one in more than a
> dozen years.
"Would you like fries with that?"
> I neither, but when I'm willing to work at the legal minimum wage
> but the company says i'm [sic] too expensive so they'll hire the
> foreigner instead to save money, it totally pisses me off, either
> that they are breaking the law, or they are simply not listening to
> me that I'm really highly skilled but after 17+ years unemployment
> I'm desperate to find a job even if I have to work at minimum wage
> to "get my foot (back) in the door".
Anyone who's been unemployed for 17 or more years has a perception problem
they will need to overcome, as most hiring managers will be very, very
skeptical of someone with such a gap. They will want to know why a person has
been unemployed - have they been ill, a homemaker, independently wealthy?
That kind of thing. They'll want to see what a person has done recently to
make themselves more attractive to prospective employers - have they gone to
school, done research, taken an internship, worked in a volunteer capacity?
Someone without appropriate answers to these kinds of questions, who complains
bitterly, even if accurately, about why it's other people's fault, who readily
admits to "harassing" prospective employers, who simply states that they're
"really highly skilled" but has no verifiable skills relevant to the employer,
who asserts that they're "desperate to find a job" but also says that they're
unwilling to hustle - that person will almost certainly not get hired. There
are too many people with verifiable skills, a solid work history, and a
demonstrably positive attitude with hustle who are competing for those positions.
Time for some tough love, Robert. Project a positive attitude, even if you
have to fake it. Take courses; get certified. Develop the skill set you see
advertised in the help wanted. Don't ever let them hear you complain about
"foreigners" or whining about the circumstances. Develop hustle.
I know that I repeated some things that Patricia Shanahan said. You should
listen to her. And get a better attitude.
--
Lew
Lew wrote:
> Someone without appropriate answers to these kinds of questions, who
> complains bitterly, even if accurately, about why it's other people's
> fault, who readily admits to "harassing" prospective employers, who
> simply states that they're "really highly skilled" but has no verifiable
> skills relevant to the employer, who asserts that they're "desperate to
> find a job" but also says that they're unwilling to hustle - that person
> will almost certainly not get hired. There are too many people with
> verifiable skills, a solid work history, and a demonstrably positive
> attitude with hustle who are competing for those positions.
We need to respond to clinical depression as a health problem, not a job
problem. These newsgroups have seen these threads before, for many years, with
the same recommendations...
(BTW the secret words here are "Rails" and "Craigslist". They apparently have
higher numbers than the corporate systems and sites. Go figure!)
--
Phlip
On Sat, 09 May 2009 00:13:25 -0400, Lew wrote:
>> As for jobs I really qualify for, I haven't seen one in more than a
>> dozen years.
>
> "Would you like fries with that?"
While working in a fast food chain is considered the ultimate bottom
on the job ladder (hence the term "McJob"), even that sector requires
some skills: serving customers the whole day at least demands the
right attitude, you need to be polite, etc. Judging the OP's attitude
from his posts, no fast food chain would employ him, or even if one
did, he would find himself on the street in a week with a valedictory
box of chicken nuggets.
Tamas
·············@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
writes:
>
> But such skills as needed to hussle a job under the current system
> are irrelevant to many kinds of work, such as computer programming.
> It really sucks that good skilled people with lots of other skills
> are neglected for employment because they don't have that one
> specific skill job-hustling and none of the employment agencies are
> willing to do their supposed job.
>
A lot depends on what you define as job-huslling, but good peple skills
and communication skills are still important even for programmers. While
much of the work you do as a programmer involves sitting at a terminal
cutting code, this is only part of the job.
The days of a programmer being given a task and then they just go off to
wherever they do their work, code like mad and then deliver the finished
solution are gone (actually, I'm not even sure they ever really
existed). These days, programmers need to have good communications and
people skills to extract the true requirements of the software from the
client and to work well with others on the team. In fact, to some extent
this has become an even more difficult task as the general level of
computer literacy has increased. Now, more often than not, in addition
to system requirements, you also get clients telling you how to program
the solution. often the requirements are difficult to identify because
they have presented you with what they think is the solution rather than
describing what they want. You need good peple skills so that you can
extract the real requirements from what the client gives you - you can't
just accept what they tell you, implement exactly that and then expect
they will be satisfied with the result. You need to make them feel
comfortable enough that you can discuss the problem they want to solve,
feel free to ask questions and be able to extract what you need without
making them feel uncomfortable, threatened or concerned that perhaps
your not terribly sane or don't understand the problem. It is only
through good inter-personal skills that you can extract the information
you need to gain sufficient understandinig of the problem to come up
with a good solution. (there are some exceptions of course - writing
your own software to solve a problem you already know and understand and
then hoping to sell the solution to other for example).
Good communications skills are also required because fewer and fewer
programming jobs represent just a single developer working in
isolation. More often than not, there will be a team - possibly a small
team of only a couple of people or maybe a large team of 30 or more. To
actively participate in the team, you need to be able to communicate
with them and you need the people skills necessary to fit into the
team.
having been responsible for employiing staff, both for small companies
and larger beurocracies, two things jump to my mind when I see an
application from someone who hasn't worked for a long time (BTW, 17
years of unemployment is an excessively long time - not sure I've ever
heard of anyone not having any employment for 17 years who wasn't in
prison or in a coma!). The first thing I'd want to know is why they
haven't had a job for 17 years. If there answer involved a lot of what
sounded like excuses or blaming the system or something akin to a victim
attitude, I'd probably write them off. Anyone who hasn't been able to
adapt to changing circumstances and an evolving world and stil comes up
with nothing but excuses or considers themselves a victim of situation
and takes no responsibility for their part in their situation is
unlikely to have the problem solving and outcomes oriented focus I would
be looking for in an employee.
The second thing I'd possibly want to know is what they had been doing
over that 17 years and what they had done to try and get a job (assuming
they wanted one over that whole period). The problem I would have with
employiing anyone who had been unemployed for 17 years is with the fact
that if they couldn't solve their unemployment problem for that length
of time, can I have any confidence they will be able to solve any of the
problems they are likely to run into while working for me. At the end of
the day, you have to weigh this person up with all the other applicants
you have that have recent employment, possibly recent track records of
work completed, recent education or even just youthful
enthusiasm. sometimes, peple will have very good reasons for not having
worked for 17 tears (such as prison or a coma). For this type of
situation, I think your better off being honest and stating why you have
been unable to work for so long. Yes, it may cost you a job, but it may
also get you one. Not everyone will automatically right someone off
because they have a criminal record or a history of mental illness or
whatever. Yes, there are small minded bigoted people who will just write
you off, but they would have written you off already just because you
haven't worked for 17 years. There are some out there who are honestly
prepared to give people a second chance. There are also a growing number
of people out there who have either suffered some significant physical
or mental illness who can have a better understanding and greater
acceptance of such things. Whatever the case, I suspect you are more
likely to find someone who is willing to give you a chance once they
understand why you haven't worked for a long time and that there is a
good reason for it. Complaining that you couldn't get a job because of
low paid overseas competition, lack of money to access and stay current
with modern technology or because the current hiring practices are too
myopic to see your potential are not valid reasons, only excuses.
Is any of this fair - no, probably not. However, it never has been and
never will be a fair world. Good people get screwed over all the time
and bastards are often very successful. What is important to
realise is that the individual plays a significant role in determining
what their situation is. Very few are simply passive victims. It is how
you handle the situation you find yourself in that matters more than the
causes of what put you there.
While it is positive to see someone wanting to get something happening
by starting their own projects and lookinig for others to help, I do
have to wonder why not just join an existing project. Establishing a new
project, particularly one with multiple contributors, is a difficult and
time consuming process. It is also one that usually requires someone
with strong peple skills and a certain level of charisma and ability to
inspire others to be a success. You will be able to get far more mileage
out of working and contributing to an existing recognised project in a
much shorter time than you will with starting your own project. In
particular, a reasonably well know project with a good profile can be
worth a lot. In addition to being able to point to something you have
done which can easily be verified, you are also likely to make
connections with people who would be willing to provide references or
act as referees for jobs you apply for.
For the record, I do believe the way job interviews are handled and the
way applications are processed is fundamentally flawed. My personal
preference for assessing someone for a job is to give them a simple task
that will take about a week to complete and assess how they deal with it
and what they come up with. This lets me see how well they fit in with
the rest of the staff, how well they handle obstacles and whether they
actually can deliver the goods. It may cost a weeks wages to find this
out, but generally, it works a hell of a lot better than making largely
arbitrary assessments based on an interview where all you can tell is
whether the person is a good interviewer or not. Unfortunately, too many
employers are worried about doing tis in case they get problems with
litigators, unions or government beurocracy concerning hiring and
firing - though this varies a lot from country to country.
Tim
--
tcross (at) rapttech dot com dot au
> > But such skills as needed to hussle a job under the current system
> > are irrelevant to many kinds of work, such as computer programming.
> > It really sucks that good skilled people with lots of other skills
> > are neglected for employment because they don't have that one
> > specific skill job-hustling and none of the employment agencies are
> > willing to do their supposed job.
> From: Tim X <····@nospam.dev.null>
> A lot depends on what you define as job-huslling, but good peple [sic]
> skills and communication skills are still important even for
> programmers.
Agreed for some kinds of "people skills", but hustling to convince
total strangers to put out money to take a chance on hiring me
isn't at all the type of "people skills" needed by a software
programmer to interact with supervisor and co-designers. Lumping
the two grossly different kinds of skill-sets into a single label
"people skills", and thereby attempting to equate the two, does a
disservice to this discussion.
> While much of the work you do as a programmer involves sitting at
> a terminal cutting code, this is only part of the job.
Agreed. There's listening to the supervisor to learn what kind of
task must be automated, and brainstorming with that supervisor and
possibly other software designers to work out what's possible and
feasible and what needs changing to become feasible and what's most
cost effective in a general sense of being truly worth the effort,
and reporting partial work to the supervisor, and occasionally
engaging in debates as to the best way to accomplish a task. But
all of this is in a context of the software programmer *already*
being on the payroll, so there's incentive for everyone to
cooperate. Furthermore the various people already somewhat know
each other and have some existing trust between them. By
comparison, job hustling requires converting a hostile stranger
into making a major investment to put the new person on the
payroll, which involves a lot of cost even before the first
paycheck, and then locks the employer into a longterm situation
until and unless the employer can find a really good reason to fire
the new employee. True the new employer is usually on a
probationary period of three to six months during which firing is
easier than it would be later, but still it's a lot easier to just
not hire somebody in the first place than fire after hiring.
Convincing a stranger to take such a big risk on my behalf,
convincing that stranger that somehow the cost will reap greater
rewards, is far beyond the normal job duties of a software
programmer. It's ridiculous to say that somebody who doesn't have
advanced skills to hustle a new job during the worst recession in
70 years is consequently incapable of the "people skills" involved
in software programming work.
> The days of a programmer being given a task and then they just go
> off to wherever they do their work, code like mad and then deliver
> the finished solution are gone (actually, I'm not even sure they
> ever really existed).
At this point you're beating a dead horse, or straw man, reader's choice.
> These days, programmers need to have good communications and
> people skills to extract the true requirements of the software from
> the client and to work well with others on the team.
I believe I could do all of that. During my prior work, I never was
allowed to talk directly with the actual customer, who was any of
several high school students who would be participating in our
experimental computerized course in college-level Calculus as soon
as we finished getting our software finished. I discussed
requirements only with my supervisor (on a regular basis) and with
a couple other top management people (occasionally). In terms of
requirements, it was these management people, not the actual
high-school student user, who needed to be accomodated. However
more recently I have become familiar with "use cases" and related
matters of true-customer requirements-determination, and I am
enthusiastically favoring such methodology and believe I could do
it quite well, if only some customer ever wanted me to write
software for him/her.
> In fact, to some extent this has become an even more difficult
> task as the general level of computer literacy has increased. Now,
> more often than not, in addition to system requirements, you also
> get clients telling you how to program the solution.
I clearly understand the difference between user requirements
(including both functionality and timing) and methods to accomplish
such requirements. I believe I could tease out what the customer
really needs, and why he/she feels some particular method would be
needed, and propose *other* methods which I feel would be better if
I can see a significant difference where the customer was in fact
mistaken, and hopefully I can either convince the customer to allow
me to implement *his/her* true needs using *my* judged best
methods, or otherwise just yield to the customer, with full
disclosure that in my opinion the customer's decision was a mistake
but the customer is paying for my labor and can order anything
possible.
> often the requirements are difficult to identify because they
> have presented you with what they think is the solution rather than
> describing what they want.
IMO breaking down the system into "use cases" should go far in
resolving this kind of communication problem. I'll either ask the
customer which use cases ar required, or I'll guess what the
customer wants and propose my own set of use cases and allow the
customer to amend my guess, or a combination of the two approaches.
If the customer doesn't even understand the concept, I can re-word
my "guesses" as direct questions, such as "do you want this
software to allow a user to log into the system?" etc., and after a
series of YES answers I ask "is there anything else the system must
allow the user to do", and hopefully the user will finally either
agree my use cases are complete or say something I overlooked.
By the way, my current estimate of time needed is one use case per
half day (if programming in Common Lisp) or per full day (if
programming in Java or PHP), plus additional time for any totally
new algorithms that I need to craft from scratch. If the customer
agrees with me that six use cases are needed for a minimal (no
"bells and whistles") operational system, and I can get a prototype
system up and running in three days (using Common Lisp) for the
customer to play with to get a feel for both user interface and
"what's missing here", I expect the customer to be reasonably
satisfied.
> You need good peple skills so that you can extract the real
> requirements from what the client gives you - you can't just accept
> what they tell you, implement exactly that and then expect they
> will be satisfied with the result.
Agreed. I think my discussion just above covers that.
> You need to make them feel comfortable enough that you can
> discuss the problem they want to solve, feel free to ask questions
> and be able to extract what you need without making them feel
> uncomfortable, threatened or concerned that perhaps your not
> terribly sane or don't understand the problem.
Whether the customer feels "comfortable" or not is partly a
psychological matter. Perhaps you would be willing to play customer
with me, making up a ficticious task you'd pretend-like to have
implemented, and we can then discuss use-cases and you tell
everyone whether you felt comfortable or not brainstorming the use
cases with me? If for any reason you don't feel comfortable, we can
discuss the psychological problems, and somebody can recommend
improvement. But if you *do* feel comfortable brainstorming with
me, then you can withdraw your apparent objection to this aspect of
my "people skills".
(snipped excessive verbage and rehashing)
> Good communications skills are also required because fewer and
> fewer programming jobs represent just a single developer working in
> isolation. More often than not, there will be a team - possibly a
> small team of only a couple of people or maybe a large team of 30
> or more. To actively participate in the team, you need to be able
> to communicate with them and you need the people skills necessary
> to fit into the team.
My previous major job, that computer-Calculus course, had appx. ten
people on the project, so I think this issue is resolved already.
> The first thing I'd want to know is why they haven't had a job
> for 17 years.
Because during the first three years i was unemployed, nobody was
hiring, so the agencies wouldn't even *try* to match me with a job.
After the first three years, everyone had the ready excuse that I
had no recent employment, and that excuse has continued for an
additional 14 years.
Also because I don't know anybody. Getting hired is more a matter
of who you know than what skills and experience you have. If you
don't know anyone, all the skills and experience in the world are
of nearly zero help in getting hired. Recently I tried several
"networking" groups, including CSix, LinkedIn, etc., but so-far
none of them have resulted in even one person willing to get
connected to me for purpose of "networking".
> The second thing I'd possibly want to know is what they had been
> doing over that 17 years
A whole bunch of stuff. For the first several years I was spending
full time doing classical job search (writing and re-writing my
resume, scanning job ads, answering some job ads, contacting
employment agencies asking for their help) to the point where I got
emotionally burned out. During that time I kept careful records of
all my efforts, which now total 9.3 megabytes. Any time you want to
come over and look at it all and admit I ****really**** made an
effort to find employment, contact me for an appointment. Even
better, perhaps you could analyze what I did right and wrong, and
give me "strokes" for what I did right, and offer suggestions for
improvements of what I did wrong. Maybe after looking at all my 9.3
megabytes of SeekJob effort you can write a succinct explanation of
why none of that immense labor resulted in getting any employment
except for 60 hours of contract work I got in 1992.
I've also done lots of software work on my own, both traditional
software (programs/applications) and Web pages to organize and
present information. Highlights include my sort/merge utility and
use of it for file maintainance, my flashcard-drill application,
the "MaasInfo" indexes, and various CGI and PHP applications. For
more details from 1995 onward, see <http://tinyurl.com/352wo4>,
but for the very most recent activities see <http://twitter.com/CalRobert>
> and what they had done to try and get a job
You can see those 9.3 megabytes of detailed notes any time you want.
> The problem I would have with employiing anyone who had been
> unemployed for 17 years is with the fact that if they couldn't
> solve their unemployment problem for that length of time, can I
> have any confidence they will be able to solve any of the problems
> they are likely to run into while working for me.
Those are completely unrelated skill sets needed to solve those
very different kinds of problems.
(snipped strawman discussion of people in prison)
> Whatever the case, I suspect you are more likely to find someone
> who is willing to give you a chance once they understand why you
> haven't worked for a long time and that there is a good reason for
> it.
I have yet to find even one person who is willing to read those 9.3
megabytes of SeekJob notes to try to understand why none of that
immense effort (plus years of accomplishments on my own as noted
above) have failed to materialize into a paying job. Perhaps you
will volunteer to be the first.
> Good people get screwed over all the time and bastards are often
> very successful. What is important to realise is that the
> individual plays a significant role in determining what their
> situation is. Very few are simply passive victims.
I haven't been passive at all. See those 9.3 megabytes of direct
SeekJob efforts, and see those many many accomplishments on my own,
and tell me what at all I've ever done wrong. I'm willing to learn,
if you teach me, but so-far I haven't been able to find anyone
willing to network with me or give me one-on-one diagnosis of my
past efforts and suggestions for changes in the future.
> It is how you handle the situation you find yourself in that
> matters more than the causes of what put you there.
Read the 9.3 megabytes and tell me if I mis-handled anything whatsoever.
> While it is positive to see someone wanting to get something
> happening by starting their own projects and lookinig for others to
> help, I do have to wonder why not just join an existing project.
I'm not aware of any other existing project of this type, anything
that will provide employment for *everyone*, allowing *anyone* to
become an employer despite not having money to begin with, thus
escaping from those who already have money dictating employment for
the rest of us. If you know of any such project, I'd be glad to
learn about it.
> Establishing a new project, particularly one with multiple
> contributors, is a difficult and time consuming process.
Less time-consuming than trying to do a ten man-years of work all
by *myself* fast enough to make the recession moot.
> You will be able to get far more mileage out of working and
> contributing to an existing recognised project in a much shorter
> time than you will with starting your own project.
You're repeating yourself there. Please suggest a suitable project
I might join.
> For the record, I do believe the way job interviews are handled
> and the way applications are processed is fundamentally flawed. My
> personal preference for assessing someone for a job is to give them
> a simple task that will take about a week to complete and assess
> how they deal with it and what they come up with.
I'm game. Please suggest such a project I could do for *you* during
the next week, some Web application. If it's just programming, I'll
do it in Lisp, while if it requires use of a relational database
I'll use PHP. But except for the URL you use to get it
(something.cgi or something.php respectively), you won't be able to
easily tell the difference.
> This lets me see how well they fit in with the rest of the staff,
I don't see how accomplishig such a task shows anything to do with
fitting in with other staff. Please explain the connection.
> how well they handle obstacles
That'll be covered in the preliminary discussion of use cases.
Before I start coding, I'll know the task is doable within
approximately that one week of time allowed.
> and whether they actually can deliver the goods.
Yes. Let me prove it.
> It may cost a weeks wages to find this out,
It won't cost you anything, except "pie in your face" if you claim
at the outset I'll fail but in fact I prove you wrong. Are you
willing to take that risk?
> ... arbitrary assessments based on an interview where all you can
> tell is whether the person is a good interviewer or not.
Sometimes a good interviewer will ask a question about how to solve
some problem, basically asking for an informal algorithm to be
invented (or remembered/adapted) on the fly. For example, when I
interviewed for RSA Data Security, the interviewer asked me how I
achieved efficient modular exponentiation, and I described my
algorithm, and he agreed it was efficient but said his company used
a more efficient algorithm, and he described his proprietary
algorithm, and it seemed to indeed be more efficient in some
special cases but not essentially more efficient than what I
already devised appx. fifteen years previously. i fully expected to
be hired, but they never called me back even for a second
interview, and I have no idea why, because AFAIK I was fully
qualified for the job and in fact more than qualified, and they
never even had the decency to tell me why they didn't hire me.
- Good interviewer. Stupid hiring manager. -
> Unfortunately, too many employers are worried about doing tis in
> case they get problems with litigators, unions or government
> beurocracy concerning hiring and firing - though this varies a lot
> from country to country.
If you negotiate with me to assign a reasonable one-week project
for me to demonstrate my abilities, and I accept the task, I won't
later sue you for some aspect of the task you assigned me, OK?
Stop being so paranoid!
Robert Maas, http://tinyurl.com/uh3t wrote:
> Agreed for some kinds of "people skills", but hustling to convince
> total strangers to put out money to take a chance on hiring me
> isn't at all the type of "people skills" needed by a software
> programmer to interact with supervisor and co-designers.
Au contraire. When a boss thinks of a feature, they need to ask for an estimate
of the programmer hours required to implement it. If each little planning
session has the same meanings as a hiring interview, then maybe a good way to
face the interview is like a big planning session...
On 11 Apr., 23:57, ·············@rem.intarweb.org (Robert Maas,
http://tinyurl.com/uh3t) wrote:
> > From: Kaz Kylheku <········@gmail.com>
> > But income without a regular job generally requires better people
> > skills than job income.
>
> Perhaps under the current economic system.
-- Begin off topic --
Don't expect some unrealisic change of the economic system. The
evolution will not allow that kapitalism (For europeans: free market
economy) to be replaced by something weaker. Survival of the fittest
will not allow a weaker replacement (at least not permanently,
see Russia).
-- End off topic --
> On the other hand what
> if there were an online auction site for bidding on short-term
> contracts, where all you need to do is
> (1) make the lowest bid on the contract
> (2) complete the contract before the deadline
> and you get paid automatically? No need to talk your way into the
> contract. Just bid-then-perform. That's it. No people skills
> needed?
Forget it, the world will not change just because some people have
no people skills. It might sound harsh, but you have to change. The
world will not change just to fit to you. Take my advice: Try to
adopt to the needs (people skills and other things) and try to be
successful in the current world/economic system. Even it many things
in our world are wrong by far. With reasonable success in the
current system you are capable to do some changes (make the world
a better place). This is at least my aproach. In companies I write
C++ programs under Windows. This enables my to help changing the
world into a place were people write Seed7 programs under Linux. :-)
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
> From: ·············@gmx.at
> Don't expect some unrealisic change of the economic system.
You're mistaken on two counts. I'm making an effort *myself* (and
soliciting collabators to share the workload) to make a *realistic*
change.
> The evolution will not allow that kapitalism (For europeans: free
> market economy) to be replaced by something weaker.
I have no intention of getting rid of free market, in fact I want
to *enhance* free market to be more divisible, where *anyone* can
put their labors directly on the market, rather than only companies
and other well-established individuals having that capability.
What I plan to *replace* (as a growing share of the market, not as
a one-shot revolution as occurred in Marxist Russia) is the unit of
monetary exchange, getting rid of $money$ which only some people
have, and using instead *labor* which just about everyone has in
abundance any time there's sufficient incentive for them to develop
(produce) it. Anybody with lots of money and no time can contribute
$money$ to my system any time they want, purchasing *labor* at the
legal minimum wage. If any such $money$ is introduced into my
system, then per any restrictions that may be attached to that
$money$ somebody may later be able to "cash out" their *labor*
credits to get some of that $money$.
> Survival of the fittest will not allow a weaker replacement (at
> least not permanently, see Russia).
There's nothing weaker about my proposed new econonic system.
> Take my advice: Try to adopt to the needs (people skills and
> other things) and try to be successful in the current
> world/economic system.
17+ years of effort per your advice haven't been successful. Your
advice is worthless. Please come over and read the 9.3 megabytes of
detailed notes about my attempts to follow your advice.
> In companies I write C++ programs under Windows. This enables my [sic]
> to help changing the world into a place were people write Seed7
> programs under Linux. :-)
Are you aware of that spelling mistake?
It doesn't look like a keystroke error, but a genuine English mistake.
On 2009-05-25, Robert Maas, http://tinyurl.com/uh3t
<·············@rem.intarweb.org> wrote:
>> From: ·············@gmx.at
>> Don't expect some unrealisic change of the economic system.
>
> You're mistaken on two counts. I'm making an effort *myself* (and
> soliciting collabators to share the workload) to make a *realistic*
> change.
>
>> The evolution will not allow that kapitalism (For europeans: free
>> market economy) to be replaced by something weaker.
>
> I have no intention of getting rid of free market, in fact I want
> to *enhance* free market to be more divisible, where *anyone* can
> put their labors directly on the market, rather than only companies
> and other well-established individuals having that capability.
But it's a consequence of the free market that well-established individuals and
companies have an edge; the market naturally prefers those individuals. You
seem to want to impose some rules which will take away that edge. Any such
rules take away freedom from the market.
The free market necessarily has certain entry barriers which arise
from its freedom. An entry barrier perceived by an individual vying
in the free market is a consequence of the free choice made by many other
individuals not to do business with him, for whatever reasons, none of which
necessarily indicate that there is any problem with the market itself.
Jon Harrop wrote:
> Arne Vajhøj wrote:
>> Jon Harrop wrote:
>>> If you diversify into OCaml or F#, I'll gladly help you advertise your
>>> products.
>> Products ????
>>
>> He is looking for a job !
>
> I suspect he's looking for income.
Possibly, but that does not create any products of of
nothing.
Arne
> From: Jon Harrop <····@ffconsultancy.com>
> I suspect he's looking for income.
I'm looking for *earned* income, which has an advantage over
charity: Somebody is paying me because they appreciate my work, not
just because they feel sorry for worthless little old me. I'd even
be willing to work for **free**, for a while anyway, if just
somebody would appreciate my **free** labors. I'm currently
available to give free lessons: ESL, pre-school reading, computer
programming, board game "Go".
> From: Jon Harrop <····@ffconsultancy.com>
> My CV is 2 pages long. I believe "resume" is American for CV.
My understanding is different. In Europe, employers want to read
somebody's life story, for almost any job. Here in the USA<
employers want the quickest summary, no details until later such as
phone interview. Accordingly it's not *just* a different name for
an otherwise identical first-contact seek-job document, it's a
different name because of a significantly different format and
size. In the USA, a European-style CV is used for academic jobs,
especially for tenured professor.
> If you are interested in working in Europe, I would recommend
> also using "CV".
I already have a CV, about ten pages long, but I'm not looking for
any jobs in Europe, so I have no use for my CV. Do you know any
employers in Europe who would let me tele-work from California?
> If you diversify into OCaml or F#, I'll gladly help you advertise
> your products.
Are either of those available on FreeBSD Unix, or Ubuntu Linux? If
so, what is the name of the program file, so that I can use
'whereis' and 'man' to find info about using it?
Most of my recent software is for server-side Web applications, via
CGI or equivalent. If I write such an application using OCaml or
F#, and show you a demo of it online, how would you know I'm not
cheating by writing the application in Common Lisp and lying to you
saying it's written in OCaml or F# instead? Is there some
characteristic of such software that you can tell what language
it was written in?
On 11 Apr, 22:41, ·············@rem.intarweb.org (Robert Maas,
http://tinyurl.com/uh3t) wrote:
> > From: Jon Harrop <····@ffconsultancy.com>
>
> > If you diversify into OCaml or F#, I'll gladly help you advertise
> > your products.
>
> Are either of those available on FreeBSD Unix, or Ubuntu Linux? If
> so, what is the name of the program file, so that I can use
> 'whereis' and 'man' to find info about using it?
I don't know about BSD but there is an ocaml package for Ubuntu
(which package I've never used). In fact there seem to be quite
a few OCaml related packages which you can find in the Ubuntu
repositories. Regarding documentation many Ubuntu packages
don't come with a man page or the man page only has limited
information and the main documentation is accessible in some
other way. You do dpkg -L <package-name> which will give you the
list of files that came with a package and you'll see which of
those looks like documentation. For large packages the
documentation often exists in a separate package than the
programme itself. For example sbcl-doc is the documentation
for sbcl , cmucl-docs is the documentation for cmucl and , more
to the point , ocaml-doc is (I'm guessing) the documentation for
ocaml.
--
The Balkans Intervention achieved all aims rapidly, giving the
European
continent its first peace in 4,000 years, dramatically enhancing
America's
reputation and world popularity (especially among Muslims)...
David Brin
Spiros Bousbouras <······@gmail.com> writes:
> On 11 Apr, 22:41, ·············@rem.intarweb.org (Robert Maas,
> http://tinyurl.com/uh3t) wrote:
>> > From: Jon Harrop <····@ffconsultancy.com>
>>
>> > If you diversify into OCaml or F#, I'll gladly help you advertise
>> > your products.
>>
>> Are either of those available on FreeBSD Unix, or Ubuntu Linux? If
>> so, what is the name of the program file, so that I can use
>> 'whereis' and 'man' to find info about using it?
>
> I don't know about BSD
ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/lang/ocaml/README.html
No idea, why Dragonfly packages are not there, same package builds on
FreeBSD for me.
--
BECHA...
CKOPO CE3OH...
On Feb 3, 12:57 am, Mariano Montone <··············@gmail.com> wrote:
> You have that resume and can't get a job??!! What can I expect for me
> then... :S
I suspect a lot of people are thinking the same. In my case: major
application areas over last two decades: one; mainstream languages
used: zero :-(
There seems to be too much detail there and some things might just put
off people reading it (like appearing a lot smarter than them; top 1%
in Mensa? And explaining why that is good?).
And what's the buzzword list all about, is this just all the ones he's
simply heard of? Otherwise no-one could possibly have that much
experience in one lifetime. If it's just for getting search engine
hits, there seem to be one or two words left out, or misspelt :-)
--
Bartc
On Feb 4, 7:50 am, Bart <····@freeuk.com> wrote:
>
> There seems to be too much detail there and some things might just put
> off people reading it (like appearing a lot smarter than them; top 1%
> in Mensa? And explaining why that is good?).
>
This is why Robert might need to write a few versions of his resume
and CV, each designed for a particular target audience. The academic,
scientific and research communities, for instance, will very likely be
interested in someone with superior intelligence. On the other hand,
some employers might not be comfortable - initially - with employing
someone whose abilities will create too sharp a distinction between
him/her and the rest of the pack.
> And what's the buzzword list all about,
This might be one reason why Tamas suggested a CV instead of a resume.
Robert's information in resume format looks crowded, while a CV would
allow a more descriptive presentation so the details would not appear
to be "buzzwords".
I think Robert should write both a CV and a resume with versions of
each tailored according to audience. The resume is typically a shorter
document - one or two pages max allowing a quick review of the
applicant's qualifications and interests. The CV is important when the
reader wants a more detailed grasp of the facts.
Rob, don't forget to include any clubs and societies of which you
might be member, e.g. a folk dancing troupe perhaps? This will allow
your potential interviewers to see that you are sociable and relate
well to people - despite your being hacker.;-)
agt
--
Freedom - No pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: ···@codeartnow.com
In article <····································@f40g2000pri.googlegroups.com>,
viper-2 <········@mail.infochan.com> wrote:
>On Feb 4, 7:50 am, Bart <····@freeuk.com> wrote:
>>
>> There seems to be too much detail there and some things might just put
>> off people reading it (like appearing a lot smarter than them; top 1%
>> in Mensa? And explaining why that is good?).
>
>This is why Robert might need to write a few versions of his resume
>and CV, each designed for a particular target audience. The academic,
>scientific and research communities, for instance, will very likely be
>interested in someone with superior intelligence. On the other hand,
>some employers might not be comfortable - initially - with employing
>someone whose abilities will create too sharp a distinction between
>him/her and the rest of the pack.
Mr. Maas has been complaining about his inability to get a job (and
recieving comments on his website, resume, etc) for fifteen years now.
He's obviously smart, but he just doesn't seem to "get it". He
radiates an aura of defeat (perhaps justified) and has serious interpersonal
problems (that's "serious" by the standards of programming professionals,
where being borderline autistic counts as having people skills). He
managed to be unemployed during the .com boom and has variously claimed
to have no friends who could refer him to jobs, no ex-coworkers who
could refer him to jobs, and serious medical difficulties that would
make it difficult for him to work.
I presume he's living on disability and my advice to him would be to
continue to do so. I rather doubt he is capable of working professionally
at this point. I realize that the social safety net in the US ain't great,
but it's there, and I suggest he resign himself to taking advantage of
it for the rest of his life. Sorry, but if you've been unemployed
in the programming field in silicon valley for 20 years then I can not
imagine what is going to change in the next 20.
Mr. Maas - good luck. Seriously.
Alan
--
Defendit numerus
On Feb 4, 2:06 pm, ·······@xenon.Stanford.EDU (Alan Morgan) wrote:
> He
> radiates an aura of defeat (perhaps justified) and has serious interpersonal
> problems (that's "serious" by the standards of programming professionals,
> where being borderline autistic counts as having people skills).
This suggests that you might have a serious problem with people skills
yourself - and you're not even autistic.
--agt
From: William James
Subject: Re: Seeking computer-programming job (Sunnyvale, CA)
Date:
Message-ID: <gmg46m02hui@enews4.newsguy.com>
viper-2 wrote:
> On Feb 4, 2:06 pm, ·······@xenon.Stanford.EDU (Alan Morgan) wrote:
> > He
> > radiates an aura of defeat (perhaps justified) and has serious
> > interpersonal problems (that's "serious" by the standards of
> > programming professionals, where being borderline autistic counts
> > as having people skills).
>
>
> This suggests that you might have a serious problem with people skills
> yourself
No, it doesn't. This suggests that you are devoid of logic or honesty
or both.
> - and you're not even autistic.
But you are?
On Feb 5, 8:36 pm, "William James" <·········@yahoo.com> wrote:
>
> No, it doesn't. This suggests that you are devoid of logic or honesty ...
I don't see the logic in the forming of an opinion on my honesty as
following from anything I've said in this thread. But I may have
NAILed what might be bothering you - and I can't help you.
It's back to code; I'm in Fortran mode.
agt
--
Freedom - no pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: ···@codeartnow.com
You can fool some people sometimes,
But you can't fool all the people all the time.
Get up, stan' up!
Stan' up for your rights!
Get up, stan' up!
Don't give up the fight!
From
"Get Up Stand Up" by
Robert Nesta Marley and Peter Tosh (1973)
On Fri, 06 Feb 2009 01:36:22 +0000, William James wrote:
> viper-2 wrote:
>
>> On Feb 4, 2:06 pm, ·······@xenon.Stanford.EDU (Alan Morgan) wrote:
>> > He radiates an aura of defeat
Did anyone notice his Organization: line?
> No, it doesn't. This suggests that you are devoid of logic or honesty
> or both.
This thread is certainly devoid of something important, and that something
is Java, Lisp, or programming, I'm not sure which.
f'up set to ba.jobs.resumes, the only crossposted group where this seems
like it might be on topic.
--
blue indigo
UA Telecom since 1987
viper-2 <········@mail.infochan.com> wrote in
·········································@e1g2000pra.googlegroups.com:
> On Feb 4, 2:06 pm, ·······@xenon.Stanford.EDU (Alan Morgan) wrote:
>> He
>> radiates an aura of defeat (perhaps justified) and has serious
>> interpersonal problems (that's "serious" by the standards of
>> programming professionals, where being borderline autistic counts as
>> having people skills).
>
>
> This suggests that you might have a serious problem with people skills
> yourself - and you're not even autistic.
Programming is an art. Not an aut.
On Feb 10, 3:19 pm, Anagram <·······@nearmonopolyirkswuss.com> wrote:
> viper-2 <········@mail.infochan.com> wrote ···········································@e1g2000pra.googlegroups.com:
>
> > <snip> - and you're not even autistic.
That last bit was meant to be a joke. I forgot to smile ;-)
> Programming is an art.
Yes, programming is an art.
"Not an aut."
I guess that's a joke too.
All the best Robert.
agt
--
Freedom - no pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: ····@codeartnow.com
Alan Morgan wrote:
> I presume he's living on disability and my advice to him would be to
> continue to do so. I rather doubt he is capable of working professionally
> at this point. I realize that the social safety net in the US ain't great,
> but it's there, and I suggest he resign himself to taking advantage of
> it for the rest of his life. Sorry, but if you've been unemployed
> in the programming field in silicon valley for 20 years then I can not
> imagine what is going to change in the next 20.
That's nonsense; one should never give up trying. Good luck in sorting
it out, Robert.
In article <··············@mid.dfncis.de>,
Matthias Buelow <···@incubus.de> wrote:
>Alan Morgan wrote:
>
>> I presume he's living on disability and my advice to him would be to
>> continue to do so. I rather doubt he is capable of working professionally
>> at this point. I realize that the social safety net in the US ain't great,
>> but it's there, and I suggest he resign himself to taking advantage of
>> it for the rest of his life. Sorry, but if you've been unemployed
>> in the programming field in silicon valley for 20 years then I can not
>> imagine what is going to change in the next 20.
>
>That's nonsense; one should never give up trying. Good luck in sorting
>it out, Robert.
He has been doing exactly the same thing for 15 years (literally. I
found posts of his from 1993 which sound exactly like the ones he posts
today). If someone has been trying and failing for 15 years then they
need to consider the possibility that it just isn't going to work (or
they could change their approach. He has been given ample advice about
how to do that and is either unable or unwilling to take said advice).
I feel sorry for the guy. Obviously life has not treated him with a
great deal of kindness. But, I'm not sure that telling him to keep doing
exactly what has been beating him down over the last decade+ is helpful.
Alan
--
Defendit numerus
Alan Morgan wrote:
> In article <··············@mid.dfncis.de>,
> Matthias Buelow <···@incubus.de> wrote:
>> Alan Morgan wrote:
>>
>>> I presume he's living on disability and my advice to him would be to
>>> continue to do so. I rather doubt he is capable of working professionally
>>> at this point. I realize that the social safety net in the US ain't great,
>>> but it's there, and I suggest he resign himself to taking advantage of
>>> it for the rest of his life. Sorry, but if you've been unemployed
>>> in the programming field in silicon valley for 20 years then I can not
>>> imagine what is going to change in the next 20.
>> That's nonsense; one should never give up trying. Good luck in sorting
>> it out, Robert.
>
> He has been doing exactly the same thing for 15 years (literally. I
> found posts of his from 1993 which sound exactly like the ones he posts
> today). If someone has been trying and failing for 15 years then they
> need to consider the possibility that it just isn't going to work (or
> they could change their approach. He has been given ample advice about
> how to do that and is either unable or unwilling to take said advice).
>
> I feel sorry for the guy. Obviously life has not treated him with a
> great deal of kindness. But, I'm not sure that telling him to keep doing
> exactly what has been beating him down over the last decade+ is helpful.
Actually, giving up is the worst thing to suggest. The mere fact that
the OP has /not/ given up hope is a hopeful sign. Giving up hastens the
end and removes all chance of finding that one employer who might be
able to tolerate his idiosyncrasies and provide him with a little income.
Something tells me you are speaking in the abstract and not from
experience of helping such folk. IIANM, you might want to STFU.
hth,kth
On Feb 5, 4:29 pm, Kenneth Tilton <·········@gmail.com> wrote:
> Alan Morgan wrote:
> > In article <··············@mid.dfncis.de>,
> > Matthias Buelow <····@incubus.de> wrote:
> >> Alan Morgan wrote:
>
> >>> I presume he's living on disability and my advice to him would be to
> >>> continue to do so. I rather doubt he is capable of working professionally
> >>> at this point. I realize that the social safety net in the US ain't great,
> >>> but it's there, and I suggest he resign himself to taking advantage of
> >>> it for the rest of his life. Sorry, but if you've been unemployed
> >>> in the programming field in silicon valley for 20 years then I can not
> >>> imagine what is going to change in the next 20.
> >> That's nonsense; one should never give up trying. Good luck in sorting
> >> it out, Robert.
>
> > He has been doing exactly the same thing for 15 years (literally. I
> > found posts of his from 1993 which sound exactly like the ones he posts
> > today). If someone has been trying and failing for 15 years then they
> > need to consider the possibility that it just isn't going to work (or
> > they could change their approach. He has been given ample advice about
> > how to do that and is either unable or unwilling to take said advice).
>
> > I feel sorry for the guy. Obviously life has not treated him with a
> > great deal of kindness. But, I'm not sure that telling him to keep doing
> > exactly what has been beating him down over the last decade+ is helpful.
>
> Actually, giving up is the worst thing to suggest. The mere fact that
> the OP has /not/ given up hope is a hopeful sign. Giving up hastens the
> end and removes all chance of finding that one employer who might be
> able to tolerate his idiosyncrasies and provide him with a little income.
>
> Something tells me you are speaking in the abstract and not from
> experience of helping such folk. IIANM, you might want to STFU.
>
> hth,kth
Woof! Woof!
Translation:
Go Kenny Go! ;-)
--
Freedom - no pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: ···@codeartnow.com
On 2009-02-05, Matthias Buelow <···@incubus.de> wrote:
> Alan Morgan wrote:
>
>> I presume he's living on disability and my advice to him would be to
>> continue to do so. I rather doubt he is capable of working professionally
>> at this point. I realize that the social safety net in the US ain't great,
>> but it's there, and I suggest he resign himself to taking advantage of
>> it for the rest of his life. Sorry, but if you've been unemployed
>> in the programming field in silicon valley for 20 years then I can not
>> imagine what is going to change in the next 20.
>
> That's nonsense; one should never give up trying.
One, however, at one point one should give up trying exactly the same thing
over and over again, hoping to that the results will change. That is not sane
behavior.
Kaz Kylheku wrote:
> On 2009-02-05, Matthias Buelow <···@incubus.de> wrote:
>> Alan Morgan wrote:
>>
>>> I presume he's living on disability and my advice to him would be to
>>> continue to do so. I rather doubt he is capable of working professionally
>>> at this point. I realize that the social safety net in the US ain't great,
>>> but it's there, and I suggest he resign himself to taking advantage of
>>> it for the rest of his life. Sorry, but if you've been unemployed
>>> in the programming field in silicon valley for 20 years then I can not
>>> imagine what is going to change in the next 20.
>> That's nonsense; one should never give up trying.
>
> One, however, at one point one should give up trying exactly the same thing
> over and over again, hoping to that the results will change. That is not sane
> behavior.
"exact same"? One never steps into the same stream twice. If one has
been paying attention, our applicant's contributions here on c.l.l have
improved greatly lately. And new employers are coming along all the
time, but sparsely, so the wise course is a steady presence and steady
reminder of one's availability.
my2,kth
Kaz Kylheku wrote:
> On 2009-02-05, Matthias Buelow <···@incubus.de> wrote:
>> Alan Morgan wrote:
>>> I presume he's living on disability and my advice to him would be to
>>> continue to do so. I rather doubt he is capable of working professionally
>>> at this point. I realize that the social safety net in the US ain't great,
>>> but it's there, and I suggest he resign himself to taking advantage of
>>> it for the rest of his life. Sorry, but if you've been unemployed
>>> in the programming field in silicon valley for 20 years then I can not
>>> imagine what is going to change in the next 20.
>> That's nonsense; one should never give up trying.
>
> One, however, at one point one should give up trying exactly the same thing
> over and over again, hoping to that the results will change. That is not sane
> behavior.
"The definition of insanity is doing the same thing over and over
again and expecting different results." is often attributed to
Albert Einstein.
Arne
In comp.programming Bart <··@freeuk.com> wrote:
| There seems to be too much detail there and some things might just put
| off people reading it (like appearing a lot smarter than them; top 1%
| in Mensa? And explaining why that is good?).
That could get people a lot of job offers ... when there is money to pay them.
--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |