Noob Wonders: Lisp-1 vs. Lisp-2
are
Lisp, I'm wondering what the advantages of a Lisp-2 are over a Lisp-1.
It seems to me that a Lisp-2's ability to use a single symbol to
represent both a function and a value is a minor advantage, although
I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2
requires the clunky, IMHO, #' operator and cannot have a elegant,
universal DEFINE like Scheme's.
Yet I've heard that a Lisp-1's macros are necessarily less powerful
than those of a Lisp-2. Is that true? Are there some other big
advantages of a Lisp-2 that I'm missing?
Rainer Joswig
<74e46212-fcd3-4d2d...@t1g2000pra.googlegroups.com>,
are <Prop...@gmx.net> wrote:
See here:
Michael Weber
> It seems to me that a Lisp-2's ability to use a single symbol to
> represent both a function and a value is a minor advantage, although
> I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2
> requires the clunky, IMHO, #' operator and cannot have a elegant,
> universal DEFINE like Scheme's.
Here's a DEFINE in CL (see also the rest of the thread and its
references):
http://groups.google.com/group/comp.lang.lisp/msg/d1918aee5dd0f512
Michael
Pascal Costanza
> Having read Touretzky's introduction and the first half of PG's On
> Lisp, I'm wondering what the advantages of a Lisp-2 are over a Lisp-1.
>
> It seems to me that a Lisp-2's ability to use a single symbol to
> represent both a function and a value is a minor advantage, although
> I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2
> requires the clunky, IMHO, #' operator and cannot have a elegant,
> universal DEFINE like Scheme's.
In my personal experience, I have more problems with nameclashes in
Scheme (quite often, actually) than in Common Lisp (practically never).
A standard (but somewhat silly) example is
(let ((list '(a b c)))
... you can't use the function 'list here anymore in Scheme ...)
But this happens to me in more realistic scenarios...
> Yet I've heard that a Lisp-1's macros are necessarily less powerful
> than those of a Lisp-2. Is that true? Are there some other big
> advantages of a Lisp-2 that I'm missing?
Lisp-1 macros are not less powerful. You can have macro systems in
Scheme that give you the same expressiveness as the Common Lisp macro
system (like syntax-case or syntactic closures). With R6RS, you now even
have symbol / identifier macros.
However, such so-called hygienic macro systems are, IMHO, much more
complicated to use. (They are easier for simple cases, but much harder
for complex cases.)
In general, Lisp-2 encourages you to separate namespaces for different
concepts, which allows you to have different meanings for the same name
in different contexts or for different uses. In contrast, Lisp-1
encourages you to represent concepts as first-class objects. Both
approaches have advantages and disadvantages.
Personally, I generally prefer Lisp-2 over Lisp-1 in practical settings,
but Lisp-1 has advantages if you want to present the core essentials of
an idea. That's probably why Scheme is more widely used in academia than
Common Lisp...
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Kent M Pitman
Mostly my comments here reply to the inner message, but Rainer added the
URL at end which I wanted to keep in and add a comment about.
> In article
> <74e46212-fcd3-4d2d...@t1g2000pra.googlegroups.com>,
> are <Prop...@gmx.net> wrote:
>
> > Having read Touretzky's introduction and the first half of PG's On
> > Lisp, I'm wondering what the advantages of a Lisp-2 are over a Lisp-1.
> >
> > It seems to me that a Lisp-2's ability to use a single symbol to
> > represent both a function and a value is a minor advantage,
In understanding things like this, you should worry you are not being
objective when your attempt to understand injects "minor" into the
data collection rather than the analysis. Just say it's viewed as
an advantage, then put the word "minor" into the analysis after the fact.
If you're still trying to collect data and also if you aren't speaking to
a specific target audience, you can't assess major vs. minor.
I personally consider this issue extremely major.
> > although
> > I'm sure some regard it as a disadvantage.
And some would say major disadvantage here, just to underscore my point
about how your wording biases you--you are already pre-biasing the outcome
by comparing point-by-point rather than by just enumerating the issues and
comparing in the context of a known user with particular value scores.
In the metaphor of our world, I think another way to say this is that
either: The assessment of point scores needs to be dynamically, not
statically, assessed ... or, perhaps, that it's a macro and it's too
early to bind the names to values.
I think you are correct here not to add the major/minor qualifier, I'm only
pointing out that your decision to say major/minor in one case but not the
other is inconsistent.
> > On the other hand, a Lisp-2
> > requires the clunky, IMHO, #' operator and cannot have a elegant,
Elegance is a term that is not canonically defined. Be very careful
about this term. There are many forms of elegance. Elegance of
language is not the same as elegance of program, for example. Certain
members of the Scheme community seem to me to not only have a
preference for a single kind of name, but then to take that into the
meta to say that the word elegance can only denote a single thing,
too. Don't fall into that trap.
I'm not saying Scheme isn't elegant in its own way--I'm saying it does
not have a strangehold on the notion of elegance.
Historically, I created the terms lisp1/lisp2 (see below) for the purpose
of making this NOT be a battle between Scheme and Lisp, but rather between
one particular design principle and another. But, in practice, the people
making arguments do come from these communities and tend to have strong
allegiances to their own communities which they often don't think through
as isolated design choices, but accept sometimes as a necessary whole.
At least, in your quest for the Truth (there isn't just one truth either,
by the way--that's part of my joke here), make sure to consider this.
> > universal DEFINE like Scheme's.
I'm glad you wrote IMHO, since I don't agree that #' is best described as
clunky. It just satisfies a different aesthetic.
Calling #' clunky is like calling the words public/private/protected
in other class systems, or calling the ':'/'::' thing in our package
system clunky. They increase the number of characters you have to
write, but buy something in return.
The question of clunkiness creates an implicit bias in whether you
either like the price or value the outcome; and it's legitimate to not
like the price or value the outcome, but when assessing the value of
something from anything other than a flamewar, you want to make sure
to understand that it isn't necessary to something's existence that it
satisfy the non-consumers of it, it's necessary that it satisfy the
consumers of it. On the other hand, the (effective) adverb IMO or
IMHO turns "clunky" as a general claim into "clunky within the
non-general framework of one observer", and is then unobjectionable,
but loses its scientific basis in the process as a term for describing
the feature overall.
In fact, during the design process, and even now, not everyone agreed
that functional programming style was what they wanted to do. They
weren't trying to make it super-expensive, but they were saying "it
doesn't occur often enough that I don't want to see it notated when it
happens". So the flip side community actually likes seeing it in many
cases, at least for #'foo vs foo, because it flags "this is a function being
passed" vs "this is a variable", and that's an important thing to see.
In the case of lambda, it's redundant, and Lisp has grown the alternative
of allowing you to write either #'(lambda...) or (lambda...) so it's not
an issue there.
> > Yet I've heard that a Lisp-1's macros are necessarily less powerful
> > than those of a Lisp-2. Is that true?
Lisp1 advocates would likely phrase this in a way that was spun more
positively, making side-by-side comparison difficult. In many cases,
they will say that the Lisp-1 macro system works reliably and leave it
to you to infer that this means the Lisp2 macro system doesn't. It
wouldn't under Lisp-1, I think; but they don't have packages, and some
in that community think packages make no sense either. But the
combination of packages, macros, and normal CL programming style lead
to no major problems in practice due to the Lisp2 sytle.
> > Are there some other big
> > advantages of a Lisp-2 that I'm missing?
> See here:
>
> http://www.nhplace.com/kent/Papers/Technical-Issues.html
This published paper is a short form of a longer document we used in
the X3J13 process; the longer document is the origin of the terms
Lisp1/Lisp2, and at some point it should be dredged up. (As I recall,
it didn't have the word "Technical" on its name and had additional
arguments that Gabriel wanted to omit during formal publication.)
Xah Lee
「Having read Touretzky's introduction and the first half of PG's On
advantages of a Lisp-2 that I'm missing?」
Please try to avoid the jargons lisp1 and lisp2.
Recently i have just wrote a longish essay on the harm of jargons in
functional languages.
See
Newsgroups: comp.lang.lisp, comp.lang.scheme, comp.lang.functional
From: Xah Lee
Date: Wed, 9 Jan 2008 12:20:47 -0800 (PST)
Subject: Re: Java as a first language "considered harmful"
http://groups.google.com/group/comp.lang.lisp/msg/9c93ce334527797d?dmode=source
HTML version now at
http://xahlee.org/emacs/jargons_high_level_lang.html
(Jargons And High Level Languages)
---------------------------
The jargon lisp1 and lisp2 is one of better example that illustrate
the issue.
★ The jargon is opaque. The words do not convey its meaning.
★ Being a opaque jargon, it is often used subsconsciously by people in
a group, to communicate that they are in-group. (a cast-
differentiation stratedgy of human animals; as is much of slang's
purpose) And consequenctly, these jargons are thrown about often
without the writers actually understanding, or wishing to discuss
about it in any way.
Further, it is my opinion, this issue is extremely minor, having
little real-world practical impact. It is not unlike a war about which
end of egg one should crack. (i.e. big endian vs little endian)
(See:
★ Gulliver's Travels. PART I ― A VOYAGE TO LILLIPUT
http://xahlee.org/p/Gullivers_Travels/gt1ch04.html
)
Why is this issue minor? Consider it broadly in human animal's
computing activities. I give 2 examples:
Consider that in the 1960 people went to moon. Imagine what
complexities involved in the physics, mathematics, computation, at a
time when computer are some one thousand times slowers than today,
using punch-cards, and there are not much computer languages, not even
modular programing.
For another example, consider today's PHP language. Linguistically, it
is one of the most badly designed language, with many inconsistancies,
WITH NO NAMESPACE MECHANISM, yet, it is so widely used that it is in
fact one of the top 5 most deployed languages. If one of PHP or lisps
and all associated applications written in them is to suddenly
disappear from the face of this earth as a catastrophic punishment
from Zeus, and all the leaders of nations is to have experts to access
the damage as they do with natural disasters, it is probable PHP would
be the much greater loss.
-------------
To people in the lisp communities, i would suggest, to stop using the
term. If necessary, say Common Lisp's model or Scheme Lisp model.
Maciej Katafiasz
> Please try to avoid the jargons lisp1 and lisp2.
>
> Recently i have just wrote a longish essay on the harm of jargons in
> functional languages.
Please stop being a dumb arsehole and a troll. As long as you only
post your tripe in separate threads, I can just ignore you, but stop
presenting your bullshit as advice to people who might not be able to
tell you're deranged.
Maciej
PS. Do you write anything but longish essays? Though hopefully that's
a good thing, I'd expect most sane individuals to just tl;dr them,
thus minimising the harm done.
Blake McBride
> Elegance is a term that is not canonically defined. Be very careful
> about this term. There are many forms of elegance.
I would define "elegance" as follows.
One program is more elegant than another that solves the same problem at
least as well but in a simpler manner.
Blake McBride
Pascal Costanza
Now we only need to define "simple." ;)
Christopher Browne
> Blake McBride wrote:
>> Kent M Pitman wrote:
>>> Elegance is a term that is not canonically defined. Be very careful
>>> about this term. There are many forms of elegance.
>> I would define "elegance" as follows.
>> One program is more elegant than another that solves the same
>> problem at least as well but in a simpler manner.
>
> Now we only need to define "simple." ;)
"Shorter" is an objective measure, and it is common for "more elegant"
approaches to be shorter than "less elegant" approaches.
"Fewer lines" does not usually signal a more elegant mathematical
proof, but there's a strong likelihood that "fewer symbols" is
suggestive of such...
--
output = ("cbbrowne" "@" "linuxfinances.info")
http://www3.sympatico.ca/cbbrowne/sgml.html
Never lend your car to anyone to whom you have given birth to.
--Erma Bombeck
Kent M Pitman
> Pascal Costanza <p...@p-cos.net> writes:
> > Blake McBride wrote:
> >> Kent M Pitman wrote:
> >>> Elegance is a term that is not canonically defined. Be very careful
> >>> about this term. There are many forms of elegance.
> >> I would define "elegance" as follows.
> >> One program is more elegant than another that solves the same
> >> problem at least as well but in a simpler manner.
> >
> > Now we only need to define "simple." ;)
>
> "Shorter" is an objective measure, and it is common for "more elegant"
> approaches to be shorter than "less elegant" approaches.
Yeah, that's one reason Teco and APL have been so popular.
> "Fewer lines" does not usually signal a more elegant mathematical
> proof, but there's a strong likelihood that "fewer symbols" is
> suggestive of such...
Certainly... sometimes. But I don't think that if you ask people
about elegance without biasing the input, or if you show people
various solutions and ask which is most elegant, with a properly
distributed set of inputs, that you'll get answers that uniformly say
this is so. There is an elegance in Shakespeare, even though I
suspect it is not a minimal form. There is language design elegance
in Esperanto, and yet people aren't rushing to it over other natural
languages. The Chinese character set has a certain grace and
elegance, and yet there are people who think there's elegance in the
Latin alphabet, too, and probably people who are annoyed at both. Not
everyone is trying to optimize the same set of qualities. The Lisp1
family of languages is not optimizing the same concerns as the Lisp2
family. The world would probably be boring if there were only one
canonical kind of elegance.
In my experience, Lisp2 advocates have little problem understanding
Lisp1 people think as they do, while why some vocal Lisp1 advocates
seem to want the Lisp2 community to cave and "admit" there is no such
desire to be other than the one way, that it was all a delusion. I
find the meta pressure to conform the most annoying part of the whole
Lisp1/Lisp2 debate. I don't feel a problem with Lisp1 existing, I
just don't want to join it, and I don't want to be told that there's a
lack of validity in my desire not to. This ought not to devolve to some
sort of debate over whether this is elegant.
I assert that the Lisp2 solution seems simple and elegant to me, and
more elegant and simple than the Lisp1 solution. I might use
"simplistic" for Lisp1 because to me, it gains textual ground by
sacrificing things I care about. Kind of like saying an elegant
solution to the problem of getting wet in the rain isn't to wear
raincoats but not to go out in the rain. You can make such a claim,
but no one who likes going outside will accept it as elegant or
minimal or anything like that because they are denied something they
need and want. Elegance must surely be measured in the context of
things one wants to do, and telling someone that a simpler solution is
to ignore part of the things they want to do is meaningless and/or
provocative.
There is a belief by me and others that there is an elegance to the
Lisp2 solution; that seems to me an existence proof that the usage of
the term is reasonable. We want a solution that permits the
simultaneous use of words for multiple meanings in exactly the way
English does (and nearly all, if not all, human languages do).
I don't recognize a logical mechanism to refute this. All you can do
is ignore valid data, or challenge the legitimacy of a community (my
community). That seems both unwise and unproductive.
I do not, by contrast, challenge that there are people who use the term
differently. I merely challenge any claim that their right to the use
of the term elegant or simple is canonical.
I am sometimes willing to say that languages like Lisp1 "have a certain
elegance", that is, they display one of many kinds of things people
(to include myself) call elegance on some occasions. I just would not
replace "a" with "the" in such a statement.
Don Geddis
> Please try to avoid the jargons lisp1 and lisp2.
> Recently i have just wrote a longish essay on the harm of jargons in
> functional languages.
Your "longish essay" shows vast ignorance, a lack of any research into the
history and significance of the topic, and is really barely more than your
personal, uninformed, stream-of-consciousness rambling.
> To people in the lisp communities, i would suggest, to stop using the
> term. If necessary, say Common Lisp's model or Scheme Lisp model.
You're apparently not aware that the practice you suggest was EXACTLY the
community's approach in the past. It had severe problems, namely:
1. The choice of namespaces is (at least potentially) orthogonal to other
aspects of a language's design;
2. Common Lisp and Scheme differ in far more ways than just namespaces.
How do you avoid confusion, if you really mean to talk about only the
namespace issue?
These topics were addressed far more intelligently by Gabriel and Pitman
in 1988:
http://www.nhplace.com/kent/Papers/Technical-Issues.html
Presumably, before you were even aware that Lisp existed.
One of the great, lasting, advances of that paper was the creation of the
terms "Lisp1" and "Lisp2", as a _superior_ replacement for discussing the
topic, compared to the phrasing that you suggest (and that was used
previously).
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
I hope some animal never bores a hole in my head and lays its eggs in my brain,
because later you might think you're having a good idea but it's just eggs
hatching. -- Deep Thoughts, by Jack Handey [1999]
Ken Tilton
Don Geddis wrote:
> Xah Lee <x...@xahlee.org> wrote on Thu, 10 Jan 2008:
>
>>Please try to avoid the jargons lisp1 and lisp2.
>>Recently i have just wrote a longish essay on the harm of jargons in
>>functional languages.
>
>
> Your "longish essay" shows vast ignorance, a lack of any research into the
> history and significance of the topic, and is really barely more than your
> personal, uninformed, stream-of-consciousness rambling.
Enough already with this description of the average Usenet post, tell us
what you think about Xah's... oh. sorry.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Alex Mizrahi
??>> about this term. There are many forms of elegance.
BM> I would define "elegance" as follows.
BM> One program is more elegant than another that solves the same problem
BM> at least as well but in a simpler manner.
simplicity is not the only one virtue. often programmers would prefer
approaches that are more general, that can be adapted to wider set of
problems, even if these programs would be more complex.
because problems often evolve with time, and it's better to be able to adapt
existing solution, than to have a simplier one and throw it away completely.
Blake McBride
That is what "at least as well" means.
Xah Lee
"lisp1", "lisp2", because these jargons just perpetuate a non-issue.
I wrote:
「
Recently i have just wrote a longish essay on the harm of jargons in
functional languages.
The jargon lisp1 and lisp2 is one of better example that illustrate
the issue.
* The jargon is opaque. The words do not convey its meaning.
* Being a opaque jargon, it is often used subsconsciously by people in
a group, to communicate that they are in-group. (a cast-
differentiation stratedgy of human animals; as is much of slang's
purpose) And consequenctly, these jargons are thrown about often
without the writers actually understanding, or wishing to discuss
about it in any way.
Further, it is my opinion, this issue is extremely minor, having
little real-world practical impact. It is not unlike a war about which
end of egg one should crack. (i.e. big endian vs little endian; See:
Gulliver's Travels. PART I -- A VOYAGE TO LILLIPUT, Chapter 4 (
http://xahlee.org/p/Gullivers_Travels/gt1ch04.html ))
Why is this issue minor? Consider it broadly in human animal's
computing activities. I give 2 examples:
Consider that in the 1960 people went to moon. (Moon landing↗) Imagine
what complexities involved in the physics, mathematics, computation,
at a time when computer are some one thousand times slowers than
today, using punch-cards, and there are not much computer languages,
not even modular programing.
For another example, consider today's PHP language. Linguistically, it
is one of the most badly designed language, with many inconsistancies,
WITH NO NAMESPACE MECHANISM, yet, it is so widely used that it is in
fact one of the top 5 most deployed languages. If one of PHP or lisps
and all associated applications written in them is to suddenly
disappear from the face of this earth as a catastrophic punishment
from Zeus, and all the leaders of nations is to have experts to access
the damage as they do with natural disasters, it is probable PHP would
be the much greater loss.」
---------------------
Now, suppose we narrow the scope of "lisp1 vs lisp2" to its context:
computer language design. There are many issues in language design.
For example: dynamic scope vs lexical scope, various models of typing
systems (dynamic, static, variable/value based, no types, with or
without inference system), computing model (OOP, Functional,
procedural, pattern matching, database), evaluation model (greedy vs
lazy) ... etc. Among all language design issues, the "lisp1" vs
"lisp2" is really one of those less significant, which actually arise
practically only in Lisp due to its peculiar concept of its "symbols".
The existance of a name to a concept or idea, especially a opaque
jargon, tends to get people to throw the name and argue about it
unnecessarily.
To people in the lisp communities, i would suggest, to stop using the
term. If necessary, say Common Lisp's model or Scheme Lisp's model.
----------------------
This essay is now archived at:
http://xahlee.org/emacs/jargons_high_level_lang.html
Now, in the following, i wish to discuss some associated issue. In
particular, tracing the "why".
There's a curious question. Why is the "lisp1 vs lisp2" happens only
in lisp, and we don't have "perl1 vs perl2", "java1 vs java2", "ML1 vs
ML2", or any language with a variation on this?
This has to do with the concep of lisp's symbol, which doesn't exist
in other languages (notably except Mathematica).
Now, a further question is then, why Common Lisp's symbol of a
particular name can have mulitple meanings? (That is, a name in CL can
both be a variable and a function in the same block of code at the
same time. (This peculiar fact, we might give it a professional
terminology for ease of communication, and we might call it: Common
Lisp's multi-meaning-space, or just multi-meaning-space, meaning-
space.))
Now, the question is, why does Common Lisp has this multi-meaning-
space?
I do not know much about the technical aspects of Common Lisp's
history. However, i can venture a educated guess.
Common Lisp's multi-meaning-space feature, just like so many of its
features (cons, sort, and semi-regular syntax using nested parens,
etc), is simply designed as is without necessarily explicit,
important, rationals. In other words, it is probably a characteristic
that happens to be convient, easy to implement, or not thought about
at the time, or simply went one way than the other.
Now, as i mentioned before, this (single/multi)-meaning-space issue,
with respect to human animal's computing activities, or with respect
to the set of computer design decisions, is one of the most trivial,
having almost no practical impact. And, because some human animals, in
the history of their power struggle, is produced the byproduct of the
jargons "lisp1" and "lisp2". And due to the fact that which end of egg
to crack is now blessed with a terminology that has all the
counternance of impartiality, it furnishes and fuels counterless
arguments and fightings on this non-issue between the Scheme Lisp and
Common Lisp factions, even when the origin of the power struggle on
this particular issue (the Common Lisp Standard) has long died. (more
specifically, every few months the issue will rise up in
comp.lang.lisp or comp.lang.scheme, with all colors and types of
activities from sincere to trite to re-examination to political
struggle to pacification.)
Given that this is a good subject for debate, even though now we
understand that it is a non-issue, but nevertheless you are a geek,
and i'm a geek, and we fucking love to discuss this. Thus, let me now
let you know my allegiance and alliance.
On this issue, i deem the Common Lisp the fuckfaces. Why? In my
opinion, the Common Lisp's multi-meaning-space feature is just
something quaint. Term this un-natural if you want and debate what is
natural or un-natural. But looked from another view, the fact that
almost no language support it, is a good reason that it shouldn't be
so (assuming all other things being equal).
Xah Lee
I wrote:
“Now, the question is, why does Common Lisp has this multi-meaning-
space?”
It should be
“Now, the question is, why do Lisps before Common Lisp have this multi-
meaning-space?”
I don't like to post corrections to newsgroup posting. No more
corrections on this will be posted.
Kent M Pitman
Alex may have meant, as I did in earlier text, that all this is fine
but you still have to define what "just as well means" by having an
adequate predicate that takes in all the sensibilities of the
programmer, not just the ones that manifest in a particular program.
A very "simple" (by some metric) program that is nevertheless not
rewritable easily to another that might be needed instead if program
requirements change might be seen as not only not simple in the new
case but ALSO not simple in the original case if a better and more
comprehensive (er, dare I say "less simple"?) set of values to
preserve was imposed on the entire context in which the programming
occurs.
These discussions get quickly messy if you don't pin down the values
that you care about and make sure they are in play from the beginning,
not just at points along the way. If simplicity metrics can vary
point-to-point, one might call this "mercinary" simplicity (or
relativist simplicity, by analogy with notions of relative and
absolute notions of value systems or ethics), some odd effects
happen... or, at least, some things you didn't expect because you
didn't indicate that such a system of evaluation was in play.
So probably some or all of us are in agreement on the issue of "at
least as well" and we're just trying to understand the valuation
metric and whether it's well-defined at all points. Again, for me, it
comes back to the issue of canonicality, or lack thereof, for any definition
of simplicity.
Rainer Joswig
<8f1bff57-cbe7-4d6b...@p69g2000hsa.googlegroups.com>,
Xah Lee <x...@xahlee.org> wrote:
> In my previous message, i suggested people to not use the jargon
> "lisp1", "lisp2", because these jargons just perpetuate a non-issue.
Why don't you just stop telling the Lisp community which words
it should use and which not?
Why are you writing about it, if don't know much about
the technical issues and the historic context?
...
> To people in the lisp communities, i would suggest, to stop using the
> term. If necessary, say Common Lisp's model or Scheme Lisp's model.
It has nothing special to do with 'Common Lisp' or 'Scheme'.
There are some Lisp languages that are Lisp2:
MacLisp, Lisp Machine Lisp, Common Lisp, Emacs Lisp
Others are Lisp1:
Scheme, EuLisp, ISLisp ...
> I do not know much about the technical aspects of Common Lisp's
> history. However, i can venture a educated guess.
>
> Common Lisp's multi-meaning-space feature, just like so many of its
> features (cons, sort, and semi-regular syntax using nested parens,
> etc), is simply designed as is without necessarily explicit,
> important, rationals. In other words, it is probably a characteristic
> that happens to be convient, easy to implement, or not thought about
> at the time, or simply went one way than the other.
That is wrong. People have thought about these issues quite
a bit.
http://www.dreamsongs.com/Separation.html
The strongest force for Common Lisp to be a Lisp2 was
that the Lisp dialects it historically builts on were Lisp2, too:
MacLisp, Lisp Machine Lisp.
The issue comes up when people design a new Lisp dialect.
It is one of the basic design decisions. It was one of the early
design decisions for Common Lisp.
http://www.dreamsongs.com/NewFiles/Hopl2.pdf
See also:
http://www.softwarepreservation.org/projects/LISP/conference/ilc02/Masayuki-Ida.pdf
The History of Lisp Standardization during 1984 ? 1990
Masayuki Ida
Xah Lee
「Why don't you just stop telling the Lisp community which words it
should use and which not?」
I presented my idea, with detailed reasoning, for the public to
consider. My writings on this issue has now reached over a thousand
words, so i separated it into its own page, now archived at:
http://xahlee.org/emacs/lisp1_vs_lisp2.html
Rainer wrote:
「Why are you writing about it, if don't know much about the technical
issues and the historic context?」
Sometimes, when you are a outsider, you can see things clearly, of
which the endianess and the allusion to which ends of eggs to crack,
is fitting. Jonathan Swift (1667-1745) used it to mock the political
parties of his time (or perhas the catholics and protestants). And
this is borrowed in modern time to mock the byte order arguments. I,
hereby, borrow it to mock the “lisp1 vs lisp2” debate.
For example, i tried to show the insignificance of this single/multi-
meaning-space issue, in the context of human animal's computing
activities, and also in context of programing language design. I
showed, in my opinion, it is trivial issue of little practical impact.
And, i argued, that this jargon, is a culprit for this un-important
issue to be perpetually discussed and debated.
Let me ask you a question. What is it, that you fret about whether the
terms lisp1 lisp2 be used?
Kent Pitman, and his affiliation and opinion on these jargons, is
understandable. He, coined, or participated in the coinage, of these
terms. The use and popularity of these terms, spread alone with his
name. And, if we take the cynical view, his actions and beliefs
regarding these jargons spurs from egoism, and that applies to all
human animals.
What, is your vantage on this jargon issue? Trying to uphold some
truth? Annoyed by my what you believe to be disruptive, abnormal, or
specious views?
What is your thought, regarding my main arguments about the
insignificance of this single/multi-meaning-space issue, and how do
you refute that this “lisp1 lisp2” jargons engender fruitless and
wastful debates?
Xah wrote:
「To people in the lisp communities, i would suggest, to stop using the
term. If necessary, say Common Lisp's model or Scheme Lisp's model.」
Rainer wrote:
「It has nothing special to do with 'Common Lisp' or 'Scheme'.
There are some Lisp languages that are Lisp2:
MacLisp, Lisp Machine Lisp, Common Lisp, Emacs Lisp
Others are Lisp1:
Scheme, EuLisp, ISLisp ... 」
Yeah, of course. Thanks for this historic info. Today, lisp are for
practical purposes just Common Lisp and Scheme Lisp. (and emacs lisp,
AutoLisp and others if you want to count small ones.) So, my
suggestion, of saying Common Lisp's model or Scheme Lisp's model, do
make good sense. I think a more communicative term, would be single-
meaning-space and multi-meaning-space.
Xah wrote:
「I do not know much about the technical aspects of Common Lisp's
history. However, i can venture a educated guess. Common Lisp's multi-
meaning-space feature, just like so many of its features (cons, sort,
and semi-regular syntax using nested parens, etc), is simply designed
as is without necessarily explicit, important, rationals. In other
words, it is probably a characteristic that happens to be convient,
easy to implement, or not thought about at the time, or simply went
one way than the other.」
Rainer wrote:
「That is wrong. People have thought about these issues quite
a bit.
http://www.dreamsongs.com/Separation.html
[Technical Issues of Separation in Function Cells and Value Cells, by
Richard P Gabriel, Kent M Pitman, 1988]」
I don't think you really understood me correctly there. My passage,
from the context, is about why lisp has the multi-meaning-space in the
first place. The paper you cited, is written when this political
struggle is on-going, in consideration of its introduction to Common
Lisp, a post-analysis of the single vs multi meaning-space issue.
The question is, why did lisp(s), has the multi-meaning space in the
first place. Where did it origin? Was it just one lisp or multiple
implementation all started with it, or from a spec? Which is the first
lisp that started with single-meaning-space? And, if there is one
original lisp that started the multi-meaning-space, then, how or why
it is so? How important, or how consciously, was the issue at the time
with this first lisp?
I conjecture (slightly expanded now), that there probably was a first
lisp(s) and it is multi-meaning-space, and the fact of that is not one
of the important design issue but rather one of the million small
characteristics that just happens to be when something comes into
being.
From the paper you cited, in the “4. Historical Perspective” section,
i quote:
“Most Lisp dialects adopted a two-namespace approach to the naming
problem. To some extent this is because most dialects followed Lisp
1.5 [McCarthy 1965] or dialects derived from Lisp 1.5”
So, this partly answered our previous questions about the origin.
Further, i quote:
“It seems that the designers of Lisp 1.5 thought of function names as
being different from variable names--the Lisp 1.5 interpreter looked
at the property list of the named atomic symbol first, and so it can
be argued that a function was considered a property of a symbol. The
designers used the terminology that a symbol "stands for" a function
while a variable "refers" to a value.”
This gives us some hints about why it was multi-meaning-space. Exactly
why Lisp 1.5 is so, perhaps some lisp historian here can detail. Or
perhaps we can email McCarthy.
The paper did not explicitly mention when did single-meaning-space
came into being. Presumably it was just from Scheme... (you mentioned
EuLisp, ISLisp. Do they come before or after Scheme?)
Rainer Joswig
<f4b6620f-82dd-4b3c...@p69g2000hsa.googlegroups.com>,
Xah Lee <x...@xahlee.org> wrote:
...
> Let me ask you a question. What is it, that you fret about whether the
> terms lisp1 lisp2 be used?
>
> Kent Pitman, and his affiliation and opinion on these jargons, is
> understandable. He, coined, or participated in the coinage, of these
> terms. The use and popularity of these terms, spread alone with his
> name. And, if we take the cynical view, his actions and beliefs
> regarding these jargons spurs from egoism, and that applies to all
> human animals.
>
> What, is your vantage on this jargon issue? Trying to uphold some
> truth? Annoyed by my what you believe to be disruptive, abnormal, or
> specious views?
>
> What is your thought, regarding my main arguments about the
> insignificance of this single/multi-meaning-space issue, and how do
> you refute that this “lisp1 lisp2” jargons engender fruitless and
> wastful debates?
These are technical issues that come up when you think
about Lisp implementations. For example the absolutely
excellent book 'Lisp in Small Pieces' by Christian Queinnec
has a whole chapter devoted to this topic:
Chapter 2: Lisp, 1, 2, ... infinity
http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/LiSP.html
>
> Xah wrote:
> 「To people in the lisp communities, i would suggest, to stop using the
> term. If necessary, say Common Lisp's model or Scheme Lisp's model.」
>
> Rainer wrote:
> 「It has nothing special to do with 'Common Lisp' or 'Scheme'.
> There are some Lisp languages that are Lisp2:
> MacLisp, Lisp Machine Lisp, Common Lisp, Emacs Lisp
> Others are Lisp1:
> Scheme, EuLisp, ISLisp ... 」
>
> Yeah, of course. Thanks for this historic info. Today, lisp are for
> practical purposes just Common Lisp and Scheme Lisp. (and emacs lisp,
> AutoLisp and others if you want to count small ones.) So, my
> suggestion, of saying Common Lisp's model or Scheme Lisp's model, do
> make good sense. I think a more communicative term, would be single-
> meaning-space and multi-meaning-space.
It does not make sense to bind terms to things that happen
to be popular. Popularity changes. Languages change.
Lisp is now 50 years old. It has seen many dialects and
we will see many more. Still some of the basic principles
of Lisp implementation are independent of the dialect
that happens to be popular at any one time.
ISLisp is still used. There are also lots of other Lisp dialects
in usage. Some only inside companies (say as extension language)
or single applications.
(I heard that a disk drive vendor has a Lisp in their
firmware.). I'm always careful to not exclude other Lisp dialects.
For some it may not be important, since they have never
used anything else from Scheme or Common Lisp. Some
others feel that there is need for more experimentation,
diversity or a clean-up. EuLisp especially was such an
attempt to create a cleaned-up Lisp. One that has some
properties that were important to its designers: smaller,
less historical baggage, 'elegant', efficient, object-oriented.
I feel that it is not a good idea to attach technical issues
to a particular dialect. Then you also would need to start a lot
of renaming. Generic Functions would be 'functions like
in CLOS' and so on. Other Lisp dialects also have Generic
Functions.
...
> I conjecture (slightly expanded now), that there probably was a first
> lisp(s) and it is multi-meaning-space, and the fact of that is not one
> of the important design issue but rather one of the million small
> characteristics that just happens to be when something comes into
> being.
Check out Queinnec's book where he discusses the technical
issues in context of various implementation strategies.
He also mentions that (some) Scheme compilers internally transform
Lisp-1 code to Lisp-2 code.
>
> From the paper you cited, in the “4. Historical Perspective” section,
> i quote:
>
> “Most Lisp dialects adopted a two-namespace approach to the naming
> problem. To some extent this is because most dialects followed Lisp
> 1.5 [McCarthy 1965] or dialects derived from Lisp 1.5”
>
> So, this partly answered our previous questions about the origin.
> Further, i quote:
>
> “It seems that the designers of Lisp 1.5 thought of function names as
> being different from variable names--the Lisp 1.5 interpreter looked
> at the property list of the named atomic symbol first, and so it can
> be argued that a function was considered a property of a symbol. The
> designers used the terminology that a symbol "stands for" a function
> while a variable "refers" to a value.”
>
> This gives us some hints about why it was multi-meaning-space. Exactly
> why Lisp 1.5 is so, perhaps some lisp historian here can detail. Or
> perhaps we can email McCarthy.
>
> The paper did not explicitly mention when did single-meaning-space
> came into being. Presumably it was just from Scheme... (you mentioned
> EuLisp, ISLisp. Do they come before or after Scheme?)
EuLisp and ISLisp come after Scheme. Like Common Lisp.
Common Lisp was also designed after Scheme.
I see that ISLisp is also a Lisp2. A new revision of the standard
has been published in 2007:
http://www.open-std.org/JTC1/SC22/WG16/open/standard.html
Some dates when some Lisp dialects were designed:
Scheme: 1975- 2007 (R6RS)
Lisp Machine Lisp: 1978 (first spec) -?
Common Lisp: 1981 (first discussions) 1984 (CLtL1) -
1990 (CLtL2) - 1994 (ANSI Standard)
EuLisp: 1985 (first discussion) - 1993 (0.99 spec)
ISLisp: end of 1980s-1997 (spec published) - 2007 (revision)
The Common Lisp designers had two main concerns when
it comes to Lisp1 vs Lisp2: existing practice (which also
means lots of existing code) and efficiency for (compiled)
code. Efficiency was important, both for vendors (and their
customers) and users. If somebody had a large piece of software,
it should not run slower in the new language, just because
somebody added more baggage to it. Common Lisp was a
compromise - it looks and feels that way. It was built
on a lot of existing experience. It was certainly more safe
to use existing practice, than to adopt radical new stuff.
There was already enough 'new' stuff. For example
the introduction of 'lexical binding' (by default) in a
MacLisp-derived language.
>
> Xah
> x...@xahlee.org
> ? http://xahlee.org/
Kent M Pitman
Xah Lee <x...@xahlee.org> writes:
> sorry, a minor correction but important.
>
> I wrote:
> “Now, the question is, why does Common Lisp has this multi-meaning-
> space?”
>
> It should be
> “Now, the question is, why do Lisps before Common Lisp have this multi-
> meaning-space?”
>
> I don't like to post corrections to newsgroup posting. No more
> corrections on this will be posted.
Notwithstanding the claim by some zealous advocates of single
namespaces that such a naming scheme is canonically determined and the
only natural way of doing things, I think it's just not so: I think
earlier dialects picked it because it felt natural to whoever was
doing it. (That doesn't mean they were saying no one should ever
design a system otherwise, they were just saying they preferred not
to.)
(I suspect one of the strong pressures for caring about this issue at
all is the underlying representation of binary library structure,
which often tends to prefer flat names and requires "name mangling" of
various kinds to wedge the surface namespace into the interchange
language-independent namespace. I suspect that where that pressure
does not exist, this tends to sort out differently than where it does.
In the modern world of cross-calling languages, there is considerable
pressure to do things in the way the backbone does it, to accommodate
something like the CLR. I don't claim this is a completely irrelevant
issue--design needs to be done in a context, and this has become the
relevant context for a large number of users. But I do claim that a
discussion of "the right design within such a context" is not a
discussion of "what is natural or appropriate to people".)
By the way, while I don't tend to agree with or respond to a lot of
your posts for various reasons that are more social than technical, I
do think that the following text from an upthread post of yours, while
not something I agree with, is also not an unreasonable personal
opinion to take--it's just not one I agree with. I've been
disappointed by the harshly negative response to your remarks as if
you've offended some religion by making them. In fact, while I don't
agree, there's evidence you've given some thought to these issues, and
I am saddened by the idea that thoughtful people would reject each
others' ideas or cast aspersions on one another merely because they
disagree on technical claims, and I do consider these technical
claims. (Ironically, I think the reason you get the negative feedback
you do is that I think you've done the same to others in the past, so
maybe there's some justice here, or some lessons all around.
Nevertheless, I don't think that compounding past injustices with new
ones fixes anything.) Consequently, since these remarks are spoken with
due civil and technical focus, I'm going to reply in kind:
Xah wrote:
> * The jargon is opaque. The words do not convey its meaning.
Dictionary.com [ http://dictionary.reference.com/browse/jargon ]
gives one definition of jargon as:
jargon[1] -noun 1. the language, esp. the vocabulary, peculiar to
a particular trade, profession, or group
That term would tend to span all words used on this newsgroup. I was
surprised to see the definition [5] there, though:
5. language that is characterized by uncommon or pretentious
vocabulary and convoluted syntax and is often vague in meaning.
since I would have regarded this as the connotation, not denotation, in
that the word jargon is often used with this as the "hidden meaning" as
a way of conveying a put-down without acknowledging overtly one's intent.
It's fine they list it as a denotation, though--it makes my analysis a
bit easier.
In the world at large, the uses Lisp1/Lisp2 are certainly uncommon and
without doubt qualify as jargon, but within the Lisp world, even words
like cons and car and cdr, which might likewise qualify as jargon in
the real world, don't qualify as jargon. And while the terms
Lisp1/Lisp2 are not as common as car/cdr, they are the terms of choice
many have used to address this issue. No one forced their usage. I
was surprised to see them take hold. But the use is voluntary, and
human languages change in just such a voluntary way. Uses can be
legislated.
One can make arguments for non-use, of course, as you're doing. But
such arguments do not have to be heeded. Grammarians have fussed for
years that words like "yeah" and "ain't" are not words, and as a
consequence they are excluded from formal writings, but they are
nevertheless common and a natural-language understanding system that
didn't know these words would be deficient. The issue is even more
striking for "y'all" (Southern) and "yous" (New York? not even sure
how to spell it) where these words, though identified as substandard,
actually solve a language design problem of ambiguity of the word
you... it's as if the controllers of English grammar books don't want
this problem solved. A similar problem happens for "they" and "their"
as the gender-unspecified article. (In the MOO universe, the pronouns
"e" and "eir" are used, but that hasn't caught on in the real world.)
It's a pity that getting good solutions in a language takes so long and
it's no wonder people gravitate informally toward a word that lets them
get on with discussing things.
The Lisp1/Lisp2 issue is something people notice and like to discuss,
and it helps them to have a word. In that regard, the usage is not
pretentious, but enabling.
Note that I have myself leveled criticisms based on "perspicuity" before,
when terminology talks past the point. But that doesn't seem in play
here because people seem to first decide they want to discuss this topic,
then find there is a word. I don't think anyone can claim that this doesn't
speak straight to the point they have in mind.
The principle reason not to wish I'd chosen different terms is that
the issue transcends Lisp. The same issue can come up in other languages,
and then you're left talking about Dylan1 and Dylan2, or something. But,
actually, that's not so terrible. I think it would have the same effect
there.
> * Being a opaque jargon, it is often used subsconsciously by
> people in a group, to communicate that they are in-group.
> (a cast-differentiation stratedgy of human animals; as is
> much of slang's purpose) And consequenctly, these jargons
> are thrown about often without the writers actually
> understanding, or wishing to discuss about it in any way.
I've often said that it's useful to actually listen to others, even
those you disagree with, because you learn things. In this case,
while I don't have the same interpretation (in part because, having
created the term in the first place, I know as absolute fact that the
intent was just the opposite), I learned something interesting about
how something can be misperceived. (And, in fact, I note further that
although the original intent was different, that doesn't mean there
can't be some reality to the notion that these things take on a life
of their own after launched, so I'm not dismissing the possibility that
someone would have this interpretation. I would just ask you to see
that this is interpretation is just one of many possible, and that
there is another side.)
Let me speak to what was intended and then maybe you'll see the irony
here:
The words were created in the context of a discussion about a highly
specific language feature, in the context of the design of a language
whose semantics had not been frozen yet. So the whole notion that
there is a caste-system (I'm assuming you mean "caste" with an "e" in
your above remark) in play is funny because (to use the non-"e"
version of that word), the die had not yet been cast as to which
hypothetical community was in play for the discussion.
The discussion was of whether the language wanted to join one of these
two worlds. (In fairness, it had already joined, but it was open for
discussion whether it would stay there. And we were trying to retain an
open mind.)
The problem was, in writing the paper, that it seemed that Gabriel was
pushing for the one-namespace style and I was pushing for the
two-namespace style. In fact, as I recall, the committee assigned us
to co-write the analysis BECAUSE we disagreed. So we batted the paper
back and forth between us over the net, each injecting things into it
and trying not to perturb the other's text, and the paper reads as a kind
of discussion between us if you look at it in the right way. That often
means that people from each side read it and see only their own side of
the discussion (as happens when partisan people watch debates) and then
wonder how anyone could conclude that their original idea wasn't right.
The paper embodies both sides and supports both conclusions, to some
degree.
The paper, as published, is not the text of the paper that X3J13 used
to decide though. The word "Technical" at the start of the paper
identifies the published paper; the original did not have that word,
and contained additional discussion that I think got left out for
publication. So that may be why it's hard to understand how the vote
fell the way it did, I don't recall. I should look this up some time.
(If I get some time today, maybe I'll rummage old papers since this has
come up a number of times.)
But in any case, back to my story, the "conversation" in the original
paper took on structure I did not like. In plain terms, I felt I was
losing the debate, and I felt it wasn't for reasons I considered "fair".
Not that Gabriel was doing anything per se inappropriate, but he kept
using the term "Scheme" as the opponent position. And I didn't want this
to be a debate over Common Lisp vs Scheme. Because it gave the false
perception that the choice was between Common Lisp and Scheme, which was
a weird thing for Common Lisp designers to be debating. There was already
Scheme, and anyone wanting to use Scheme was already free to use it.
And even if he won the debate, Common Lisp was not going to be Scheme.
So THAT was what was misleading.
(This is the irony I spoke of in your conclusion that these terms
support an in-group analysis. I don't claim you're wrong in having
that impression--you have, as a point of fact, whatever impression you
have. I take you at your word that this is your impression. However,
you are wrong in thinking that's the intended impression or
effect. Just the opposite.)
By choosing the Lisp1/Lisp2 terminology, as illustrated in the paper, I
wanted to say "there is a possible Scheme which has Lisp2 semantics" and
"there is a possible CL that has Lisp1 semantics", exactly to neutralize
the notion of in-group allegiance. I felt that if these words had no
other meaning that precisely what was in discussion, saying "Let's make
CL Lisp2-like" (or "Lisp1-like") instead of "Let's make CL Scheme-like"
(or "CLTL-like") would better allow a fair analysis of the issues.
And I think once this subtle shift of terminology was made, we were
able to have the debate fairly. And the result was that we retained
the status quo, which I suppose could mean you could sum it as that I
had "won" the debate. And I do think it was due to the use of this
term, but NOT because it caused people to think of themselves as
in-group or out-of-group, but rather because it allowed them to
neutrally view the options without extra "warm fuzzy" feelings that I
think people always get with the word Scheme, not all of which were in
play in this discussion.
So if you look at these terms as describing before-the-fact choices,
not after-the-fact reified camps of people, you'll see it differently.
The fact of this analysis gives me new insight into other issues I've
seen in political debates, by the way, and I thank you for that. I'll
expand on that just briefly.
Terms like "Communist", "Democratic", "Fascist", "Socialist",
"Liberal", "Conservative", "Libertarian", and even "Green" presumably
exist to help people give names to concepts that are intellectually
interesting, each of them, in their own right, and that might guide
their thinking. Students learn them in school and often are much more
open-minded and mix-and-match about these things, much more willing to
consider alternatives, do comparisons, and in every way use the terms
as they were probably originally designed. These terms, at least at
their time of creation, are about the exercise of thought. They may
have some evangelistic component, but they also surely require a
free-thinker even to consider them. Later in life, though, these
things become "worked problems" and people look to them not as
selectable decision theories but rather as labels to attach to people.
From the outside, one labels others (see Fox News or Rush Limbaugh or
Ann Coulter for the most extreme examples) as "liberal" or
"conservative" not as a way of being descriptive, but actually as a
way of dismissing or sorting people--as if a human being's entire
reasoning system can be reduced to a word. It is as if the essence of
things is that no one should indeed ever think, other than to select
the Good Way (and then never think again) or select the Bad Way
(proving you never thought even once in your life, since even that
choice was wrong and since after that choice all of your wrong choices
are due to that choice). It is not the term which establishes the
caste, it is the use of the term in a non-analytic way.
I think that sometimes these categorizations are essential in a world
full of too much information, as a way of making guesses quickly. But
one must be careful not to take them as fixed, invariant truth.
Perhaps that's why I've responded to your post here today, rather than
simply dismissing it. Your posts very often contain a lot of bile and
negativity and other things that I find unhelpful, and so I don't tend
to patronize them. But I don't see that as a reason to dismiss
reasonable points you make, on those occasions where I happen to have
the time to be reading at all and can notice such points.
I really enjoy reading things written by people who disagree with me.
I just like it to happen respectfully. And I hope I've been adequately
respectful in return in the context of this message.
tim Josling
> I've been
> disappointed by the harshly negative response to your remarks as if
> you've offended some religion by making them. In fact, while I don't
> agree, there's evidence you've given some thought to these issues, and
> I am saddened by the idea that thoughtful people would reject each
> others' ideas or cast aspersions on one another merely because they
> disagree on technical claims, and I do consider these technical
> claims.
Quite true. If you sort through the intemperate language there is a lot of
good material particularly on his web site.
Xah Lee has done a huge amount of research and even when I don't agree he
is often thought provoking.
If you read his web site, you can gain some understanding of why he is how
he is. Not everyone had a smooth path from comfortable suburbia to an ivy
league school.
Still, it would be in his interests to consider the effect of the way he
uses language.
Tim Josling
Cor
Some entity, AKA tim Josling <tejgcc...@westnet.com.au>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Still, it would be in his interests to consider the effect of the way he
> uses language.
Do you really mean that ?
Just because the messenger used "Hey-'yo 'ya-bunch" instead of My Dearly
Beloved Congregation ... ?
Would you really believe the 'foo-thinghy instead of the 'bar-thinghy
because the paper 'foo-thinghy was written on did not match your colour taste ?
Maybe , the lingo is just used to kick some life in stuffed shirts ...
Cor
--
SPAM DELENDA EST http://www.clsnet.nl/mail.php
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Alle schraifvauden zijn opsettelick, teneynde ieder lafaart de cans te
gevuh over spelingk te mekkuh instede de inhaut
Don Geddis
> I do not know much about the technical aspects of Common Lisp's history.
> However, i can venture a educated guess.
I wonder: when you are ignorant, rather than guessing, why don't you actually
become educated? There is a historical truth to what happened. That truth is
actually available to you, if you bothered to look or ask questions.
What you are doing is providing an IGNORANT guess, not an educated guess.
You seem to have no interest in educating yourself about the questions you
profess to be interested in -- even when there are factual answers to those
questions!
> In other words, it is probably a characteristic that happens to be
> convient, easy to implement, or not thought about at the time, or simply
> went one way than the other.
A fine, ignorant guess.
Unfortunately, it turns out, in fact, to be false.
Why do you think it is useful to sit in your room and make guesses about
things like this, rather than look out into the real world and see what the
real answer is? You remind me of the ancient Greeks. Did you really learn
nothing from the progress of science in the last 2000 years?
> And, because some human animals, in the history of their power struggle, is
> produced the byproduct of the jargons "lisp1" and "lisp2". And due to the
> fact that which end of egg to crack is now blessed with a terminology that
> has all the counternance of impartiality, it furnishes and fuels
> counterless arguments and fightings on this non-issue between the Scheme
> Lisp and Common Lisp factions
You're blaming the terminology itself for the conflict? As through there
were no actual issue involved?
I agree with you that the core issue is a minor one. But to say that the
conflict is CAUSED by the terminology seems absurd. The conflict existed
long before the terminology, and surely would continue even if the
terminology changed.
> On this issue, i deem the Common Lisp the fuckfaces.
You're attempting to explore and explain an objective, technical issue, and
you think this kind of language is appropriate? In a newsgroup devoted to
Common Lisp? What response do you even expect, except something like "no,
YOU are the fuckface"?
Even if you had an actual technical point, your poor choice of presentation
completely overwhelms it.
> But looked from another view, the fact that almost no language support it,
> is a good reason that it shouldn't be so (assuming all other things being
> equal).
Looked at it from another view, Lisp has embodied many advanced programming
language concepts that other languages ignored for decades, and only recently
began appreciating the value and adding. Garbage collection, macros, symbols,
etc. Surely, if your argument ("popularity in other languages") were valid,
it would apply to all those concepts also (at least until the recent past).
Or, perhaps there is a benefit to the features that you don't yet understand.
Instead of making assertions from your ignorant guesses, why don't you try
doing a little research? E.g., ask fans of Lisp2 languages what benefits THEY
see from the design choice? Maybe you'll learn something.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
If you're not part of the solution, then you're part of the precipitate.
tim Josling
>> Still, it would be in his interests to consider the effect of the way
>> he uses language.
>
> Do you really mean that ?
>
> Just because the messenger used "Hey-'yo 'ya-bunch" instead of My Dearly
> Beloved Congregation ... ?
>
> Would you really believe the 'foo-thinghy instead of the 'bar-thinghy
> because the paper 'foo-thinghy was written on did not match your colour
> taste ?
>
> Maybe , the lingo is just used to kick some life in stuffed shirts ...
>
> Cor
>
>
It didn't affect me. I spent several hours reading through his web site.
But "university studies show" that most people are greatly impacted by
appearance and impressions.
You seen this in the computer field all the time where people are sucked
in by good looking demos that have no substance to them whatsoever ie no
actual capability.
Have a look at some advertising to see the rubbish that convinces most
people. None of us are immune - we are all human.
Tim Josling
tim Josling
>
> Looked at it from another view, Lisp has embodied many advanced programming
> language concepts that other languages ignored for decades, and only recently
> began appreciating the value and adding. Garbage collection, macros, symbols,
> etc. Surely, if your argument ("popularity in other languages") were valid,
> it would apply to all those concepts also (at least until the recent past).
>
It's interesting that other languages have been importing many features,
but macros seems to be an exception. My impression is that macros are less
used now than 10 or 20 years ago.
There seems to be a phobia about macros. People keep reinventing them but
are very wary of calling them macros.
If you have a look at the java world, there is a large amount of code
generation going on. There is also an amazing amount of patching of object
files (.class files) as well.
C++ has templates, which have reportedly now reached the stage of being
Turing-complete. But macros are still frowned upon.
There are two explanations I have seen:
1. If you use macros, you are almost defining a new language. You have to
look at the macro definition to see what the code does.
This argument seems equally applicable to the use of any facility beyond
in-line code (eg using other classes). And most languages with macros have
the ability to expand the macro for viewing.
In any case, as Paul Graham never tires of pointing out, maybe you do want
to create a new language, a domain specific language. This may be a really
good idea.
What puzzles me is that people accept patching class files but will not
accept macros. How do you look at the source of a patched class file?
2. In the early days, people went too far with macros and the code became
unmaintainable.
This seems to be just an argument for discipline in programming projects.
Is there any other explanation? Here is Sun's explanation for no macros in
Java.
http://www.artima.com/weblogs/viewpost.jsp?thread=5246
Tim Josling
Andrew Reilly
> What puzzles me is that people accept patching class files but will not
> accept macros. How do you look at the source of a patched class file?
>
> 2. In the early days, people went too far with macros and the code
> became unmaintainable.
>
> This seems to be just an argument for discipline in programming
> projects.
>
> Is there any other explanation?
I think that the big "problem" wth macros is that because they leave no
trace of themselves in the ultimately-generated executable code, they
make it difficult and confusing to debug with the usual suite of source-
level "IDE" debuggers (you generally can't "step into" a macro the way
you can a function). I have observed that there are a *lot* of otherwise
good programmers who won't even consider stepping outside that paradigm,
and who therefore hate all macros, a-priori.
--
Andrew
Cor
Some entity, AKA tim Josling <tejgcc...@westnet.com.au>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> It didn't affect me. I spent several hours reading through his web site.
> But "university studies show" that most people are greatly impacted by
> appearance and impressions.
I understand that, but it really bugs me that 'packaging seems more
important that the contents, hence my reaction.
George Neuner
>
>Some entity, AKA tim Josling <tejgcc...@westnet.com.au>,
>wrote this mindboggling stuff:
>(selectively-snipped-or-not-p)
>
>
>> Still, it would be in his interests to consider the effect of the way he
>> uses language.
>
>Do you really mean that ?
>
>Just because the messenger used "Hey-'yo 'ya-bunch" instead of My Dearly
>Beloved Congregation ... ?
>
>Would you really believe the 'foo-thinghy instead of the 'bar-thinghy
>because the paper 'foo-thinghy was written on did not match your colour taste ?
>
>Maybe , the lingo is just used to kick some life in stuffed shirts ...
>
>Cor
The problem is that Xah frequently opens a discussion with the moral
equivalent of "hey you fuckers, you should listen to me because I'm
smarter than you". He only rarely responds to discussions of his
posts and when he does, his responses to criticism are frequently
abusive. His style and tone naturally predispose people not to listen
to him.
Xah's opinions are rarely unclear, and he obviously puts quite a bit
of thought into his missives - but many people simply are unwilling to
parse his morass of foul language to understand what it is that he
thinks.
Anyone in advertising will tell you that the form of the message is at
least as important as the message itself. The message doesn't matter
if no one hears it. If Xah cleaned up his language (quite) a bit and
took the chip off his shoulder, I think he would get much more respect
as a critical thinker.
George
--
for email reply remove "/" from address
Kent M Pitman
> It's interesting that other languages have been importing many features,
> but macros seems to be an exception. My impression is that macros are less
> used now than 10 or 20 years ago.
Yes. I think that's for a number of reasons, but basically because
the trend has been toward static analysis and macros themselves are
hard to debug without a decent theory of parsing, presenting language
structures, etc. Without that, they are little more than a sed
script, and that detracts from the other less unruly (more ruly?)
parts of whatever language you are talking about.
> There seems to be a phobia about macros. People keep reinventing them but
> are very wary of calling them macros.
Well, they keep trying to solve the problem in isolation, without
addressing the other parts of the language (manifest representation,
parsing, printing) issues that make it tough to use them. If you want
to solve only the macro problem in isolation, it is a hard problem,
and they're doing the best they can--much better, frankly, than I'd
have predicted, even if not as well as we might wish. I'm pretty
impressed with how much C# managed to clean up templates, to where
they almost feel like they're part of the same language and not some
alien language, unrelated to the base language (as happens in C++).
> If you have a look at the java world, there is a large amount of code
> generation going on. There is also an amazing amount of patching of object
> files (.class files) as well.
>
> C++ has templates, which have reportedly now reached the stage of being
> Turing-complete. But macros are still frowned upon.
Probably because of debuggability, which in turn is because the
language you're writing your template code in really doesn't feel like
the language you've come to master without templates... so it doesn't
leverage a lot of what you know already. It's just a new exercise.
> There are two explanations I have seen:
>
> 1. If you use macros, you are almost defining a new language. You have to
> look at the macro definition to see what the code does. [...]
You are only defining a new language if you don't make your original
language available as a manifest data structre that is easy to
conjure, traverse, parse, and print. What modern language, and here
I'll generously include not only C++ but even C, is incapable of those
four basic operations? The thing that is missing isn't the ability to
manage such structures, it's the ability to know and manipulate and
interact with and extend the actual structures C++ does.
What's people like about Lisp, I think, is that it allows you to take
ordinary knowledge--the kind of knowledge you have already if you've
solved that idiotic FLATTEN-LIST problem that teachers of Lisp always
assign--and use that to write a macro. C++ templates are
unintelligible to someone who does not have reasonably advanced
knowledge of types and methods. That's a huge difference. You could
get a lot of programming done in Lisp without ever mastering defclass,
defstruct, deftype, and typep; to include the use of macros. Not so
in C++ for the equivalent operators.
> 2. In the early days, people went too far with macros and the code became
> unmaintainable.
>
> This seems to be just an argument for discipline in programming projects.
I think it tells you that the tools for creating macros were
error-prone because they were text-based, and they got a bad name
because of token merging bugs and stupid stuff like that. That makes
it politically hard to get people to reconsider them. They have the
kind of overzealous bad reputation that Lisp has in some
circles--where people are eschewing a whole class of concepts because
once, somewhere that they probably don't remember, they saw (or heard
about or think they heard about) one such concept being abused.
> Is there any other explanation? Here is Sun's explanation for no macros in
> Java.
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=5246
Fascinating. But personally, I think the central claim in that post
appears to be unsupported. That is, they seem to assert that macros
would make programs unreadable for everyone else. But they offer no
foundation for this claim. That says a lot.
Probably people are not beating down their doors asking for macros.
People rarely ask for things they are not used to using, and are
usually delighted to get anything that improves their prior state,
with very little regard to whether others somewhere else have
something better. They have to first understand and appreciate that
"something else" to want it, and no one is busy marketing macros to
this community in a form that makes it sound like something they
_would_ want.
For a long time, people used to talk about what an innovation
Microsoft Windows was, mostly because they came from DOS, not the
Macintosh, and certainly not from a Lisp Machine, an Alto, a Dorado,
an Apollo ... Unix (and later Linux) was likewise greeted as an
extraordinary step up by people who had never seen Multics. Progress
often moves backward to move forward because timing, marketing, and
other factors are as important as being right about where you're
going...
- - - - -
By the way, shifting topic for a moment somewhat:
The first course I took at MIT where Lisp was taught was 6.030, I
believe, and I think I took it in the spring of 1977, almost exactly
30 years ago. The Lisp part was taught by Joe Weizenbaum (of ELIZA
fame). I recall a story he told us once about the importance of
always balancing our parens. He took on a mischievous tone at one
point and said something vaguely to the effect of (this was now almost
exactly 30 years ago, in Spring 1977, and this is from memory, so I
might not have the exact words still, but hopefully this is close in
nature): ``Sometimes, when I want to have a little fun with someone,
I'll sneak into their office and write a stray open parenthesis
somewhere on their blackboard. [And he made a little chalk mark to
show us.] And then all day, I imagine they'll wander around feeling
like something is just a little off. Then, later, I'll sneak back in
and close that parenthesis. [He made another chalk mark.] And then
the world will be back in balance, and they may never know why.'' And
he smiled the kind of delighted smile of someone who understood the
power of parentheses to make or break one's day. The remark, or its
essential nature at least, really stuck with me. And I often think on
it and smile.
I noticed you missed a closing parenthesis in the subject line. And
so I was feeling like something was just a little off.
:) <-- Balance restored. I hope you don't mind.
I feel better now.
Kent M Pitman
> I think that the big "problem" wth macros is that because they leave no
> trace of themselves in the ultimately-generated executable code, they
> make it difficult and confusing to debug with the usual suite of source-
> level "IDE" debuggers (you generally can't "step into" a macro the way
> you can a function). I have observed that there are a *lot* of otherwise
> good programmers who won't even consider stepping outside that paradigm,
> and who therefore hate all macros, a-priori.
I don't think this problem is intractable. There are various
different approaches that can be used, some involving more and less
cooperation from macro writers, some involving different data
structures and tools for navigating them than Lisp uses.
Just as an example, there was a stepper written for Lisp by ... hmmm
... I'm going to say Dan Halbert, then a student MIT Lab for Computer
Science, I wish I could remember for sure--anyone know? And I can't
remember the name of the stepper, but I can't do that either. Anyway,
in this stepper I'm remembering some extra operations that macro
expanders could expand into in order to help with interactive stepping
through macrofied code. Vaguely, I recall it being something like:
(defmacro with-variable-bound-to-random-number ((variable n) &body forms)
`(without-stepping
(let ((,variable (random (with-stepping ,n))))
(with-stepping ,@forms))))
or something like that.
[With only slight bits of extra effort, you could even make these forms
take an "argument" which was the parent cons of the point in the
source code that contains the source text, or some other such thing.
Or it could be heuristically inferred.]
This doesn't exhaust the set of things that macro writers are up
against, and each has to be confronted as its own problem. Keeping
track of token-to-line correspondences is another. I've seen various
solutions to that, too. None are trivial but each does a fair job of
getting close enough for serious work.
But they don't get solved by saying "oh, this looks hard" and giving
up. One thing the Lisp community has excelled at is first committing
to doing something, just because it needs to be done, and then making
it work well. If you do it the other way around, only moving forward
when you know how to do it, you don't get nearly as many submissions
about how to improve things. And you hold back program writing in the
interim rather than having people write as they like on the promise or
hope that it will work better by magic later. Some of those promises
don't come true. But more often than not, they do.
lisp linux
>
> I think that the big "problem" wth macros is that because they leave no
> trace of themselves in the ultimately-generated executable code,
I am a newbie But I'll take a shot, what the heck :)
If some CL compiles to C and then generates code and (for argument's sake) can not correlate the
ultimate machine instruction with the CL source, is that a problem with functions
Even if it directly generated machine code, is it automatically given that such an implementation
can correlate source and the machine code
Don't the lexical variables go away unless explicit care is take to preserve stuff for debugging
Isn't same true for tail call merging (or whatever)
I guess logically you should be able to step into macro expansion and then also step into macro
execution, showing appropriate code at the appropriate time, depending on whether you are debugging
expansion or debugging execution (nice theory :) )
Ducking...
-Antony
Evans Winner
I am a newbie But I'll take a shot, what the heck :)
If some CL compiles to C and then generates code and (for argument's
sake) can not correlate the ultimate machine instruction with the CL
source, is that a problem with functions
Even if it directly generated machine code, is it automatically given
that such an implementation can correlate source and the machine code
Don't the lexical variables go away unless explicit care is take to preserve stuff for debugging
Isn't same true for tail call merging (or whatever)
I guess logically you should be able to step into macro expansion and
then also step into macro execution, showing appropriate code at the
appropriate time, depending on whether you are debugging expansion or
debugging execution (nice theory :) )
Inspired by this post, and as a service to the Internet community I am
making available, free of charge, a large collection of periods:
http://timbral.net/periods.txt
Please feel free to take as many as you like; I can generate more as
needed.
tim Josling
> Andrew Reilly <andrew-...@areilly.bpc-users.org> writes:
>
>> I think that the big "problem" wth macros is that because they leave no
>> trace of themselves in the ultimately-generated executable code, they
>> make it difficult and confusing to debug with the usual suite of source-
>> level "IDE" debuggers (you generally can't "step into" a macro the way
>> you can a function). I have observed that there are a *lot* of otherwise
>> good programmers who won't even consider stepping outside that paradigm,
>> and who therefore hate all macros, a-priori.
>
It's understandable. I just faced a choice like this myself. Generate
several thousand lines of code, or use a macro to do a similar thing. This
was for a lexical analyzer. I opted for generating code because the
generated code was just too far away from the source representation - I
needed to be able to look at it.
> I don't think this problem is intractable. There are various
> different approaches that can be used, some involving more and less
> cooperation from macro writers, some involving different data
> structures and tools for navigating them than Lisp uses.
>
The same kind of problem does actually exist with any language above
assembler, but we are used to it. How do you correlate source code with the
machine code when the code has been extensively transformed eg by a code
optimizer?
Variables can disappear or can have wrong values because they are
no longer required. Two different lines of code can share a single machine
instruction. A line of code can be split up into bits. Code can move out
of loops. Values can be stored in different forms (eg a variable used as
an index could be changed to a pointer). Functions can be inlined and then
thrown into the optimizer to be shredded.
There was a quite heated discussion about this on the GCC mailing list a
few weeks ago. One point of contention was should you sacrifice
run-time optimization to get a good debugging experience.
Compiler performance can also be drastically impacted.
http://gcc.gnu.org/ml/gcc/2007-11/msg00176.html
Tim Josling
Thomas F. Burdick
> The principle reason not to wish I'd chosen different terms is that
> the issue transcends Lisp. The same issue can come up in other languages,
> and then you're left talking about Dylan1 and Dylan2, or something. But,
> actually, that's not so terrible. I think it would have the same effect
> there.
Damn you Kent Pitman, you're the reason I sound like a halfwit when
claiming that Smalltalk is a Lisp2 ;-)
Curt
> abusive. His style and tone naturally predispose people not to listen
> to him.
I'm not a programmer; I'm a "layman".
Norman Mailer once said when asked why he didn't wear glasses (because
without them he couldn't recognize his own mother at the other end of the
room at a smoky literary reception), "I don't want to become an
expert." What he meant by that was that it is conceivably superior to
see the "ensemble" fuzzily than certain selective details with
clarity.
Anyhow, you should speak for yourself and not for "people." What
"predisposes" you not to listen to Xah is exactly what "predisposes" me
to do the contrary--different strokes for different folks.
Let's not allow the thought patrol of political correctness and stuffy,
hypocritical rectitude invade and pollute this free space where even a
monkey as low as I on the evolutionary chart can swing and fart with the
higher apes frequenting this lovely jungle, and where the validity of an
idea is judged by its evidence and not by its source, whatever the style
or tone.
lisp linux
>> lisp linux <gmai...@lisp.linux> writes:
>> .......
>> If some CL compiles to C and then generates code and (for argument's
>> sake) can not correlate the ultimate machine instruction with the CL
>> source, is that a problem with functions>
> Inspired by this post, and as a service to the Internet community I am
> making available, free of charge, a large collection of periods:
>
> http://timbral.net/periods.txt
How to I punctuate rhetorical questions ?
Do I put a period or a question mark or is it not specified ?
(These are not rhetorical)
-Antony
Harald Hanche-Olsen
> How to I punctuate rhetorical questions ?
http://en.wikipedia.org/wiki/%3F#Rhetorical_question_mark
The rhetorical question mark doesn't seem to exist in Unicode,
though. What a shame.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Andrew Reilly
> There was a quite heated discussion about this on the GCC mailing list a
> few weeks ago. One point of contention was should you sacrifice run-time
> optimization to get a good debugging experience.
That's (among other reasons) why I'm a died-in-the-wool debug-by
assertion and print guy: compiled-in debugging statements have the same
level of access to variables as the real program, no matter what
optimizations or code-movement is applied. Of course, they may alter
what optimizations are ultimately applied, and they require discipline to
avoid logic-altering side-effects, but those are different problems.
Per Kent's previous comment about tractability: no, I'm sure it's not
ultimately intractable. The DrScheme IDE, for example, has a really keen
macro-stepper. I'm sure that the situation will gradually improve. In
the mean-time, assertions and print statements will always work fine.
--
Andrew
Robert Uhl
>
> I understand that, but it really bugs me that 'packaging seems more
> important that the contents, hence my reaction.
It's not that packaging is more important than contents; it's that we
all have limited time to spend on things and this we need to filter. To
a first approximation a writer who can't be bothered to respect his
audience is probably not worth reading. There are exceptions,
naturally--but as a general rule it's a decent one.
The guy on the street corner shouting about quantum physics and aliens
_might_ have a point. But that's not the way to bet.
Had I infinite time, then naturally I'd listen to and evaluate everyone,
including the crazy guy on the street corner. Not having that luxury, I
have to filter.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Twelve as a divisor has always been preferred to ten. I can understand
the twelfth part of an inch but not the thousandth part of a metre.
--Napoleon
tim Josling
> On Sun, 13 Jan 2008 09:12:05 +0000, tim Josling wrote:
>
>> There was a quite heated discussion about this on the GCC mailing list a
>> few weeks ago. One point of contention was should you sacrifice run-time
>> optimization to get a good debugging experience.
>
> That's (among other reasons) why I'm a died-in-the-wool debug-by
> assertion and print guy: compiled-in debugging statements have the same
> level of access to variables as the real program, no matter what
> optimizations or code-movement is applied. Of course, they may alter
> what optimizations are ultimately applied, and they require discipline to
> avoid logic-altering side-effects, but those are different problems.
>
Yes a few times after spending hours on the debugger I have put in a few
displays and there it is. On the other hand using debuggers to
do hardware traps for storage overlays is useful (in languages with weak
run time checks).
> Per Kent's previous comment about tractability: no, I'm sure it's not
> ultimately intractable. The DrScheme IDE, for example, has a really keen
> macro-stepper. I'm sure that the situation will gradually improve. In
> the mean-time, assertions and print statements will always work fine.
>
Agree - I was thinking about this last night. If you think
debugging HLL then dropping down to assembler you are dropping
down several levels at once. If you add some layers in between for
different levels of macro expansion, you are up and running. Good debuggers
need tight coordination between compiler, linkers and debuggers
to get optimal results.
Tim Josling
Rob Warnock
+---------------
| Cor <c...@clsnet.nl> writes:
| > I understand that, but it really bugs me that 'packaging seems more
| > important that the contents, hence my reaction.
|
| It's not that packaging is more important than contents; it's that we
| all have limited time to spend on things and this we need to filter.
| The guy on the street corner shouting about quantum physics and aliens
| _might_ have a point. But that's not the way to bet.
| Had I infinite time, then naturally I'd listen to and evaluate everyone,
| including the crazy guy on the street corner. Not having that luxury,
| I have to filter.
MIT prof Scott Aaronson's blog had a recent article which is directly
related to this:
http://scottaaronson.com/blog/?p=304
Ten Signs a Claimed Mathematical Breakthrough is Wrong
...
Instead I want to explore the following metaquestion: suppose
someone sends you a complicated solution to a famous decades-old
math problem, like P vs. NP. How can you decide, in ten minutes
or less, whether the solution is worth reading?
And Sabine Hossenfelder's latest blog entry explores even more
outrageous possible consequences of information overload:
http://backreaction.blogspot.com/2008/01/spirits-that-we-called.html
The Spirits that We Called
...
`Information overload' isn't just an error message my brain
produces when I check the arXiv[1], and an expression that I've
made up for fun, but a rather unsurprising and well known side
effect of a tightly connected world. The human brain's capacity
to process input is limited. Today you are confronted with more
information than you a) need and b) can deal with. The challenge
today is not to collect all information you can possibly get,
but to filter it and extract the relevant bits.
-Rob
[1] <http://arxiv.org/>. Sabine is a theoretical physicist, and
the arXiv is *the* hot place these days to get the very latest
preprints, especially the "hep-th" subsection.[2]
[2] <http://arxiv.org/list/hep-th/new> == "High Energy Physics - Theory (new)"
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Alex Mizrahi
??>>
BM>>> One program is more elegant than another that solves the same problem
BM>>> at least as well but in a simpler manner.
??>>
??>> simplicity is not the only one virtue. often programmers would prefer
??>> approaches that are more general, that can be adapted to wider set of
??>> problems, even if these programs would be more complex.
??>> because problems often evolve with time, and it's better to be able to
??>> adapt existing solution, than to have a simplier one and throw it away
??>> completely.
BM> That is what "at least as well" means.
"at least as well" doesn't help here.
suppose we have a more general approach: yes, it solves "same problem at
least as well". but it's more complex, so you will say it's not elegant, if
you follow your logic.
to fix this issue, you need to actually use generality parameter in the
elegance function, not just have inequality: "if it's more general it's ok".
we can define elegance as generality divided by complexity: for given
complexity more general solution is more elegant, and for given generality
less complex solution is more elegant.
these are obvious properties, but we do not know how parameters are
weighted.
some people give more weight to generality -- they tolerate more complex
solution that will help to reduce maintenance costs in long term. and they
actually find these general solutions "good" and "elegant".
other people prefer simplicity -- they just pick simpliest solution that
works for this particular case, and generality is little important.
Robert Uhl
>
> http://scottaaronson.com/blog/?p=304
[snip]
> http://backreaction.blogspot.com/2008/01/spirits-that-we-called.html
Interesting entries both--worth reading, for those of you who haven't
yet. I particularly like the bit about discounting mathematical papers
not written in TeX...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Suffice it to say that the ZlFDY devs I know shouldn't get too close to me in
case my intense hatred causes them to spontaneously combust. --Matt Palmer
Ken Tilton
Robert Uhl wrote:
> rp...@rpw3.org (Rob Warnock) writes:
>
>> http://scottaaronson.com/blog/?p=304
>
Lisp is definitely taking over the world; the math community has adopted
even our methods for dealing with unsatisfactory applicants for
citizenship:
"But when a “proof” has turned into a “plausibility argument” by page 47
— release the hounds!" http://scottaaronson.com/blog/?p=304
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
George Neuner
>On 2008-01-13, George Neuner <gneuner2/@/comcast.net> wrote:
>
>> abusive. His style and tone naturally predispose people not to listen
>> to him.
>
>I'm not a programmer; I'm a "layman".
Then what the hell are you doing here?
>Anyhow, you should speak for yourself and not for "people." What
>"predisposes" you not to listen to Xah is exactly what "predisposes" me
>to do the contrary--different strokes for different folks.
If you enjoy being verbally abused, then nothing I can say in polite
company is going to sink in. I can guarantee that many people do not
enjoy blatant rudeness and name calling.
>Let's not allow the thought patrol of political correctness and stuffy,
>hypocritical rectitude invade and pollute this free space where even a
>monkey as low as I on the evolutionary chart can swing and fart with the
>higher apes frequenting this lovely jungle, and where the validity of an
>idea is judged by its evidence and not by its source, whatever the style
>or tone.
The "thought police" have nothing to do with this - the issue is
polite discourse. No one is stopping Xah or you or anyone else from
posting to Usenet - some of us are simply requesting that posters
refrain from using abusive language.