In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
: I cannot decide if your analogies are false since I cannot make heads
: or tails of them.
You should try to make CARs and CDRs of them instead.
: In what way is Lisp "bland ... all the way through"?
There's little visual distinctiveness to distinguish mentally
distinctive constructs.
: How does Lisp's expressiveness (which I believe measures "easy to say
: and understand") "[get] a big yawn"? Is it because Lisp is so expressive,
: that it is boring?
No, I'm saying that Lisp is only expressive by one rather cerebral kind
of measurement, which neglects many human factors related to how we
think, perceive and talk. And that this is the primary reason people
avoid Lisp.
: Are you saying that most other languages, because they are so
: horrible and so inexpressive, are not boring because they elicit anger
: and frustration, whereas Lisp does not elicit those emotions?
I don't believe that the absence of boredom implies the presence of
anger and frustration. All these states of being are in opposition to
creative excitement.
: Are you saying that you think that the true challenge in programming
: is the actual struggling with the language, rather than the addressing
: the deeper issues (such as, what it is you are trying to do)?
I haven't noticed people struggling that much less with Lisp than with
most other languages. Admittedly, nroff is a bit tougher, unless
you're just trying to do text processing... :-)
: In what way does Lisp "push down so hard" on morphology?
One form to rule them all,
One form to find them,
One form to bring them all
And in the darkness bind them.
In the land of machinery, where the symbols lie.
Essentially, Lisp assumes that humans like to write programs the same
way the machines like to execute them, and so conflates the human
representation with the machine representation. True, there are Lisp
compilers, but the "ideal" is still that the machine and the programmer
are interpreting the exact, same, one-size-fits-all data structure.
: Where's the "tar pit", and what languages do better? (I can think of
: some languages that do better in some areas, but none that, taken as a
: whole, do better for most purposes).
That's precisely the point. "Beware the Turing Tarpit, where
everything is possible, and nothing is easy."
That said, I should back off a little and admit that there are a few
things that are easier in Lisp than in other languages. But your
assumption seems to be that it's better to use an all-around mediocre
language for most everything than to use each language for what it does
best. I'm just pointing out the obvious fact that most people disagree
with that assumption nowadays, and that I suspect that this is the
answer to the question posed in the subject line of this thread.
: I can't even decide if you are serious or not. I guess that all of
: your handwaving means that you must be making a joke. In that case,
: I guess I am too dense to get the joke.
Never assume, just because I'm making a joke, that I'm not also quite serious.
Larry Wall
·····@netlabs.com
From: Jim Carden
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <1866@tekgen.bv.tek.com>
In article <······················@netlabs.com> ·····@netlabs.com (Larry Wall) writes:
>In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>: In what way is Lisp "bland ... all the way through"?
>
>There's little visual distinctiveness to distinguish mentally
>distinctive constructs.
Written by the designer of Perl. Well, Perl certainly cannot be accused of being bland.
To each his own, I guess. I cannot disagree more with almost everything Larry Wall
has written on this subject. As far as syntax goes, LISP and Perl are about as far apart
as they can be (and I hope LISP does not budge).
In article <····@tekgen.bv.tek.com> ····@tekcae.cax.tek.com (Jim Carden) writes:
>In article <······················@netlabs.com> ·····@netlabs.com (Larry Wall) writes:
>>In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>>: In what way is Lisp "bland ... all the way through"?
>>
>>There's little visual distinctiveness to distinguish mentally
>>distinctive constructs.
>
> Written by the designer of Perl. Well, Perl certainly cannot be accused
> of being bland.
>
> To each his own, I guess. I cannot disagree more with almost everything
> Larry Wall has written on this subject. As far as syntax goes, LISP and
> Perl are about as far apart as they can be (and I hope LISP does not
> budge).
Seconded. Every now and then you see a post that reveals a particular
viewpoint so completely alien to your own experience and beliefs that it's
pretty much impossible to address on a point by point basis. Of course, I'm
not surprised that Larry would have fairly well-thought-out views on
language design and syntax, and if Perl is any indicator, that they differ
radically from most others reading this group; it's just very difficult for
me to understand the design philosophy that these views represent.
What's more interesting is the difference this post illustrates between the
view of the problems with Lisp held by those "outside" the Lisp community
and that held by those "inside" the community. Most of the non-Lisp-users'
comments have been, almost universally, about syntax. "Lots of Idiotic
Silly Parentheses". "Lisp assumes that humans like to write programs the
same way the machines like to execute them, and so conflates the human
representation with the machine representation." And so on. And yet, if
you look at the problems the Lisp users are talking about, *nobody* brings
up syntax as a "real" issue. We talk about problems with application
delivery and deployment, confusing/redundant language features, the lack of
Genera on a Sun :-) When syntax is mentioned, it's in terms of a marketing
problem, in the same paragraph that we address the myth that Lisp is an
interpreted language where you have to shoehorn all your data structures in
to lists. All we have to do, it's claimed, is educate enough people on the
real benefits of Lisp, and they'll be so bowled over by Lisp's power that
they'll be more than willing to struggle with the syntax for a little
while. After all, it worked for *us*, didn't it?
Personally, when I'm comparing languages, syntax is way down on my list.
Sure, Ada is verbose, C seems to be more susceptible than most to
obfuscation, Perl is just plain chaotic, whatever. But much more important
to me are issues like modularity, extensibility, and semantic
expressibility. I suppose there was some initial work involved in picking
up the rhythms of Lisp syntax, but that's true with any language, and Lisp
was no more difficult than any other.
Why, then, do others make such an issue of Lisp's syntax? Partly it's our
fault, I suppose, for always trying to claim that the simplicity of it
makes it easier to learn. For one thing, it's not really that simple, once
you get beyond the Reader, and for another, some folks, like Larry, don't
seem to *like* simplicity, preferring the alleged "creative excitement" of
chaos. But, in general, why the discrepency?
Finally,
>>That said, I should back off a little and admit that there are a few
>>things that are easier in Lisp than in other languages. But your
>>assumption seems to be that it's better to use an all-around mediocre
>>language for most everything than to use each language for what it does
>>best.
Well, no, the assumption held most Lisp programmers I know, many of whom
have had substantial experience with other more chaotic languages, is that
when it comes to developing large, complex systems for which there is no
single target that can be addressed by some more focused language, Lisp
wins hands down, not just in a "few things". Very few, if any, would write
a small file utility in Lisp, any more than would attempt to build a large
application in Perl. But this has nothing to do with syntax.
Pete Halverson INET: ·········@crd.ge.com
GE Corporate R&D Center UUCP: uunet!crd.ge.com!halverson
Schenectady, NY
In article <······················@crd.ge.com> ·········@crd.ge.com
(Pete Halverson) writes:
[...]
>Personally, when I'm comparing languages, syntax is way down on my list.
[...]
>Why, then, do others make such an issue of Lisp's syntax?
One reason, in my experience, is the context in which they were introduced
to LISP. I teach AI and AI Programming to MS students at Johns Hopkins.
Almost without exception, students who come into my classes with a smattering
of LISP background (eg in an undergrad course) are biased against the syntax
*from experience*. They were generally introduced by people who were not
serious LISP programmers and in a context (an AI course) where understanding
the language was not a priority. Few heard anything about LISP style or the
importance of indentation or the ideas of functional programming. Not
everyone who takes the AI Programming course here turns into a LISP zealot,
but I do think it is fair to say that few are still troubled by the syntax.
- Marty
(proclaim '(inline skates))
In article <··········@aplcenmp.apl.jhu.edu> ····@aplcenmp.apl.jhu.edu (Marty Hall) writes:
>In article <······················@crd.ge.com> ·········@crd.ge.com
>(Pete Halverson) writes:
>[...]
>>Personally, when I'm comparing languages, syntax is way down on my list.
>[...]
>>Why, then, do others make such an issue of Lisp's syntax?
>
>One reason, in my experience, is the context in which they were introduced
>to LISP. I teach AI and AI Programming to MS students at Johns Hopkins.
>Almost without exception, students who come into my classes with a smattering
>of LISP background (eg in an undergrad course) are biased against the syntax
>*from experience*. They were generally introduced by people who were not
>serious LISP programmers and in a context (an AI course) where understanding
>the language was not a priority. Few heard anything about LISP style or the
>importance of indentation or the ideas of functional programming. Not
>everyone who takes the AI Programming course here turns into a LISP zealot,
>but I do think it is fair to say that few are still troubled by the syntax.
>
> - Marty
As a newcomer to the language, and a relative newcomer (undergrad) to
programming in general, from experience I can confirm, from a different
perspective, much of what you've said.
Since LISP _does_ have a repuatation for being hard to learn I did have
some concerns about the language. On the other hand, during my
third semester programming course, I had a professor who, while teaching
our class (using Pascal), spoke so highly of Lisp, so often, that many of the
students were intrigued by his praise for the language. This has resulted in
a couple of us taking a winter-session course to see what the language
has to offer, and I must say that I enjoy the language very much. It's
so flexible and free from what I would call 'constraints', that I feel
very comfortable with it. I have also found that, since the syntax is simple,
I am free to concentrate on the problem that I am trying to solve, rather
than syntax, type declarations, etc...
Concerning the matter of people feeling uncomfortable with the large
number of parens used, (referring to other posts -sorry for not including
them here), I didn't find that to be difficult since our version of EMACS
blinks the corresponding paren. And lest anyone think that my being
comfortable with 'thinking in parens' might be due to a strong Math
background, let me just say that Comp. Sci. is my second major,
my first major being Ancient Studies (Ancient History & Languages etc.)
and until 18 months ago, I hadn't taken any Math for over 15 years.
(No flames intended, just an observation.) What I _did_ find, is that
the parens required a precision of thought that was challenging, yet
gratifying.
As a final note, then, I would say, yes, in the beginning, my attitude
toward LISP was influenced by a professor whom I respected, and who spoke
positively regarding the language. I would also say that being
'positively oriented' probably facilitated my ability to pick up the
language. The question then, is, in comparison with C and Pascal
(remember, I'm giving you the newcomer's point of view, so I can't give
you a massive list :) of languages with which I have experience), which
language would I choose? Without a doubt, LISP. Too bad I have to
go back to writing in C and Pascal next week.
--
Priscilla Walther
>
> As a final note, then, I would say, yes, in the beginning, my attitude
> toward LISP was influenced by a professor whom I respected, and who spoke
> positively regarding the language.
>
IMHO, Priscilla's hit the nail on the head. Most purchasing decisions
or choices of how to go about doing something are based first on
personal experience and second on recommendations from friends and
colleagues. You may violate this characterization by going out and
researching every purchase that you do; however, I doubt it. Your
choice of store to shop in, refrigerator model, *restaurant*, church,
etc starts with personal recommendations (or sometimes
advertisements). We've got to evangelize and perhaps stoop to
teaching introductory programming courses :-)
Note, IBM and MicroSoft don't corner their markets by quality,
price, or features but by familiarity, trustworthiness, and
marketing agressiveness. They've defined the battle: we must
fight it on their grounds. The same goes for languages.
>
> --
> Priscilla Walther
Don Mitchell ·········@trc.amoco.com
Amoco Production Company (918) 660-4270
Tulsa Research Center
P.O. Box 3385, Tulsa, OK 74102
--
Don Mitchell ·········@trc.amoco.com
Amoco Production Company (918) 660-4270
Tulsa Research Center
P.O. Box 3385, Tulsa, OK 74102
Date: Thu, 21 Jan 1993 18:06 EST
From: Larry Wall <·····@netlabs.com>
In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
: I cannot decide if your analogies are false since I cannot make heads
: or tails of them.
You should try to make CARs and CDRs of them instead.
I personally think CAR and CDR could have been flushed from the
language, since FIRST and REST do the exact same thing. Note, by the
way, that you have picked one of the very few things retained in Common
Lisp for historical purposes.
: In what way is Lisp "bland ... all the way through"?
There's little visual distinctiveness to distinguish mentally
distinctive constructs.
This is simply not a valid criticism. There is little visual
distinctiveness in English to distinguish mentally distinctive
constructs, and yet you do not fault English. In fact, one could argue
that "visual distinctiveness" is a principally a matter of typography.
: How does Lisp's expressiveness (which I believe measures "easy to say
: and understand") "[get] a big yawn"? Is it because Lisp is so expressive,
: that it is boring?
No, I'm saying that Lisp is only expressive by one rather cerebral kind
of measurement, which neglects many human factors related to how we
think, perceive and talk. And that this is the primary reason people
avoid Lisp.
This is still a handwave. You might be right that it is "easy to say
and understand" things in other languages, but I can equally well claim
(with support from others) that it's "easy to say and understand" things
in Lisp as well. And unlike in most other languages, if something
becomes cumbersome to say in Lisp, you can write a macro to make it easy
to say again. Since Lisp is it's own meta-language (this is what many
people erroneously refer to as "Lisp not having any syntax"), Lisp
macros are a natural thing for people to write and use. It would be
wonderful if other languages did as well, but since a truly powerful
macro facility has to, in effect, operate on the syntax tree for a
language form, things get harder.
I really think that the burden is still on you to define what you mean
by "expressiveness", and then show how your pet languages meet these
criteria, and how how Lisp does not.
: Are you saying that most other languages, because they are so
: horrible and so inexpressive, are not boring because they elicit anger
: and frustration, whereas Lisp does not elicit those emotions?
I don't believe that the absence of boredom implies the presence of
anger and frustration. All these states of being are in opposition to
creative excitement.
Yes. Boredom, anger, and frustration are all in opposition to creative
excitement. But you didn't answer the question. I personally get my
creative excitement from trying to solve new problems, not from
successfully cajoling a language into doing what I want it to do.
: Are you saying that you think that the true challenge in programming
: is the actual struggling with the language, rather than the addressing
: the deeper issues (such as, what it is you are trying to do)?
I haven't noticed people struggling that much less with Lisp than with
most other languages. Admittedly, nroff is a bit tougher, unless
you're just trying to do text processing... :-)
Perhaps it is the sort of software I do, but I emphatically do notice
people struggling more with most other languages than with Lisp. Let's
look at memory management, for instance. In most other languages, such
as C, programmers must confront the issue of memory management head on,
right away, even if they don't want to do memory management. I'm
willing to simply concede the point that, with a little practice,
"anybody" can write working memory management in C (although not without
first pointing out that, in the past year I've read two papers claiming
that around 40% of a C programmer's time is spent chasing dangling
poiinters and storage leaks). The point is that, in most other
languages, programmers must immediately tackle programming tasks that
are only incidentally related to the problem at hand.
: In what way does Lisp "push down so hard" on morphology?
One form to rule them all,
One form to find them,
One form to bring them all
And in the darkness bind them.
In the land of machinery, where the symbols lie.
Essentially, Lisp assumes that humans like to write programs the same
way the machines like to execute them, and so conflates the human
representation with the machine representation. True, there are Lisp
compilers, but the "ideal" is still that the machine and the programmer
are interpreting the exact, same, one-size-fits-all data structure.
I fail to see that Lisp makes any such assumption. What machines
directly execute mapping operators? Reduction operators? What machines
directly execute generic arithmetic, including integers, large integers,
floating point, and ratios? Hash tables? Sequences and collections?
This claim just cannot be made to stick.
If I didn't know better, I would be sure that you are talking about C/C++.
I also think you have confused what you call "machine representation"
with "parsed representation". The fact that the human-readable
representation is the same as the basic parsed representation is one of
the great sources of Lisp's power -- it allows Lisp programs to
effortlessly talk about Lisp programs.
Perhaps you think that Lisp's "one-size-fits-all data structure" is the
list, but that reflects a circa-1972 bias for the language (or maybe
even earlier).
: Where's the "tar pit", and what languages do better? (I can think of
: some languages that do better in some areas, but none that, taken as a
: whole, do better for most purposes).
That's precisely the point. "Beware the Turing Tarpit, where
everything is possible, and nothing is easy."
I'll consider myself warned, and avoid Algol-68 as much as possible.
That said, I should back off a little and admit that there are a few
things that are easier in Lisp than in other languages. But your
assumption seems to be that it's better to use an all-around mediocre
language for most everything than to use each language for what it does
best. I'm just pointing out the obvious fact that most people disagree
with that assumption nowadays, and that I suspect that this is the
answer to the question posed in the subject line of this thread.
I don't claim that Lisp is an all-around mediocre language. It's an
all-around excellent language. Sure, there are some languages that have
a few features that are better than what I can find in Lisp, but so
what? If you just want to do rule-chaining and nothing else, by all
means use Prolog. If you are writing an interrupt handler for a device,
why not use C or Bliss? If you are doing program proofs, use ML or
Haskell. And why not use Fortran for some scientific hacking? But for
general programming, I'll take Lisp nearly every time. Moral: use the
right tool for the job.
So while you may be pointing out an obvious fact that people don't want
to use an all-around mediocre language, you are just tilting at a windmill,
since I made no such assumption.
: I can't even decide if you are serious or not. I guess that all of
: your handwaving means that you must be making a joke. In that case,
: I guess I am too dense to get the joke.
Never assume, just because I'm making a joke, that I'm not also quite serious.
What makes me sad is that I know you're serious, and yet you have
entirely missed the real issues about why Lisp isn't a mainstream
language. Other messages (e.g., Pete Halverson's) under the same
subject have started to touch on the real issues.
From: David F. Skoll
Subject: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <dfs.727723285@noonian>
I've noticed a thread extolling the beauty of Lisp syntax. While I agree
that mostly, Lisp syntax is easy to understand and consistent, I wonder
what sort of mental disease struck the creators for the "format" function.
Take a look at all the baroque format directives in Common Lisp. I mean,
who really needs the number 394829348234982435 formatted in English words??
Just try (format t "~R~%" 394829348234982435) for fun!
--
David F. Skoll
From: Hal Mueller
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1jpe0qINNnf1@tamsun.tamu.edu>
In article <·············@noonian> ···@doe.carleton.ca (David F. Skoll) writes:
>who really needs the number 394829348234982435 formatted in English words??
>Just try (format t "~R~%" 394829348234982435) for fun!
Well, if i DID need it, I'd hate to write it! Fortran and C versions
are left as an exercise.
--
Hal Mueller If guns are outlawed, only the government
········@orca.tamu.edu will have guns.
From: David F. Skoll
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <dfs.727729181@crusher>
In <············@tamsun.tamu.edu> ········@orca.tamu.edu (Hal Mueller)
writes:
>In article <·············@noonian> ···@doe.carleton.ca (David F.
Skoll) writes:
>>who really needs the number 394829348234982435 formatted in English words??
>>Just try (format t "~R~%" 394829348234982435) for fun!
>Well, if i DID need it, I'd hate to write it! Fortran and C versions
>are left as an exercise.
Actually, it wouldn't be too bad in C (if you can ignore the
fixnum/bignum problems :-)) I agree that Lisp has many built-in
conveniences. Maybe too many - we have Allegro Common Lisp on our Sun
network, and the image is 11MB long. That's a huge overhead, and
anyone supporting the full Common Lisp spec probably couldn't do it in
much less.
I like Lisp. I've worked on a large CAD program, and for that, Lisp
was great. But for small-to-medium programs, I find the overhead of
Common Lisp way too high.
--
David F. Skoll
Newsgroups: comp.lang.lisp
From: ···@doe.carleton.ca (David F. Skoll)
Date: Fri, 22 Jan 1993 18:59:41 GMT
>>who really needs the number 394829348234982435 formatted in English words??
>>Just try (format t "~R~%" 394829348234982435) for fun!
Actually, it wouldn't be too bad in C (if you can ignore the
fixnum/bignum problems :-)) I agree that Lisp has many built-in
conveniences. Maybe too many - we have Allegro Common Lisp on our Sun
network, and the image is 11MB long. That's a huge overhead, and
anyone supporting the full Common Lisp spec probably couldn't do it in
much less.
I couldn't just let this one go by. The image for Macintosh Common
Lisp is ~1.5 MB, which includes the programming environment. (I have
no idea why the Allegro image is so big...)
I like Lisp. I've worked on a large CAD program, and for that, Lisp
was great. But for small-to-medium programs, I find the overhead of
Common Lisp way too high.
In article <·············@crusher> ···@doe.carleton.ca (David F. Skoll) writes:
>In <············@tamsun.tamu.edu> ········@orca.tamu.edu (Hal Mueller)
>writes:
>
[things omitted]
>
>I like Lisp. I've worked on a large CAD program, and for that, Lisp
>was great. But for small-to-medium programs, I find the overhead of
>Common Lisp way too high.
>
>--
>David F. Skoll
I like Lisp too, while sometimes i HAVE to resort to C or 68020 asm
for my daily programming. but time passes and i use C less and Lisp
more. I am writing "LIsp" and not "Common Lisp" here because i prefer Scheme.
It is not a mere matter of taste. Scheme is more powerful for building
constructs, due to more powerful continuations, while CL has a much larger
library and a standard Object system. anyway, a lisp language can be used
also for very small projects... MacGambit runs on 2 meg macintoshes, as
well on powerful Quadras, while PC Scheme manages to fit in the ridiculous
less-than-640-k-or-change-os amount of memory of MesSy DOS.
If you need more powerful libraries, just look around . MIT CScheme for
example already has them built-in, with good systems such as Elk or
Gambit having no trouble in growing and growing with the user.
My 2 cents about "Why is not lisp a mainstream language" are as follow.
i) people think lisp <=> AI . it's false we know, but most people think so.
a friend of mine (and and intelligent person) asked me: why do you
use Lisp, AI has failed in its objectives...
ii) people hate parentheses. But still I do not understand why do they not
use forth instead then ...
iii) Lisp has been since recent times a resource hog. now its a false
statement, we have light lisps. but when allegro on a sparc gives you
a 11meg image, well, I believe something is wrong with allegro...
iv) a lack to a good interface to C routines. NOT OS interface, but generic
C code. I mean a STANDARD way. CMUCL, Lucid, Allegro all offer such
facilities but they are incompatible. That's bad.
Cheers
Roberto
From: Jeff Dalton
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <8262@skye.ed.ac.uk>
In article <··········@dei.unipd.it> ·······@sabrina.dei.unipd.it (ROBERTO AVANZI) writes:
>My 2 cents about "Why is not lisp a mainstream language" are as follow.
>i) people think lisp <=> AI . it's false we know, but most people think so.
> a friend of mine (and and intelligent person) asked me: why do you
> use Lisp, AI has failed in its objectives...
I can understand this reason, but I'm not sure what it's really
about. In what way has AI failed, in this view? What did these
people think AI was trying to do? Over-hyped, sure, but what was
the _failure_?
>ii) people hate parentheses. But still I do not understand why do they not
> use forth instead then ...
It's true that many people dislike Lisp syntax. But some people who
dislike it can grow to like it once they see how it "works". It isn't
necessary to pay attention to individual parens when reading
well-indented code, and the editor should take care of the problem
when writing. People who aren't used to well-indented Lisp don't
know the conventions and so can't see what's going on w/o being
distracted by the parens.
>iii) Lisp has been since recent times a resource hog. now its a false
> statement, we have light lisps. but when allegro on a sparc gives you
> a 11meg image, well, I believe something is wrong with allegro...
Something is wrong with a lot of Lisps. I know people who like Lisp
but who don't want to use it because their programs are so much bigger
and slower than if they use C. This is for windows-and-graphics sorts
of things. Lisp started with a huge lead in this area and threw it
away.
>iv) a lack to a good interface to C routines. NOT OS interface, but generic
> C code. I mean a STANDARD way. CMUCL, Lucid, Allegro all offer such
> facilities but they are incompatible. That's bad.
I agree.
-- jeff
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>In article <··········@dei.unipd.it> ·······@sabrina.dei.unipd.it (ROBERTO AVANZI) writes:
>
>>My 2 cents about "Why is not lisp a mainstream language" are as follow.
>>i) people think lisp <=> AI . it's false we know, but most people think so.
>> a friend of mine (and and intelligent person) asked me: why do you
>> use Lisp, AI has failed in its objectives...
>
>I can understand this reason, but I'm not sure what it's really
>about. In what way has AI failed, in this view? What did these
>people think AI was trying to do? Over-hyped, sure, but what was
>the _failure_?
>
Well, while i dont think LISP <=> AI, several people do. I use Scheme even
for numerical analysis on my MacII. It' DIFFERENT from a C* programmed
Connection Machine i have access to, but it does the work much clearer for me.
Probably what takes one hour on the CM will take years on the Lisp environment
but that does show that BOTH are suitable, it depends on the size of your
problem.
A lot of people believe that AI's goal was to produce an Intelligent Machine,
like the two "Hey-they-look-like-goofy-jerks" robots of Star Wars. NO, if
someone DID REALLY want to produce something like that now is probably in
a clinic for the mentally ill. ON the other hand if we want EXPERT SYSTEMS
we have almost reached the object, we have even expert system shells. I have
played with some of them, and they can diagnose some illness. But they are
not a doctor. Eliza is not a TRUE analyst, but some GOOD analysts may be
around in Lisp code. They only are definitely NOT intelligent.
Intelligent machines belong to SF, Useful ones to us. Only the japanese
failed with their fifth generation computers. They got instead useful
applications.
>>ii) people hate parentheses. But still I do not understand why do they not
>> use forth instead then ...
>
>It's true that many people dislike Lisp syntax. But some people who
>dislike it can grow to like it once they see how it "works". It isn't
>necessary to pay attention to individual parens when reading
>well-indented code, and the editor should take care of the problem
>when writing. People who aren't used to well-indented Lisp don't
>know the conventions and so can't see what's going on w/o being
>distracted by the parens.
The same for C. can you read reliably the following
int count(c) int c; {int a=0;for(;a++,c&=~-c;);return a;}
so , what's worse. C can be definitely WORSE evan than assembler (translate
the previous line to asm and you'll believe me !)
good editors can relieve the problem. Emacs is useful in this sense.
>
>>iii) Lisp has been since recent times a resource hog. now its a false
>> statement, we have light lisps. but when allegro on a sparc gives you
>> a 11meg image, well, I believe something is wrong with allegro...
>
>Something is wrong with a lot of Lisps. I know people who like Lisp
>but who don't want to use it because their programs are so much bigger
>and slower than if they use C. This is for windows-and-graphics sorts
>of things. Lisp started with a huge lead in this area and threw it
>away.
>
Right.
>>iv) a lack to a good interface to C routines. NOT OS interface, but generic
>> C code. I mean a STANDARD way. CMUCL, Lucid, Allegro all offer such
>> facilities but they are incompatible. That's bad.
>
>I agree.
>
:-)
>-- jeff
Roberto
In article <·············@crusher>, ···@doe.carleton.ca (David F. Skoll)
wrote:
> Actually, it wouldn't be too bad in C (if you can ignore the
> fixnum/bignum problems :-)) I agree that Lisp has many built-in
> conveniences. Maybe too many - we have Allegro Common Lisp on our Sun
> network, and the image is 11MB long. That's a huge overhead, and
^^^^
> anyone supporting the full Common Lisp spec probably couldn't do it in
> much less.
Ye Gods! And we're complaining about the 2.5MB size of MCL!!!
[Yes, it's full Common Lisp spec.]
this is probably the first cross-post between these two groups :-)
In article <············@tamsun.tamu.edu> ········@orca.tamu.edu (Hal Mueller) writes:
In article <·············@noonian> ···@doe.carleton.ca (David F. Skoll) writes:
>who really needs the number 394829348234982435 formatted in English words??
>Just try (format t "~R~%" 394829348234982435) for fun!
printing cheques from the US gov't to its defence contractors? but that's mostly
in Cobol i suppose... perhaps the mexican gov't... all those pesos...
Well, if i DID need it, I'd hate to write it! Fortran and C versions
are left as an exercise.
(for alt.usage.english readers - lisp's ~R format directive, according to the
draft ANSI standard, will print an integer in one of four formats; english
cardinal (4 -> four), english ordinal (4 -> fourth), "new roman" (4 -> IV),
and "old roman" (4 -> IIII).)
i have a few questions about ~R, some of which are lisp questions, and some
english. if any appreciable discussion ensues, i should probably try to
split the thread (unravel it?) into the two groups. (i'm probably stretching
it even to start the two together.)
- the draft is silent about what to do with nonpositives, especially
for roman numerals. should the english cardinal of -1 be "minus one" or
"negative one"? (i prefer the latter - minus, to me, is the operator
not the additive inverse.) what should happen with the others?
does "zeroth" make sense to anyone other than a thermodynamicist? :-)
- which english style should BIG numbers (such as Mr. Skoll provided)
be written into? i assume, since it's the AMERICAN national standards
institute, they mean the american way - million, billion, trillion,
etc. not the english million, milliard, billion, billiard (?), etc.
or will the standard permit/expect adaption to locale, using milliard
in York and billion in New York? does the usual system locale setup stuff
even handle this kind of information?
- (definitely an alt.usage.english question) what is the progression
for very large numbers? mi-, bi-, tri-, quad-, quint-, sext-, sept-,
oct-, non-, dec-; then what? i remember something like vingintillion
in american for 1000^(20+1)...
i'm not asking idly; i hope to begin giving XLisp bignums, and would
like to provide as much of ~R as i possibly can as well, just 'cause
it's so cute! :-)
(and to Mr. Mueller: i've written such an expander in Basic; it really
isn't so bad. the three-digit cycle helps a lot.)
--
Hume Smith Honour sick and davey cris-cross
··········@acadiau.ca McTruloff sentimie
······@bnr.ca A parsnip inner pair threes.
All right. Not a subject I know all that much about, but it's quite
interesting.
In article <····················@bcars148.bnr.ca> ······@bnr.ca (hume
smith) writes:
- the draft is silent about what to do with nonpositives, especially
for roman numerals.
Should it do anything useful for nonpositive Roman numerals? After
all, the Romans didn't even use nonpositive numerals, so why should
you? There's surely no reasonably Roman representation of zero.
should the english cardinal of -1 be "minus one" or
"negative one"? (i prefer the latter - minus, to me, is the operator
not the additive inverse.)
I usually prefer the former, because presumably the intention is to
produce text that is smoothly readable to people without scientific
backgrounds. `Negative one' reads like a scientific term; `minus one'
reads like English. Yes, of course, you can then run into problems
with mixing `minus' as unary and binary operators, but if you want
clarity and consistency above everything, you shouldn't be trying to
write in English.
- which english style should BIG numbers (such as Mr. Skoll provided)
be written into? i assume, since it's the AMERICAN national standards
institute, they mean the american way - million, billion, trillion,
etc. not the english million, milliard, billion, billiard (?), etc.
I think most British are probably just as familiar these days with the
American numbering as with the British, but I don't think it's safe to
use either with British English speakers unless you're quite clear
about which you're using.
or will the standard permit/expect adaption to locale, using milliard
in York and billion in New York?
Things could get a bit confusing this way, but of course if it's
cuteness value you're after, well, why not?
does the usual system locale setup stuff
even handle this kind of information?
I very much doubt it.
(and to Mr. Mueller: i've written such an expander in Basic; it really
isn't so bad. the three-digit cycle helps a lot.)
Anyone remember `Lords of Midnight' (and its sequel), the computer
games that formatted numbers in a sort of antique style: Two hundred,
four score and ten brave warriors have boldly snuffed it, etc.?
Chris
--
on sighting mathematicians it should unhook the algebra from their
minds and replace it with poetry; on sighting poets it should
unhook poetry from their minds and replace it with algebra
······@bnr.ca (hume smith) writes:
> - which english style should BIG numbers (such as Mr. Skoll provided)
> be written into? i assume, since it's the AMERICAN national standards
> institute, they mean the american way - million, billion, trillion,
> etc. not the english million, milliard, billion, billiard (?), etc.
> or will the standard permit/expect adaption to locale, using milliard
> in York and billion in New York? does the usual system locale setup stuff
> even handle this kind of information?
You have a problem even before you get to particularly big numbers.
Here on the right-hand side of the Atlantic, the number 110 is called
"one hundred and ten", whereas Americans omit the "and". I've no idea
if this omission is universal in the US, or whether the "and" form
sounds as grating to US ears as does the "and"-less form to mine.
The rules for "and"-insertion are not completely straightforward. For
instance, 1,234,001 is "one million, two hundred and thirty-four
thousand and one". I think "and" has to be inserted between
power-of-ten words and less-than-one-hundred words.
,
Eamonn
In article <·····@kaa.gr.osf.org> ········@gr.osf.org (Eamonn McManus) writes:
Here on the right-hand side of the Atlantic, the number 110 is called
"one hundred and ten", whereas Americans omit the "and". I've no idea
if this omission is universal in the US, or whether the "and" form
sounds as grating to US ears as does the "and"-less form to mine.
Aha! So I found a Briticism in LispWorks when it printed out "one
hundred and ten"! Harlequin didn't fall for the "billion" trap,
though--it drops into numerics, as CLtL2 suggests.
Seriously, "one hundred and ten" simply sounds less formal than "one
hundred ten" (to my American ears). Disney's movie "101 Dalmatians"
is typically pronounced with an "and"; in fact, I typically say "A
hundred and one Dalmatians," which is even less formal. And by the
way, mathematically trained people often say "one oh one" anyway. On
a check, though, I would indeed write "one hundred ten."
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
In article <·················@cbnewsc.ATT.COM>, ···@cbnewsc.ATT.COM
(lawrence.g.mayka) wrote:
>
> In article <·····@kaa.gr.osf.org> ········@gr.osf.org (Eamonn McManus) writes:
>
> Here on the right-hand side of the Atlantic, the number 110 is called
> "one hundred and ten", whereas Americans omit the "and". I've no idea
> if this omission is universal in the US, or whether the "and" form
> sounds as grating to US ears as does the "and"-less form to mine.
>
> Aha! So I found a Briticism in LispWorks when it printed out "one
> hundred and ten"! Harlequin didn't fall for the "billion" trap,
> though--it drops into numerics, as CLtL2 suggests.
>
> Seriously, "one hundred and ten" simply sounds less formal than "one
> hundred ten" (to my American ears). Disney's movie "101 Dalmatians"
> is typically pronounced with an "and"; in fact, I typically say "A
> hundred and one Dalmatians," which is even less formal. And by the
> way, mathematically trained people often say "one oh one" anyway. On
> a check, though, I would indeed write "one hundred ten."
An American math teacher once chewed me out for saying something like one
oh one, claiming that she couldn't possibly get her math-deficient students
to read numbers properly if nobody else did. While ranting, she stated
that and was spoken for and only for the decimal point.
ie, One hundred ten AND fifty-seven cents <==> 110.57
I have no idea if this is supported by any official source, thoug.
--
--
-- "TANSTAAFL" Rich ·····@ils.nwu.edu
In article <··················@lynch.ils.nwu.edu> ·····@ils.nwu.edu (Richard Lynch) writes:
An American math teacher once chewed me out for saying something like one
oh one, claiming that she couldn't possibly get her math-deficient students
to read numbers properly if nobody else did. While ranting, she stated
that and was spoken for and only for the decimal point.
ie, One hundred ten AND fifty-seven cents <==> 110.57
I have no idea if this is supported by any official source, thoug.
well that's what i was taught as well. and == decimal point. it got
a little fogged at point as to how the stuff after the decimal should
be read.
getting so worked up over its exact usage is pretty uptight though.
i had another teacher that insisted we should write the decimal
point halfway-up - like a zero-dimension hyphen or the top half of
a colon. i think it's often done that way on the east side of the
atlantic - she was english herself, in any case. if she'd've
been french, we probably would've have to use a comma. the point
being - that was the little quirk she tried to induce. sometimes
ya gotta wonder how much is really "real" and how much is just
the teacher's egotism.
anyway...
--
Hume Smith Honour sick and davey cris-cross
··········@acadiau.ca McTruloff sentimie
······@bnr.ca A parsnip inner pair threes.
In article <···················@bcars148.bnr.ca> ······@bnr.ca (hume smith) writes:
> An American math teacher once chewed me out for saying something like one
> oh one, claiming that she couldn't possibly get her math-deficient students
> to read numbers properly if nobody else did. While ranting, she stated
> that and was spoken for and only for the decimal point.
>
> ie, One hundred ten AND fifty-seven cents <==> 110.57
I had to read the last sentence in the first paragraph about ten times
before I got the sense of it. I have certainly never heard of that usage.
For twnty years our government tried to persuade us to say that as
"One hundred and ten comma fifty-seven"
Now at last they have seen the light, and say it's OK to say it
"One hundred and ten point fifty-seven"
But "and" for the decimal point is altogether new to me.
============================================================
Steve Hayes, Department of Missiology & Editorial Department
Univ. of South Africa, P.O. Box 392, Pretoria, 0001 South Africa
Internet: ········@risc1.unisa.ac.za
···········@p5.f22.n7101.z5.fidonet.org
·············@f20.n7101.z5.fidonet.org
In article <··················@lynch.ils.nwu.edu> ·····@ils.nwu.edu (Richard Lynch) writes:
>
> An American math teacher once chewed me out for saying something like one
> oh one, claiming that she couldn't possibly get her math-deficient students
> to read numbers properly if nobody else did. While ranting, she stated
> that and was spoken for and only for the decimal point.
>
> ie, One hundred ten AND fifty-seven cents <==> 110.57
>
> I have no idea if this is supported by any official source, thoug.
Hmm, I don't think that agrees with my (American) intuitions. The
only time I would use "and" like that with money (and even there it's
optional) is when both "dollars" and "cents" are mentioned:
A hundred ten dollars (and) fifty-seven cents.
Even there, I'd be likely to omit it. In normal conversation, if
everyone knew we were talking about money, both units would be dropped:
One ten fifty-seven
unless an ambiguity would result (as in $100.57) which would either be
A hundred dollars (and) fifty-seven cents
or
One hundred [pause] fifty-seven.
The latter would probably only be used if reading off a list of
amounts (my dad is an accountant, we did that a lot). In that case,
you knew that the last number represented the cents: fewer than ten
cents were pronounced "oh <digit>" ("one thirty two oh five"), and an
even dollar ammount was pronounced "even" ("fourteen fifty one even").
In domains other than currency, there are a couple of ways of
proceeding. The decimal point can be pronounced "point" followed by
either "<digit> <digit> ..." ("fourteen point three seven five") or
(more informally) "<number>" ("fourteen point three seventy-five").
Alternatively, when the range and accuracy is assumed, the word
"point" can be omitted, and what follows is pronounced as a number.
("fourteen three seventy-five"). Currency would seem to be a special
case of this last form.
Followups to alt.usage.english, as this doesn't seem to have much to
do with lisp.
Evan Kirshenbaum +------------------------------------
HP Laboratories | K: Natives. They may be hostile
3500 Deer Creek Road, Building 26U | C: Well, we're all a little hostile
Palo Alto, CA 94304 | now and then. Some of us are able
| to sublimate. Others just can't
···········@hpl.hp.com | adjust.
(415)857-7572
From: Erann Gat
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1jpi0sINN47q@elroy.jpl.nasa.gov>
In article <·············@noonian> ···@doe.carleton.ca (David F. Skoll) writes:
>I've noticed a thread extolling the beauty of Lisp syntax. While I agree
>that mostly, Lisp syntax is easy to understand and consistent, I wonder
>what sort of mental disease struck the creators for the "format" function.
>Take a look at all the baroque format directives in Common Lisp. I mean,
>who really needs the number 394829348234982435 formatted in English words??
Someone writing a program to print checks might find ~R to be quite
useful. (You seem to be complaining about two orthogonal issues, by
the way, the syntax of format strings and their functionality. The
syntax I will concede is not a model of clarity, but it is not represent-
ative of the rest of the language.)
Erann Gat
···@aig.jpl.nasa.gov
From: David F. Skoll
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <dfs.727732459@kehleyr>
In <············@elroy.jpl.nasa.gov> ···@forsight2.jpl.nasa.gov (Erann
Gat) writes:
>(You seem to be complaining about two orthogonal issues, by
>the way, the syntax of format strings and their functionality.
You are right. I wrote my article hastily. But the "format" function
is representative of one aspect of Common Lisp which I believe
prevents it from becoming a "mainstream" language - Common Lisp
attempts to do almost everything, with the result that 90% of the Lisp
image is devoted to functions a small-to-medium program will never use.
And people have been arguing that Lisp is a very good general
purpose language. A function that prints English names of numbers
is a pretty special-purpose function!
--
David F. Skoll
From: hume smith
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <EMCOOP.93Jan22161006@bcars148.bnr.ca>
In article <·············@kehleyr> ···@doe.carleton.ca (David F. Skoll) writes:
And people have been arguing that Lisp is a very good general
purpose language. A function that prints English names of numbers
is a pretty special-purpose function!
hmm... what makes a general purpose language? does providing lots of special
functions have anything to with it?
i think you can turn the argument around (classic usenet fashion) and say
that functions that only print numbers in digits is pretty special purpose
too. especially, functions that read and write floating point in base ten
only (my personal beef - there's no reason it can't be done in other bases!).
i think it's a nice little bonus feature. when do you ever use most of the
functions in the UNIX C libraries? isn't it handy the one time in a hundred
you need them - you can keep on truckin' instead of trying to figure out how
to patch around the hole?
--
Hume Smith Honour sick and davey cris-cross
··········@acadiau.ca McTruloff sentimie
······@bnr.ca A parsnip inner pair threes.
From: David F. Skoll
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <dfs.727757157@kehleyr>
In <····················@bcars148.bnr.ca> ······@bnr.ca (hume smith) writes:
>hmm... what makes a general purpose language? does providing lots of special
>functions have anything to with it?
Providing lots of special-purpose functions which cannot be removed at
run-time is bad news. I have no problems with lots of special-purpose
functions, but you shouldn't be forced to have them all, whether you
need them or not. The CL standard makes no provisions for excluding
some functions from a run-time environment. I'd bet that most
CL implementations can't be made much smaller than their full
(bloated) size.
>i think you can turn the argument around (classic usenet fashion) and say
>that functions that only print numbers in digits is pretty special purpose
>too. especially, functions that read and write floating point in base ten
>only (my personal beef - there's no reason it can't be done in other bases!).
There's a difference - how many programs have you written which
require numbers to be printed in base 10? In English? We're not
talking philosophical abstractions here - we're talking real-world
use.
>i think it's a nice little bonus feature. when do you ever use most of the
>functions in the UNIX C libraries? isn't it handy the one time in a hundred
>you need them - you can keep on truckin' instead of trying to figure out how
>to patch around the hole?
Absolutely. But if you don't want to use a certain C function, you don't
link it in. Your programs have no overhead for unused functionality.
If Common Lisp had some mechanism for this, then my criticism would not
be valid.
--
David F. Skoll
From: Jeff Dalton
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <8268@skye.ed.ac.uk>
In article <·············@kehleyr> ···@doe.carleton.ca (David F. Skoll) writes:
>Providing lots of special-purpose functions which cannot be removed at
>run-time is bad news. I have no problems with lots of special-purpose
>functions, but you shouldn't be forced to have them all, whether you
>need them or not. The CL standard makes no provisions for excluding
>some functions from a run-time environment.
But why does the _standard_ (or other language definition) have to
do this?
>Absolutely. But if you don't want to use a certain C function, you don't
>link it in. Your programs have no overhead for unused functionality.
>If Common Lisp had some mechanism for this, then my criticism would not
>be valid.
The C language has no mechanism for this. It's the linkers that do
it.
So, the right question is: is there something about the language
that rules out implementation strategies that omit unneeded code?
And the answer is "yes". Almost anything could be called, eg by
(apply (read) (read))
So implementation either have to provide a way for the user to
say that only the functions that are directly called will be
called or else provide a way to load in functions when needed.
The latter approach has been around for a long time in the
form of "autoloading".
However, such tricks won't work very well if programs tend to
require most of CL, perhaps because CL is so intertwined. This
is a standard criticism of CL. ERROR requires FORMAT, etc.
But how true is it? Well, I think there's evidence that it's
sufficiently true to be a problem. On the other hand, why
should it be fatal. What if, for instance, CL is packaged as
a shared library (as in WCL)? It's a fairly big shared library,
but then so is X.
-- jd
From: Espen J. Vestre
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1k6ct9INNsal@coli-gate.coli.uni-sb.de>
In article <····@skye.ed.ac.uk> Jeff Dalton, ····@aiai.ed.ac.uk writes:
>should it be fatal. What if, for instance, CL is packaged as
>a shared library (as in WCL)? It's a fairly big shared library,
>but then so is X.
...on Decstations X isn't even a shared library, which makes xclock half
a megabyte big :-)
(forgive me, decfriends, if things are better now than the last time I
used a Decstation!)
--------------------------------------------------------------
Espen J. Vestre, ·····@coli.uni-sb.de
Universitaet des Saarlandes,
Computerlinguistik, Gebaeude 17.2
Im Stadtwald, tel. +49 (681) 302 4501
D-6600 SAARBRUECKEN, Germany fax. +49 (681) 302 4351
--------------------------------------------------------------
A modern fairy tale:
Once upon a time I used to use macro-processors like GPM and UNIX's
m4. I used to generate test scripts for testing X.25 and
Z80 assembler with them. These are good tools for creating ad-hoc
mini-languages.
Then somebody suggested I look at the Lisp syntax, because
is was just as adaptable (read feature-less) as m4. I did
and was immediately hooked, because Lisp has structure, unlike
macro-processors.
Since then I have used Lisp syntax to create mini-languages for a variety of
purposes including: An assembler for Finite-state machines for
a PABX configuration; for storing interactive video overlay sequences;
a language for specifying call-processing state tables; and etc...
All these have been serious industrial applications.
I particularly like being able to parse mini-langauages in a single
statement: READ. I prefer it to FORTH syntax which I did experiment
with in a protocol testing language. The structure is more obvious
in Lisp.
So as far as I am concerned, the Lisp syntax is absolutely vital, it
is what attracted me to the langauage in the first place. But
then my use of languages is driven by real need rather than by
the impositions of University lecturers :-)
[I enjoyed that!]
Bill
--
Bill Birch | ·······@uk03.bull.co.uk
Bull Info. Sys. Ltd. | Bull Tel: 773 4770
Maxted Road, | Bull Mail: HM14 UK03
Hemel Hempstead, | Tel: +44 442 884770
HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
Aviate, Navigate, Communicate...
From: Harley Davis
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <DAVIS.93Jan28185347@passy.ilog.fr>
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>Absolutely. But if you don't want to use a certain C function, you don't
>link it in. Your programs have no overhead for unused functionality.
>If Common Lisp had some mechanism for this, then my criticism would not
>be valid.
The C language has no mechanism for this. It's the linkers that do
it.
So, the right question is: is there something about the language
that rules out implementation strategies that omit unneeded code?
And the answer is "yes". Almost anything could be called, eg by
(apply (read) (read))
So implementation either have to provide a way for the user to
say that only the functions that are directly called will be
called or else provide a way to load in functions when needed.
The latter approach has been around for a long time in the
form of "autoloading".
However, such tricks won't work very well if programs tend to
require most of CL, perhaps because CL is so intertwined. This
is a standard criticism of CL. ERROR requires FORMAT, etc.
But how true is it? Well, I think there's evidence that it's
sufficiently true to be a problem. On the other hand, why
should it be fatal. What if, for instance, CL is packaged as
a shared library (as in WCL)? It's a fairly big shared library,
but then so is X.
The problem is somewhat more complex. Another difference between Lisp
and C is that Lisp allows the creation of rather complex data at the
top-level. These data objects range from symbols to functions to data
structures stored in global variables to classes, etc. Although
shared libraries help a lot in managing code size, they do not reduce
data requirements. Even modules which have completely unexecuted code
still need to initialize their data; at a minimum, their symbols and
most likely a number of functional objects as well. There may be ways
to put off the creation of other top-level data until the module is
needed, but this requires rather complex management which has its own
cost. All this said, shared libraries are still winning. However, it
would probably be a mistake to provide *all* of Lisp as one shared
library.
I should note that C++ also has this problem to some extent since it
allows top-level data initialization and needs to initialize its
virtual function tables and other class-related hidden objects. In
fact, I don't think many C++ compilers allow the creation of shared
libraries. For example, Sun C++ has no position independent code
generation option. This may be seen as one of the biggest changes
between C and C++, and has many ominous overtones that most of C++'s
advocates don't yet understand.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
In article <···················@passy.ilog.fr> ·····@passy.ilog.fr (Harley Davis) writes:
>
>In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>
> What if, for instance, CL is packaged as
> a shared library (as in WCL)? It's a fairly big shared library,
> but then so is X.
>
>The problem is somewhat more complex. Another difference between Lisp
>and C is that Lisp allows the creation of rather complex data at the
>top-level. These data objects range from symbols to functions to data
>structures stored in global variables to classes, etc. Although
>shared libraries help a lot in managing code size, they do not reduce
>data requirements. Even modules which have completely unexecuted code
>still need to initialize their data; at a minimum, their symbols and
>most likely a number of functional objects as well. There may be ways
>to put off the creation of other top-level data until the module is
>needed, but this requires rather complex management which has its own
>cost. All this said, shared libraries are still winning. However, it
>would probably be a mistake to provide *all* of Lisp as one shared
>library.
>
>I should note that C++ also has this problem to some extent since it
>allows top-level data initialization and needs to initialize its
>virtual function tables and other class-related hidden objects. In
>fact, I don't think many C++ compilers allow the creation of shared
>libraries. For example, Sun C++ has no position independent code
>generation option. This may be seen as one of the biggest changes
>between C and C++, and has many ominous overtones that most of C++'s
>advocates don't yet understand.
>
>-- Harley Davis
You're right that initialized data can be a problem with shared
libraries. However, initializing shared data quickly is mostly a
matter of how shared libraries are implemented. For example, SunOS 4.X
implements a very simplistic (read slow) form of shared libraries.
Under SunOS, shared libs consist of position-independent code (PIC)
which is intended to run at an arbitrary location in the address
space of any process. This means that both code and data must be relocated
(= linked) at runtime. Code references are incrementally relocated,
and thus you only spend time relocating references your particular
application is going to use. However, data references must *all* be
relocated before the shared library can be used. Not only is this
unnecessary, it's really slow and easier to implement. The net result
is that a Lisp system like WCL, which puts all of CL into a shared
library, can produce very small executables ("Hello World!" is 41k),
but it takes about a second to run the executable because of all
the data relocations.
There are two ways to fix this problem. One is to perform data
relocations incrementally. I don't think that this is too difficult,
assuming you have a virtual memory system that supports copy on write
and fast fault handling for no access pages. An even better way
is to support what I think MIPS RiscOS called "fast start" libraries.
The idea is to link each shared library at a unique address that
doesn't collide with other shared libraries (this can be
determined statically or dynamically as your system is running). This
allows the equivalent of static linking, and thus you don't have any
of the problems exhibited by SunOS 4.X. -wade
From: k p c
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <KPC.93Jan22142048@zog.arc.nasa.gov>
there are technical solutions to that problem, aren't there? i recall
there being something called presto that would eliminate parts of lisp
that weren't being used.
--
i'm open to comparing research career notes with other cogsci/cogneuro people.
From: David F. Skoll
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <dfs.727757443@kehleyr>
In <·················@zog.arc.nasa.gov> ···@pluto.arc.nasa.gov (k p c) writes:
>there are technical solutions to that problem, aren't there? i recall
>there being something called presto that would eliminate parts of lisp
>that weren't being used.
Two problems - it's a bit of a "kludge" - for best performance, you
have to "train" presto to recognize which parts should be loaded and
which shouldn't. That's a bit tedious and adds nothing to your
productivity. Secondly, it's not part of the CL standard, so if you
port your software to another implementation, there's no guarantee
that it will have presto.
--
David F. Skoll
From: Erann Gat
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1jqgecINNjbf@elroy.jpl.nasa.gov>
In article <·············@kehleyr> ···@doe.carleton.ca (David F. Skoll) writes:
>In <············@elroy.jpl.nasa.gov> ···@forsight2.jpl.nasa.gov (Erann
>Gat) writes:
>
>>(You seem to be complaining about two orthogonal issues, by
>>the way, the syntax of format strings and their functionality.
>
>You are right. I wrote my article hastily. But the "format" function
>is representative of one aspect of Common Lisp which I believe
>prevents it from becoming a "mainstream" language - Common Lisp
>attempts to do almost everything, with the result that 90% of the Lisp
>image is devoted to functions a small-to-medium program will never use.
>
>And people have been arguing that Lisp is a very good general
>purpose language. A function that prints English names of numbers
>is a pretty special-purpose function!
There is an ongoing discussion on comp.lang.lisp.mcl which might be of
interest to followers of this thread. The discussion centers on the issue
of how to produce small applications using Lisp. The suggestion has been
made that Common Lisp should be considered an operating system and not
an application. In that case, having a zillion obscure functions is no
more unreasonable than having a large C library. (BTW - MCL (Macintosh
Common Lisp) implements all of CLTL2 and is 1.5 Megabytes, about a tenth
the size of Allegro.)
Erann Gat
···@aig.jpl.nasa.gov
In article <············@elroy.jpl.nasa.gov> ···@forsight2.jpl.nasa.gov (Erann Gat) writes:
There is an ongoing discussion on comp.lang.lisp.mcl which might be of
interest to followers of this thread. The discussion centers on the issue
of how to produce small applications using Lisp. The suggestion has been
made that Common Lisp should be considered an operating system and not
an application. In that case, having a zillion obscure functions is no
more unreasonable than having a large C library. (BTW - MCL (Macintosh
Common Lisp) implements all of CLTL2 and is 1.5 Megabytes, about a tenth
the size of Allegro.)
Actually, the true beauty of the suggestion was the part where you
take the entire Lisp application, call it an extension (apologies to
the non-Mac-fluent) and have people drop it in the System Folder.
After all, it isn't much bigger than Quicktime. Then you disguise the
fasl files as "applications" and sit back while everyone marvels at
the compact-but-powerful programs! And they can inter-operate, too!
> You are right. I wrote my article hastily. But the "format" function is
> representative of one aspect of Common Lisp which I believe prevents it from
> becoming a "mainstream" language - Common Lisp attempts to do almost
> everything, with the result that 90% of the Lisp image is devoted to
> functions a small-to-medium program will never use.
It seems to me that if you mentally think of the language spec as what in
other languages would be "language + standard libraries," things make much
more sense. The fact that LISP systems are based on run-time environments and
REPL modes makes it hard to provide a good seperation between the two, and in
any case from a language definition point of view there's no diffference
(unless you want things to be optional, the way scheme does).
Bruce
From: David F. Skoll
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <dfs.727981585@kehleyr>
In <······················@zowie.ils.nwu.edu>
········@zowie.ils.nwu.edu (Bruce Krulwich) writes:
>It seems to me that if you mentally think of the language spec as what
>in other languages would be "language + standard libraries," things
>make much more sense. The fact that LISP systems are based on
>run-time environments and REPL modes makes it hard to provide a good
>seperation between the two, and in any case from a language definition
>point of view there's no diffference (unless you want things to be
>optional, the way scheme does).
I think the paragraph above sums up nicely why Lisp is not a
mainstream language. Having to "think" of it as something else is not
something most programmers want to do. They want a language that's
portable, small, standard and cheap. Common Lisp programs are (in
theory) quite portable, but in practice are no more portable than C
programs. Common Lisp is not small, so it's not that good for small
applications. And Lisp is not cheap - if you want to distribute Lisp
applications, you usually have to pay $$$ to the Lisp vendor to
distribute Lisp run-time licenses. Also, the good Common Lisp
compilers are not free - are quite expensive, in fact. Compare this
to C, for example, which has no run-time royalties, and has a free
ANSI-standard compiler.
Another problem is that Lisp enthusiasts are not that good at
marketing Lisp. :-) When you tell people "well, think of this as..."
they switch off. :-)
--
David F. Skoll
In article <·············@kehleyr>, ···@doe.carleton.ca (David F. Skoll) writes:
|> And Lisp is not cheap - if you want to distribute Lisp
|> applications, you usually have to pay $$$ to the Lisp vendor to
|> distribute Lisp run-time licenses. Also, the good Common Lisp
|> compilers are not free - are quite expensive, in fact.
It depends on what you think is "quite expensive".
I wouldn't call $7500 outrageously expensive,
considering what you get. Compared to payroll
and hardware costs, it's negligible.
|> Compare this
|> to C, for example, which has no run-time royalties, and has a free
|> ANSI-standard compiler.
The run-time is a difference, but Franz will charge
you a one-time fee of $2500 for all the run-times
you want ($5000 if you're going to sell them.)
Again, not a whole lot of money.
Of course, it depends on your environment. I can
pay back the cost of a two-person-year project
including hardware and software by preventing
*one* mistake.
And fine, you can get a free C compiler. How much are
you going to pay for a development environment to match
what your $7500 for Lisp includes?
--
Greg Parkinson Phone: 212-657-7814 Fax: 212-825-8607
Citibank,111 Wall Street E-Mail: ···@fig.citib.com
New York, New York 10043
The opinions expressed are my own and not those of the big 'ol bank.
From: Jeff Dalton
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <8283@skye.ed.ac.uk>
In article <·············@kehleyr> ···@doe.carleton.ca (David F. Skoll) writes:
>In <······················@zowie.ils.nwu.edu>
>········@zowie.ils.nwu.edu (Bruce Krulwich) writes:
>
>
>>It seems to me that if you mentally think of the language spec as what
>>in other languages would be "language + standard libraries," things
>>make much more sense. The fact that LISP systems are based on
>>run-time environments and REPL modes makes it hard to provide a good
>>seperation between the two, and in any case from a language definition
>>point of view there's no diffference (unless you want things to be
>>optional, the way scheme does).
>
>I think the paragraph above sums up nicely why Lisp is not a
>mainstream language. Having to "think" of it as something else is not
>something most programmers want to do.
Let me get this straight. They know the "truth" about Lisp but don't
want to have to think of it some other way? Suppose we define it as
a language + libraries (as EuLisp does). Would that make any
difference?
>They want a language that's portable, small, standard and cheap.
Scheme.
>Common Lisp programs are (in theory) quite portable, but in practice
>are no more portable than C programs.
They're more portable in some ways, less in others. For instance, I
have no trouble porting my CL programs from one machine/OS to another.
I have more trouble going from one CL implementation to another.
One thing CL lacks is a standard (or de facto standard) for object
files and libraries, as C does.
> Common Lisp is not small, so it's not that good for small
>applications.
Depends, but it's usually so.
> And Lisp is not cheap - if you want to distribute Lisp
>applications, you usually have to pay $$$ to the Lisp vendor to
>distribute Lisp run-time licenses.
Most of the Lisps I use are free. That's right: zero $$$.
>Also, the good Common Lisp compilers are not free - are quite expensive,
>in fact.
Not so! CMU CL has an excellent compiler.
>Compare this to C, for example, which has no run-time royalties, and
>has a free ANSI-standard compiler.
Ok, I compare it, and I find that CL has the same. As does Scheme.
>Another problem is that Lisp enthusiasts are not that good at
>marketing Lisp. :-) When you tell people "well, think of this as..."
>they switch off. :-)
No doubt because their minds are soooo.... open!
-- jd
In <·············@noonian> ···@doe.carleton.ca (David F. Skoll) writes:
>I've noticed a thread extolling the beauty of Lisp syntax. While I agree
>that mostly, Lisp syntax is easy to understand and consistent, I wonder
>what sort of mental disease struck the creators for the "format" function.
>Take a look at all the baroque format directives in Common Lisp. I mean,
>who really needs the number 394829348234982435 formatted in English words??
>Just try (format t "~R~%" 394829348234982435) for fun!
Well, it is fun. But from this corner of the world I suppose that it is
a more serious problem (if not a disaster) that Common Lisp provides
input and output functions that are suited only for English/American.
(format t "~R" 4) -> four really doesn't help very much in most of the world.
And yes-or-no-p cannot be used either.
I do think it is a mistake to include natural language specific functions
in a language standard.
Flemming
From: Fernando Mato Mira
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1993Jan26.190959@di.epfl.ch>
In article <·········@stl.dk>, ···@stl.dk (Flemming Vestergaard) writes:
>
> Well, it is fun. But from this corner of the world I suppose that it is
> a more serious problem (if not a disaster) that Common Lisp provides
> input and output functions that are suited only for English/American.
>
> (format t "~R" 4) -> four really doesn't help very much in most of the world.
> And yes-or-no-p cannot be used either.
>
> I do think it is a mistake to include natural language specific functions
> in a language standard.
Maybe some hooks should be provided to internationalize these functions. Then if
somebody needs to print checks in Spanish they can write their own routine to handle the ~R directive.
But even if the standard specifies the behaviour only for english, I think that thinking only "american" with respect to
the "billion thing" is quite irritating.
For yes-or-no-p it would be very easy (and extremely useful) to specify in the standard some system variables which you
could modify to hold the string appropriate for the local language.
And yes, I think CL is "a nice PL/1". And in the same way everybody around here seems to want everybody else to program in
LISP, I will be happy only when most LISPers program in SCHEME (with a good MOP, of course). Then I could get a lot of
public domain tools for it and abandon CL. If C++ is the black hole of OO programming, I must say that CL is the neutron star of list
processing.
--
Fernando D. Mato Mira
Computer Graphics Lab "Only CLOS is good enough"
Swiss Federal Institute of Technology ^^^^^^
········@di.epfl.ch
NeXTMail : ········@lignext.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed-point-disclaimer(H,DH),
disclaim(T,DT).
fixed-point-disclaimer(Text,fixed-point-disclaimer(Text,_)).
;;; Maybe some hooks should be provided to internationalize these
;;; functions. Then if somebody needs to print checks in Spanish they can
;;; write their own routine to ha ndle the ~R directive. But even if the
;;; standard specifies the behaviour only for english, I think that
;;; thinking only "american" with respect to the "billion thing" is quite
;;; irritating. For yes-or-no-p it would be very easy (and extremely
;;; useful) to specify in the s tandard some system variables which you
;;; could modify to hold the string appropriate for the local language.
Actually, yes-or-no-p would be very hard to internationalize correctly. There
exist languages with no direct translations of the English "Yes" and "No," and
languages where the semmantics of "Yes" and "No" are quite different for
questions posed in the negative. Examples are Welsh (with no direct 1-to-1
translation for either 'Yes' or 'No'), Japanese (where the semmantics of saying
'Yes' to a negative question are different than those of English), and French
(where a 3rd word is added for disambiguating answers to questions in the
negative)
As for format's ~R, it could be internationalized, but personally I'd rather
see format dropped from the CL specification and replaced with several
functions, maybe one for the actual output and others that do formatting.
The current format defies most conventional tree-shaking algorithms. This
wouldn't be so bad if it weren't so mammoth to begin with... IMHO, of course.
I don't want to get rid of ~R, just make it its own function.
;;; And yes, I think CL is "a nice PL/1". And in the same way everybody
;;; around here seems to want everybody else to program in LISP, I will be
;;; happy only when most LISPers program in SCHEME (with a good MOP,
;;; of course). Then I could get a lot of public domain tools for it and
;;; abandon CL. If C++ is the black hole of OO programming, I must say
;;; that CL is the neutron star of list processing.
I agree that CL/CLOS/CLIM is probably too big to run as anything other than
an OS, and the design really isn't that compiler friendly. A nice, small,
OO lisp (maybe Scheme + OO or Dylan) with _libraries_ would be much more
practical.
And before everyone starts shouting that I want to remove all dynamicism from
Lisp let me assure you: I only want to remove that dynamicism that isn't
necessary for the semmantics of a given program. The compiler technology
exists for this kind of thing, but the language spec needs to be more compiler
friendly if we're ever going to see compact binaries coming from Lisp source.
-- Scot
From: Fernando Mato Mira
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1993Jan29.100744@di.epfl.ch>
In article <·····················@sharebase.com>, ····@airplane.sharebase.com (Scot Dyer) writes:
>
> Actually, yes-or-no-p would be very hard to internationalize correctly. There
> exist languages with no direct translations of the English "Yes" and "No," and
> languages where the semmantics of "Yes" and "No" are quite different for
> questions posed in the negative. Examples are Welsh (with no direct 1-to-1
> translation for either 'Yes' or 'No'), Japanese (where the semmantics of saying
> 'Yes' to a negative question are different than those of English), and French
> (where a 3rd word is added for disambiguating answers to questions in the
> negative)
>
Nihon-go no problem o wasuremashita. Keredomo...
An optional argument to yes-or-no-p to tell when a question is posed in the
negative and a system variable for indicating the semantics of double negation
would be the least expensive non-NL processing fix for the first kind of problem.
Having a list of yes and no strings ("OUI SI") ("NON") plus accounting french as
as "ilogic" language with respect to double negation would fix the problem for
french (and would work better with foreign people living in french-speaking
countries that might occassionally say "oui" instead of "si". For spanish
speakers, they might also make some faults in the positive question case).
But a language standard is supposed to be clean and complicated, so having four lists
would provide a "safe" solution and defining yet another system variable for
"forgiveness" would be practical in non-life-or-death consumer applications
(there are a lot of Spanish people living in Switzerland, for example, but they
are leaving... Now, just say NO to EEE... *sigh*).
How about Welsh, could you give some examples (with translation)? Would another argument to reverse semantics work? This is getting
complicated...
--
Fernando D. Mato Mira
Computer Graphics Lab "Only CLOS is good enough"
Swiss Federal Institute of Technology
········@di.epfl.ch
NeXTMail : ········@lignext.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed-point-disclaimer(H,DH),
disclaim(T,DT).
fixed-point-disclaimer(Text,fixed-point-disclaimer(Text,_)).
Meta-disclaimer:
This is not PROLOG. It is syntactic sugar for a theorem prover written in LISP.
From: ········@di.epfl.ch (Fernando Mato Mira)
;;; How about Welsh, could you give some examples (with translation)? Would
;;; another argument to reverse semantics work? This is getting complicated...
In Welsh, the response 'Yes' or 'No' is completely dependent on the verbal
structure of the question. For example:
Mae Tom yma? Ydy.
Is Tom here? Yes-he-is.
or... Nag ydy.
No-he-isn't.
Oes caws yn y gegin? Oes.
Is there cheese in the kitchen? Yes-there-is.
or... Does ddim.
No-there-isn't.
Really what's happening (and I _am_ trying to be brief :)) is a result of
having a great deal of inflection in the verb (for person, number, etc.) so
that a single (verb) used in response is the answer. (like Yes-he-is and
No-there-isn't)
And there are definitely too many verbs in Welsh to enumerate the possible
'yes's and 'no's. Maybe if you parsed the string argument to yes-or-no-p?
( ;) I think this is unrealistic. )
Perhaps...
(ask-answer-in-p prompt-string list-of-true-values)
...with list-of-true-values being provided in some global, like *-yeses-* and
*-nos-*, would allow the inclusion of Welsh (by the programmer enumerating
the list-of-true-values)
I don't think this is really all that important, though. As much as I want to
see Welsh live on, yes-or-no-p has another portability problem -- the string.
The code has to be changed anyway, and ask-answer-in-p has the same problem.
I'm sure that even this will exclude some language I don't happen to speak.
Writing international code is a fairly new concern, and I don't think the
field really has the _linguistic_ maturity it would need to avoid it. And I
certainly can't claim to know enough about world language to propose an
all-encompassing answer.
+------------------------+-----------------------------------------------+
|Scot Dyer_Rivenburgh | "Land of song," said the warrior bard, |
·····@eagle.sharebase.com| "Though all the world betrays thee, |
+------------------------+ One sword, at least, thy rights shall guard, |
|(He's right, you know.) | One faithful harp shall praise thee." |
+------------------------+-----------------------------------------------+
Symbolics had a FQUERY function which allowed one to specify the
yes/no strings and results. Why didn't something like this make it
into the standard? It seems like it would be easy enough to implement.
--mark
From: Stephen J Bevan
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <BEVAN.93Feb3154219@panda.cs.man.ac.uk>
In article <·····················@sharebase.com> ····@airplane.sharebase.com (Scot Dyer) writes:
In Welsh, the response 'Yes' or 'No' is completely dependent on the verbal
structure of the question. For example:
Mae Tom yma? Ydy.
Is Tom here? Yes-he-is.
or... Nag ydy.
No-he-isn't.
Oes caws yn y gegin? Oes.
Is there cheese in the kitchen? Yes-there-is.
or... Does ddim.
No-there-isn't.
In the negative cases I think you can get away with "Na" (at least I'd
say it :-), but I agree that in the affirmative cases the result is
context dependent.
bevan
From: Jeff Dalton
Subject: Format's English
Date:
Message-ID: <8299@skye.ed.ac.uk>
In article <················@di.epfl.ch> ········@di.epfl.ch (Fernando Mato Mira) writes:
>But even if the standard specifies the behaviour only for english, I
>think that thinking only "american" with respect to the "billion
>thing" is quite irritating.
What do people in the UK think? Billion or thousand million?
The ones I've asked so far don't much care.
-- jd
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
In article <················@di.epfl.ch> ········@di.epfl.ch (Fernando Mato Mira) writes:
>But even if the standard specifies the behaviour only for english, I
>think that thinking only "american" with respect to the "billion
>thing" is quite irritating.
What do people in the UK think? Billion or thousand million?
The ones I've asked so far don't much care.
Well I can't say that it has kept me awake in the wee small hours
either :-) I assume that most people by now know that American's use a
different definition and just make allowances for this i.e. re-check
the source of information if there is any doubt.
bevan
In article <····@skye.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
|> In article <················@di.epfl.ch> ········@di.epfl.ch (Fernando Mato Mira) writes:
|>
|> >But even if the standard specifies the behaviour only for english, I
|> >think that thinking only "american" with respect to the "billion
|> >thing" is quite irritating.
|>
|> What do people in the UK think? Billion or thousand million?
|> The ones I've asked so far don't much care.
I don't like the americanism but tend to check the source so that I can interpret which "billion"
is meant by the user. The thing that really bugs me is that "The BBC" tend to use the american
version - especially for economic/monetary reports. But that's a thread for UK.misc.
John
From: Jeff Dalton
Subject: CL the PL/1 of list processing
Date:
Message-ID: <8300@skye.ed.ac.uk>
In article <················@di.epfl.ch> ········@di.epfl.ch (Fernando Mato Mira) writes:
>
>And yes, I think CL is "a nice PL/1".
What do you mean by this, other than "CL is big"?
>If C++ is the black hole of OO programming, I must say that CL is the
>neutron star of list processing.
Why is that?
I really can't tell what people have in mind when they make remarks
like that. That's not because I can't think of problems that fit
their description. The trouble is I can't tell _which_ problems they
have in mind. And sometimes, the problems they have in mind don't
really exist or are based on a misunderstanding.
-- jd
From: Fernando Mato Mira
Subject: Re: CL the PL/1 of list processing
Date:
Message-ID: <1993Feb1.190001@di.epfl.ch>
In article <····@skye.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
> In article <················@di.epfl.ch> ········@di.epfl.ch (Fernando Mato Mira) writes:
> >
> >And yes, I think CL is "a nice PL/1".
>
> What do you mean by this, other than "CL is big"?
>
Just that (and maybe that it is not as clean as SCHEME).
> >If C++ is the black hole of OO programming, I must say that CL is the
> >neutron star of list processing.
>
> Why is that?
>
> I really can't tell what people have in mind when they make remarks
> like that. That's not because I can't think of problems that fit
> their description. The trouble is I can't tell _which_ problems they
> have in mind. And sometimes, the problems they have in mind don't
> really exist or are based on a misunderstanding.
>
By C++ being "a black hole" I mean that it is sucking a lot of programmers into
itself and that it makes harder for other OO languages to become widespread (some
people even say it's killing the other OO langs.).
I think you understand the rest by now. In the LISPy domain, maybe you have some
more freedom and can afford using a not very efficient (with respect to CL
implementations) SCHEME or DYLAN interpreter or do not care about using PD CL
packages. But if you want performance or access to a lot of software, you have to
use CL. If this is wrong *now* please tell me and I throw my CL through the
window. But anyway, we all know that procedural languages are a hack, so why
bother? Even SCHEME looks dirty when you compare it to a real functional language.
Why not stick around with CL and wait 10 years for the change? (But really, I miss continuations and using FUNCALL always makes me
uncomfortable...)
On another line (ISO LISP), LISP without EVAL? What is that? Does it have
COMPILE at least, can I defun at runtime? I mean, compiling things out is great, but if the language
doesn't include those, then it is not really LISP (at least for me). I would say "QUASI" rather than
"ISO". How compatible is the rest with CL? If it is almost the same then maybe it
makes sense as a delivery language, otherwise, is anybody going to use it? I
mean, what will some "mainstream language" developer gain by switching to it?
Enough blah,blah for today.
--
Fernando D. Mato Mira
Computer Graphics Lab "Only CLOS is good enough"
Swiss Federal Institute of Technology
········@di.epfl.ch
NeXTMail : ········@lignext.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed-point-disclaimer(H,DH),
disclaim(T,DT).
fixed-point-disclaimer(Text,fixed-point-disclaimer(Text,_)).
From: hume smith
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <EMCOOP.93Jan26151415@bcars148.bnr.ca>
In article <·········@stl.dk> ···@stl.dk (Flemming Vestergaard) writes:
In <·············@noonian> ···@doe.carleton.ca (David F. Skoll) writes:
> I mean,
>who really needs the number 394829348234982435 formatted in English words??
>Just try (format t "~R~%" 394829348234982435) for fun!
Well, it is fun. But from this corner of the world I suppose that it is
a more serious problem (if not a disaster) that Common Lisp provides
input and output functions that are suited only for English/American.
(format t "~R" 4) -> four really doesn't help very much in most of the world.
And yes-or-no-p cannot be used either.
I do think it is a mistake to include natural language specific functions
in a language standard.
well it IS the AMERICAN standard. ISO may (should) make a different one.
i personally think there should be something way, from system locale
resources, to figure out local customs. it shouldn't be too hard to
have hooks of some sort for ~R, so local number-spelling functions
can be slipped in.
--
Hume Smith Honour sick and davey cris-cross
··········@acadiau.ca McTruloff sentimie
······@bnr.ca A parsnip inner pair threes.
From: Tom Pole
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1993Jan28.190225.9215@evb.com>
In article <·········@stl.dk> ···@stl.dk (Flemming Vestergaard) writes:
>In <·············@noonian> ···@doe.carleton.ca (David F. Skoll) writes:
>
>>I've noticed a thread extolling the beauty of Lisp syntax. While I agree
>>that mostly, Lisp syntax is easy to understand and consistent, I wonder
>>what sort of mental disease struck the creators for the "format" function.
>>Take a look at all the baroque format directives in Common Lisp. I mean,
>>who really needs the number 394829348234982435 formatted in English words??
>>Just try (format t "~R~%" 394829348234982435) for fun!
>
>Well, it is fun. But from this corner of the world I suppose that it is
>a more serious problem (if not a disaster) that Common Lisp provides
>input and output functions that are suited only for English/American.
>
>(format t "~R" 4) -> four really doesn't help very much in most of the world.
I'm a bit confused. The fact that the output is in 'American' is somehow
different from the code being in 'American'. Don't 'C', Fortran, Basic, Ada
compilers' source code in all countries use "print", "open", "type",
"character", "in", "out", etc., etc. This may be a complaint, but surely
not a complaint about Lisp syntax/semantics.
I don't believe it would be terribly difficult to write a lisp extention
to allow a format method to be defined on a foreign language object
to produce the textual versions of numbers. I believe that Lisp
syntax/semantics and its dynamic/extensible nature would also make
such an extention easier to implement in Lisp than in most other
languages.
>And yes-or-no-p cannot be used either.
Thomas
>
>I do think it is a mistake to include natural language specific functions
>in a language standard.
>
>Flemming
--
Thomas Pole
In article ... ····@airplane.sharebase.com (Scot Dyer) writes:
Actually, yes-or-no-p would be very hard to internationalize correctly.
There exist languages with no direct translations of the English "Yes"
and "No," and languages where the semmantics of "Yes" and "No" are
quite different for questions posed in the negative. Examples are
Welsh (with no direct 1-to-1 translation for either 'Yes' or 'No'),
Japanese (where the semmantics of saying 'Yes' to a negative question
are different than those of English), and French (where a 3rd word is
added for disambiguating answers to questions in the negative)
It's not just Japanese. Some of us linguistically warped hackers respond
differently to negative questions.
``Do you want some tea?'' ``Yes.'' (I want some tea)
``Don't you want any tea?'' ``No.'' (I want some tea)
To avoid confusion, I've found it easier to say whether or not I want any
tea, rather than just ``yes'' or ``no''..... And I note that half my
brain is unhappy with this, and half would be unhappy with the opposite.
When is ``Consciousness Explained'' out in PB, anyway?
--
Regards, | "You're better off not dreaming of the things to come;
Kers. | Dreams are always ending far too soon." - Caravan.
In article <·············@noonian> ···@doe.carleton.ca (David F. Skoll) writes:
> [parts omitted]
>Take a look at all the baroque format directives in Common Lisp. I mean,
>who really needs the number 394829348234982435 formatted in English words??
>
I think I do! (But for Turkish words, and I think that would be easy to
do since there is a rather trivial 1-1 mapping.)
Here we fill a ridiculous government form every month (just to claim
some money back in return for receipts for goods with a value-added tax)
and the form won't be accepted unless you you write the sum total
in Turkish. Unfortunately my totals hardly approach the neighborhood of the
number you've cited :-) :-)
Varol Akman
Department of Computer Engineering and Information Science
Bilkent University, Bilkent, Ankara 06533, Turkey
E-mail: ·····@trbilun.bitnet
From: Mark S. Riggle
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <C19snx.2IF@unx.sas.com>
I think that one aspect of Lisp syntax that can be
confusing to lisp novices is that the first
position of a list is the functional call, EXCEPT
in certain forms. Like the lambda argument list,
'let', 'do' and others, including some user defined
macros.
ie. te consider the following fragments:
(let
((fred (x))
(sam (y))))
(letter
((fred (x))
(sam (y))))
So syntactically they look the same, but we all
know they are semantically vastly different, except
of course we have made a macro definition for
letter that is the same as say let or let*.
I think it actually takes quite some exposure to
Lisp before this semantic transformation is natural
and automatic to someone.
--
=============================================================
Mark Riggle [Professional Lisp Bigot]
······@unx.sas.com
SAS Institute Inc.,
SAS Campus Drive, Cary, NC, 27513
(919) 677-8000
···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
> And why not use Fortran for some scientific hacking?
What was wrong with Maclisp's numeric code? What is wrong with Lisp compilers
that have unboxed representations for floating point numbers?
Aren't the bignums and bigfloats Fortran lacks never useful for scientific
computations?
Bruno Haible
······@ma2s2.mathematik.uni-karlsruhe.de
Far be it for me to speak for Larry, but I've been reading this thread
long enough to see that the other side of the story isn't being told.
So here's my tuppence.
In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
> Date: Thu, 21 Jan 1993 18:06 EST
> From: Larry Wall <·····@netlabs.com>
>
> : In what way is Lisp "bland ... all the way through"?
>
> There's little visual distinctiveness to distinguish mentally
> distinctive constructs.
>
>This is simply not a valid criticism. There is little visual
>distinctiveness in English to distinguish mentally distinctive
>constructs, and yet you do not fault English. In fact, one could argue
>that "visual distinctiveness" is a principally a matter of typography.
Not a good analogy. Not only is english an unstructured language (as
compared with programming languages) but parsing english is legendary
for its difficulty. Without punctuation and semantic context, it's
trivial to write correct english which is effectively illegible; that's
illegible to man _or_ machine. The same is not true even of obfuscated
C; compilers handle it nicely. So legibility in english is _not_ a
simple matter of typography.
Likewise context free languages can be difficult to read for more reasons
than just syntactic sugar. There's little debate that unindented Lisp is
just as hard to read as unindented C, but few of us write unindented C,
and ALL Lisp is partly unindented any time two parens are adjacent.
However I think the real case to be made for Lisp's relative illegibility
is one of procedural languages vs. functional languages. When a process is
decomposed into separate tasks which are presented sequentially, the reader
has the least work to do in understanding the intent of the programmer.
Whenever processes are nested and one process generates temporary values
which are then fed directly into other processes, as in Lisp, the delineation
between tasks (prior vs. successor) is less clear. Certainly we don't write
english sentences from the inside out, why should we expect programmers to
read source code which is written that way?
>
> : Are you saying that you think that the true challenge in programming
> : is the actual struggling with the language, rather than the addressing
> : the deeper issues (such as, what it is you are trying to do)?
>
> I haven't noticed people struggling that much less with Lisp than with
> most other languages. Admittedly, nroff is a bit tougher, unless
> you're just trying to do text processing... :-)
>
>Perhaps it is the sort of software I do, but I emphatically do notice
>people struggling more with most other languages than with Lisp. Let's
>look at memory management, for instance. In most other languages, such
>as C, programmers must confront the issue of memory management head on,
>[...] The point is that, in most other
>languages, programmers must immediately tackle programming tasks that
>are only incidentally related to the problem at hand.
I see two ways to interpret what Larry said. One is to state that Lisp's
bag of tricks is no bigger than that of other languages. How readily does
a language protect the programmer from having to consider implementation
details like precision loss or the free use of memory? Does it provide
sufficient resources to off-load the myriad system support details which
are tangential to implementing an algorithm? I'd say that any language
as large as CL probably _is_ going to serve a programmer's every need,
albeit one-size-fits-all. But I don't think that's the better case that
can be made against Lisp, although that seems like what you defended.
The other perspective is one of general expressibility: does Lisp succeed
where other languages fail in producing readable source code and efficient
executables, leading to maintainability, modularity, and extensibility?
To answer this, Lisp must be compared on its own merits, without CLOS or
Genera. When stripped of its extensions and superb development environment,
Lisp doesn't appear to me to have a clear upper hand over a language like
Modula 2 or even Ada, not in any general sense. It's not more legible,
more intuitive, more efficient in execution. Lisp fares most poorly (IMHO)
when compared like this with newer languages like Modula 3, which were
designed largely for their legibility and modularity.
It's from this point of view that I too would say that I've seen few people
struggling more with Ada or Modula 3 than with Lisp. Compare the mysteries
of writing in Motif or Wcl with writing in CLIM or Clu. Not so different.
>
> : In what way does Lisp "push down so hard" on morphology?
>
> Essentially, Lisp assumes that humans like to write programs the same
> way the machines like to execute them, and so conflates the human
> representation with the machine representation. True, there are Lisp
> compilers, but the "ideal" is still that the machine and the programmer
> are interpreting the exact, same, one-size-fits-all data structure.
>
>I fail to see that Lisp makes any such assumption. What machines
>directly execute mapping operators? Reduction operators? What machines
>directly execute generic arithmetic, including integers, large integers,
>floating point, and ratios? Hash tables? Sequences and collections?
>This claim just cannot be made to stick.
Prefix notation and functional expressions are two `gotos considered good'
in Lisp. Violating either of these will either shut down your equations
or excommunicate yourself from the Brotherhood. They're both proscriptive.
>
>I also think you have confused what you call "machine representation"
>with "parsed representation". The fact that the human-readable
>representation is the same as the basic parsed representation is one of
>the great sources of Lisp's power -- it allows Lisp programs to
>effortlessly talk about Lisp programs.
Sort of the effortless way that Forth programs read?
>
> That said, I should back off a little and admit that there are a few
> things that are easier in Lisp than in other languages. But your
> assumption seems to be that it's better to use an all-around mediocre
> language for most everything than to use each language for what it does
> best. [...]
>
>I don't claim that Lisp is an all-around mediocre language. It's an
>all-around excellent language. Sure, there are some languages that have
>a few features that are better than what I can find in Lisp, but so what?
> [...]
>For general programming, I'll take Lisp nearly every time. Moral: use the
>right tool for the job.
Perhaps by choosing an all-around excellent language? :-)
Lisp isn't the most legible language, nor the fastest in execution, nor the
smallest in executables, nor the most portable among OSes, nor the easiest
to integrate with 3rd party applications. These are all excellent reasons
to prefer other languages when these considerations outweigh Lisp's
comparative strengths in rapid prototyping, implementation sbstraction,
flexible data structures, and run-time flexibility. In the PC applications
arena or systems or networking or communications or accounting or number-
crunching or distributed software, Lisp isn't even in the running.
THAT'S why Lisp isn't a mainstream language.
--
| Randy Crawford ········@mitre.org The MITRE Corporation
| 7525 Colshire Dr., MS Z421
| N=1 -> P=NP 703 883-7940 McLean, VA 22102
From: Jim Carden
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <1877@tekgen.bv.tek.com>
[[** Posted for ····@goldfish.mitron.tek.com **]]
In article <······················@linus.mitre.org> ········@boole.mitre.org (Randy Crawford) writes:
>However I think the real case to be made for Lisp's relative illegibility
>is one of procedural languages vs. functional languages. When a process is
>decomposed into separate tasks which are presented sequentially, the reader
>has the least work to do in understanding the intent of the programmer.
>Whenever processes are nested and one process generates temporary values
>which are then fed directly into other processes, as in Lisp, the delineation
>between tasks (prior vs. successor) is less clear. Certainly we don't write
>english sentences from the inside out, why should we expect programmers to
>read source code which is written that way?
There's an interesting point. What other notations are there to improve on this?
The most common is naming intermediate values. For this I prefer CL and Scheme's
LET or Dylan's BIND to C's (and Pascal, Ada, Modula, etc.) assignment semantics.
I use LET throughout my code and rarely have deeply nested functional expressions.
>When stripped of its extensions and superb development environment,
>Lisp doesn't appear to me to have a clear upper hand over a language like
>Modula 2 or even Ada, not in any general sense. It's not more legible,
>more intuitive, more efficient in execution. Lisp fares most poorly (IMHO)
>when compared like this with newer languages like Modula 3, which were
>designed largely for their legibility and modularity.
These are mostly subjective values, so to each his own. Modern LISPs' lexical
scopes, closures, and macros allow me to be significantly more expressive
than with any of the other languages you mentioned. (I have programmed extensively
in CL, Scheme, C, and C++. I have used the others enough to know what they're
like.)
>Prefix notation and functional expressions are two `gotos considered good'
>in Lisp. Violating either of these will either shut down your equations
>or excommunicate yourself from the Brotherhood. They're both proscriptive.
I could build a calendar based on threads like this one just as accurate
as the Mayan's. This is a recurring, subjective topic. Your mileage will
certainly vary.
--
Patrick Logan, ····@goldfish.mitron.tek.com, (503) 690-8350
Randy Crawford (········@boole.mitre.org writes:
Not only is english an unstructured language (as compared with programming
languages) ...
Well, any grammar for English would be far larger and more complex than for any
programming language (except maybe CommonLisp :), but I don't think I'd call
English unstructured.
... but parsing english is legendary for its difficulty.
Hmm, I have very little difficulty. :)
Without punctuation and semantic context, it's trivial to write correct english
which is effectively illegible; that's illegible to man _or_ machine.
You must make a distinction between syntactic correctness and understanding. I'm
not sure which you mean by "illegible", but if I can't parse your trivially
written sentence, and few other English speakers can either, then it ain't
English, by definition.
On the other hand, maybe you meant "understand-ability"; you're correct in that
it's easy to construct syntactically valid English sentences that I can't
understand, but that's true for programming languages as well. I submit that the
C code for the phone system is not understandable "to man _or_ machine". It's
EXECUTABLE, but so what? Very little code is understandable, as in "what does
this do, in all circumstances", to machine. Witness all the research on program
verification.
Of course, none of this distinguishes Lisp from any other programming language,
but I just wanted to suggest that as far as "legibility" (which I read as
"understand-ability") is concerned, natural and programming languages are perhaps
not that different.
John Burger ····@mitre.org
In article <······················@linus.mitre.org> ····@thelonius.mitre.org (John D. Burger) writes:
... but parsing english is legendary for its difficulty.
You must make a distinction between syntactic correctness and understanding. I'm
not sure which you mean by "illegible", but if I can't parse your trivially
written sentence, and few other English speakers can either, then it ain't
English, by definition.
Back in the mists of time when I took a course on natural language
programming we were asked to parse "I saw the man on the hill with the
telescope". I seem to remember 7 different ways to parse it. It's
perfectly good, trivial english, you just need a whole lot of context to know
what's the right one.
This has gotten pretty far afield from the original discussion, but
none of these "reasons why Lisp isn't a mainstream language" seem
reasonable.
We can't change the syntax, it'll confuse more people than it'll
convert. I remember trying to teach people about the alternate syntax
provided by Interlisp, which provides the usual syntax, apply-form,
and infix form. It's too damn confusing, and it's just easier if you
learn the regular syntax. I know a lot of people who find the Lisp
syntax a lot easier to deal with than C's, for example.
Lisp images are large because there's a fair amount of other support
(Yes, I realise that MCL is only 2.5 Mb. However, how does that
compare with other programs on Mac's?) in the image, and yes, the
language definition is huge. There have been recent developments on
this score, like tree shakers and shared libraries. Besides, if
smallness of the language was an indicator why isn't everyone
programming in Scheme? SIOD will fit in 64K, if memory serves.
I think there are other reasons for Lisps non-popularity, some of them
historical. Lisp got tied in to the AI binge, and when AI busted it
took Lisp with it. There've been a lot of other myths about Lisp
raised through time too, most of which have stuck (Lisp isn't good for
number-crunching, Lisp is slow, etc.) no matter how untrue they were.
Some blame can also be put on the Lisp programmer community itself,
through pricing itself out of the market during the AI heyday. One of
Lisp's greatest features is it's extensibility, but this has also
resulted in the mudball theory of programming language design :-).
I think an associated question we should be asking is "How can we
increase Lisp's popularity"? Knowing why it isn't popular is a good
thing to discuss, but it would also be good to know where to go from
here. Another question is "Should Lisp be a mainstream language?" I'm
not sure the answer to that is yes. A lot of neat ideas have risen out
of Lisp not having been standardised to death early on. CLOS is a case
in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
Flavors I think we'd be a lot poorer today.
I'll stop now, I think this is certainly turning out to be an
interesting discussion.
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
·····@cis.ohio-state.edu
In article <······················@linus.mitre.org> ····@thelonius.mitre.org (John D. Burger) writes:
>Randy Crawford (········@boole.mitre.org writes:
>
> Not only is english an unstructured language (as compared with programming
> languages) ...
>
>Well, any grammar for English would be far larger and more complex than for any
>programming language (except maybe CommonLisp :), but I don't think I'd call
>English unstructured.
`The horse ran through the barn, fell.' No, English isn't entirely unstruct-
ured or else it'd be unintelligible. But the number of irregularities and
contextual dependencies makes it at least context sensitive, and fully
unrestricted as far as I'm concerned. That's pretty unstructured when
compared to CFG programming languages. (I refuse to consider English as
structured but complex. It's too much a product of messy evolution to claim
that.)
If it isn't relatively unstructured then it's relatively structured. There-
fore it ought to be relatively easy to specify rules for parsing it. Yet
that's shown itself to be *highly intractable*. So I consider English to be
comparatively unstructured.
So there. I've run rings around you logically.
>
> Without punctuation and semantic context, it's trivial to write correct english
> which is effectively illegible; that's illegible to man _or_ machine.
>
>You must make a distinction between syntactic correctness and understanding. I'm
>not sure which you mean by "illegible", but if I can't parse your trivially
>written sentence, and few other English speakers can either, then it ain't
>English, by definition.
So that's the definition of English. I always wondered. :-]
`The girl saw the boy on the hill with a telescope.' Legal English. Trivial.
I can think of at least four ways to parse this. By your definition, I'm
illiterate because I can't parse this.
I prefer to think that your definition of English is flawed.
>
>On the other hand, maybe you meant "understand-ability"; you're correct in that
>it's easy to construct syntactically valid English sentences that I can't
>understand, but that's true for programming languages as well. I submit that the
>C code for the phone system is not understandable "to man _or_ machine". It's
>EXECUTABLE, but so what? Very little code is understandable, as in "what does
>this do, in all circumstances", to machine. Witness all the research on program
>verification.
This is getting more philosophical than I intended.
The only compiler for English is a human. If the person can't figure out the
sentence, then it's useless. Programming languages are equally useless if
_their_ compilers can't make sense of them. If the programming language
source is unreadable to humans, then the programmer has written machine code.
Since nobody is lining up to program in hexadecimal these days, I have to
conclude that source readability is the reason. Ergo source code legibility
is important, whether it completely and correctly describes its intentions or
not.
If in fact Lisp is less legible than other programming languages, then that's
a justifiable black mark against Lisp.
>
>Of course, none of this distinguishes Lisp from any other programming language,
>but I just wanted to suggest that as far as "legibility" (which I read as
>"understand-ability") is concerned, natural and programming languages are perhaps
>not that different.
But they're not exactly equivalent either since no machine in the world is
capable of making sense of varied natural language. I hope the same isn't
true of your favorite programming language or you're going to need an
excellent memory to recall what all your code was originally meant to do.
--
| Randy Crawford ········@mitre.org The MITRE Corporation
| 7525 Colshire Dr., MS Z421
| N=1 -> P=NP 703 883-7940 McLean, VA 22102
This has very little, if anything, to do with this thread, so I'll stop after
this post. I'm surprised there weren't more replies to my original post, it
was such a perfect flame magnet. :)
Randy Crawford (········@boole.mitre.org) writes:
The horse ran through the barn, fell.' No, English isn't entirely
unstructured or else it'd be unintelligible. But the number of
irregularities and contextual dependencies makes it at least context
sensitive, and fully unrestricted as far as I'm concerned. That's pretty
unstructured when compared to CFG programming languages
I'm not sure what your garden path sentence was an example of, but it's
certainly parseable, with or without the comma (which, by the way, I believe
would be considered ungrammatical by proscriptive grammarians). It even has
only one parse. As far as grammatical complexity is concerned, no one has
proven very convincingly that English, in particular, is syntactically
context-sensitive. Sorry. Even if English were trans-context-free, it
needn't be unstructured, by which you mean, I presume, something like
"having few formal requirements". And I don't know what "unrestricted"
means. "horse barn ran through the" isn't English, so English has some
restrictions, at least.
If it isn't relatively unstructured then it's relatively structured.
Therefore it ought to be relatively easy to specify rules for parsing it.
Yet that's shown itself to be *highly intractable*. So I consider English
to be comparatively unstructured.
Getting right all the nooks and crannies of a natural language grammar is
certainly hard. It hasn't yet been done. Nonetheless, systems exist that
correctly parse better than 99 percent of, say, the New York Times, or even
harder texts, correctly. Your may disagree, but I think that's possible
because there's lots of structure there. Of course, a C (or even Lisp)
compiler correctly parses much closer to 100 percent of its respective
language. It better.
If I can't parse your trivially written sentence, and few other English
speakers can either, then it ain't English, by definition
`The girl saw the boy on the hill with a telescope.' Legal English.
Trivial. I can think of at least four ways to parse this. By your
definition, I'm illiterate because I can't parse this.
I prefer to think that your definition of English is flawed.
I'm confused. You say "I can think of at least four ways to parse this",
then you say "I can't parse this". Is the problem that there is more than
one parse? That's certainly true. Nonetheless, the sentence can be parsed.
As far as my definition of English is concerned, I don't know what other one
there is. Maybe I missed the announcement of "ANSI English 93".
Rather arbitrarily, I'll stop now.
John Burger ····@mitre.org
From: Jeff Dalton
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <8272@skye.ed.ac.uk>
In article <······················@linus.mitre.org> ········@boole.mitre.org (Randy Crawford) writes:
>
>Far be it for me to speak for Larry, but I've been reading this thread
>long enough to see that the other side of the story isn't being told.
Really? Perhaps this time, but the case against Lisp syntax is told
again and again, in my experience.
I'd like you to ask yourself something. How could _anyone_ (who wasn't
a complete idiot) possibly think Lisp was _easier_ to read than other
languages? Could it be that maybe, for them, it really is easier,
and that they aren't just confused or in the grip of "what they're
used to"?
Just what do you think the story is here? What's wrong with these
people, in your opinion?
>In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>> Date: Thu, 21 Jan 1993 18:06 EST
>> From: Larry Wall <·····@netlabs.com>
>>
>> : In what way is Lisp "bland ... all the way through"?
>>
>> There's little visual distinctiveness to distinguish mentally
>> distinctive constructs.
As compared to ... what? For instance? Let's have some examples of
this visual distinctiveness. Let's have it compared to Lisp as
presented in Algol-ish style (ie, different fonts for different
things, as in some of the Scheme texts), or whatever.
> There's little debate that unindented Lisp is
>just as hard to read as unindented C, but few of us write unindented C,
>and ALL Lisp is partly unindented any time two parens are adjacent.
What? All languages are partly unindented every time two visible
characters appear on the same line, no? What exactly is the problem
in Lisp that you're referring to?
In properly indented Lisp, it isn't necessary to pay attention to
individual parens when reading the code. Even the general structure
of parens is largely redundant, serving chiefly to reinforce the
impression created by the indentation and our knowledge of the
operators involved. Programmers new to Lisp often try to make it
more readable by putting individual close-parens along on a line
(like they might with an "end" in Algol or a "}" in C). This
generally makes it _less_ readable.
>However I think the real case to be made for Lisp's relative illegibility
>is one of procedural languages vs. functional languages. When a process is
>decomposed into separate tasks which are presented sequentially, the reader
>has the least work to do in understanding the intent of the programmer.
Do you think functional languages such as ML or Haskell have this
problem?
Now, it's true that sequential is often easier to understand;
and that's one reason why Lisp programmers often write things
out sequentially. On the other hand, nested function calls
are used in almost every language. Lisp programmers are probably
used to a bit more complexity here than, say, C programmers;
but in well-written Lisp programs procedure definitions tend
to be fairly short, and the complexity of individual expressions
is kept under control.
Moreover, sequential isn't always easier to understand, which
is why we don't break every expression down into single steps
in (virtually) any language.
>The other perspective is one of general expressibility: does Lisp succeed
>where other languages fail in producing readable source code and efficient
>executables, leading to maintainability, modularity, and extensibility?
>To answer this, Lisp must be compared on its own merits, without CLOS or
>Genera.
CLOS is part of Common Lisp. Let's deal with actual Lisps, please,
such as Common Lisp, Scheme, EuLisp, and Dylan, and not with an
abstract "Lisp". Common Lisp, EuLisp, and Dylan all have object
systems as part of the language. EuLisp and Dylan were designed
post-CLOS, and their object-oriented aspects are not extensions
even historically.
>When stripped of its extensions and superb development environment,
>Lisp doesn't appear to me to have a clear upper hand over a language like
>Modula 2 or even Ada, not in any general sense.
I might even agree with that as a general point, though I don't think
Modula 2 or Ada are very good examples. Indeed, I usually try to say
that some people (like me) find Lisp better (at least for a wide range
of tasks) and that there's more than one good kind of language. I
think Lisp is _a_ good language, but not the only one; and I don't
expect everyone to prefer the same kind of language.
Where I disagree is when people seem to be saying that Lisp is worse
than other languages. I don't think that is so, in general, though it
often is so for certain specific purposes.
>Prefix notation and functional expressions are two `gotos considered good'
>in Lisp. Violating either of these will either shut down your equations
>or excommunicate yourself from the Brotherhood. They're both proscriptive.
To me, your entire argument more or less boils down to this: prefix
notation and functional expressions are bad. There's obviously
something to be said for this. However, for me and a number of other
people, it turns out that, all things considered, Lisp is more readable
than other languages. So either prefix notation and functional
expressions aren't as big a problem as some think, or else there
are compensating advantages. Because I just don't think we're that
different from everyone else.
This is not to say that everyone ought to see things our way. Nor am
I saying that it's entirely a matter of opinion or personal preference.
I think it's like this: when the alternatives in question are sufficiently
good, then it's not wrong to pick any of them. At this point, it's
individual factors that decide, and it has to be that way, because
there isn't One True Answer.
>Lisp isn't the most legible language, nor the fastest in execution, nor the
>smallest in executables, nor the most portable among OSes, nor the easiest
>to integrate with 3rd party applications. These are all excellent reasons
>to prefer other languages when these considerations outweigh Lisp's
>comparative strengths in rapid prototyping, implementation sbstraction,
>flexible data structures, and run-time flexibility. [...]
>THAT'S why Lisp isn't a mainstream language.
What are these mainstream languages, anyway? C, and what else?
-- jd
From: Barry Margolin
Subject: CAR and CDR (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1js697INNjh@early-bird.think.com>
In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>I personally think CAR and CDR could have been flushed from the
>language, since FIRST and REST do the exact same thing.
FIRST and REST only make sense when a cons is being used as a chain in a
list. CAR and CDR make much more sense for conses being used as pairs.
Their lack of preexisting semantics fits in with the abstract nature of
conses: calling them CONS-PART1 and CONS-PART2, for instance, would imply
an ordering to the components that doesn't necessarily exist. Flushing CAR
and CDR would make almost as little sense as flushing NOT because it's
equivalent to NULL.
Perhaps conses as fundamental data types should have been removed when
DEFSTRUCT was included in the standard. CONS could be defined as:
(defstruct (cons (:conc-name ""))
car cdr)
> What machines
>directly execute mapping operators? Reduction operators?
Connection Machines!
> What machines
>directly execute generic arithmetic, including integers, large integers,
>floating point, and ratios?
Lisp Machines?
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <····················@SUMMER.SCRC.Symbolics.COM>
···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
I have great respect for Scott's abilities, and agree with his major
points. On the following minor nit, however, I disagree:
>I personally think CAR and CDR could have been flushed from the
>language, since FIRST and REST do the exact same thing. Note, by the
>way, that you have picked one of the very few things retained in Common
>Lisp for historical purposes.
I agree when one is working with lists. However, occassionally one uses
cons cells for other things (eg trees), and CAR/CDR (or even LEFT-POINTER and
RIGHT-POINTER) are preferable then, IMHO. I'd rather have a meaningless
name in such a case than one like FIRST where the current use contradicts the
meaning. But this is obviously a minor point.
On the real issue of why LISP is not mainstream, most of the comments I've
seen have focused on the user's perspective. However, I think there is also
a commercial reason having to do with the "bundledness" of Common LISP. I've
become convinced that since Common LISP is so big, only a few vendors had
(have?) the manpower to tackle it. There were good technical reasons against
going with a small core language with optional libraries for Common LISP,
but it did make it a lot harder for vendors to break in. If you could buy
CLOS from one person (and still have it optimized, which is hard, I realize),
FORMAT from another, LOOP from a third, CLIM from Scott, a development
environment from yet another, and so on, more small companies could have
entered the market. Right now it is hard for companies to carve out a
niche; they sort of have to go after the LISP market whole hog.
As a user, I'd rather be able to count on everything being there in any
implementation, and I realize it may be convenient to able to assume CLOS
is built in (when writing the condition system, for instance). But these
conveniences had negative implications in the commercial marketplace.
On an only slightly related note, I'm unaware of the licensing rules, but
perhaps the availability of CMUCL, WCL, and PCL will provide an avenue for
smaller vendors to get up and going more quickly. And perhaps CLIM will
provide a standard so that we can realistically buy (and sell) graphics
applications that lots of people could use...
- Marty
(proclaim '(inline skates))
>In article <····················@SUMMER.SCRC.Symbolics.COM>
>···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>
>I have great respect for Scott's abilities, and agree with his major
>points. On the following minor nit, however, I disagree:
>
>>I personally think CAR and CDR could have been flushed from the
>>language, since FIRST and REST do the exact same thing. Note, by the
>>way, that you have picked one of the very few things retained in Common
>>Lisp for historical purposes.
Yeah, but would you really want to look the "first" and "rest" equivalent
of, say, caaddddr?
-Michael
--
Practice random acts of randomness.........
················@cs.yale.edu
>>>>> On 8 Feb 1993 14:12:08 -0500, ················@yale.edu (Michael Theodore) said:
MT> Yeah, but would you really want to look the "first" and "rest" equivalent
MT> of, say, caaddddr?
Would probably not take too long before you had functions like ffrrrr
(for (first(first(rest(rest(rest(rest foo))))))) :-)
--
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++!
! Richard Levitte, VMS GNU Emacs hacker ! tel: int+46-8-18 30 99 !
! Sulv"agen 57, II ! fax: none for the moment !
! S-126 40 H"agersten ! Internet: ·······@e.kth.se !
! SWEDEN ! !
!-----------------------------------------------------------------------------!
In article <····················@elin.e.kth.se>, ·······@e.kth.se (Richard Levitte) writes:
|> >>>>> On 8 Feb 1993 14:12:08 -0500, ················@yale.edu (Michael Theodore) said:
|>
|> MT> Yeah, but would you really want to look the "first" and "rest" equivalent
|> MT> of, say, caaddddr?
|>
|> Would probably not take too long before you had functions like ffrrrr
|> (for (first(first(rest(rest(rest(rest foo))))))) :-)
I wouldn't want to look an either of these and I'd be inclined to fire the
programmer who created such a nightmare. Simple data abstraction (e.g.,
via DEFSTRUCT) obviates the need for embedded car/cdr expressions and increases
legibility of code.
..................................................
Len Charest, Jr.
JPL Artificial Intelligence Group
·······@aig.jpl.nasa.gov
From: Christopher Ian Connolly
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <59072@dime.cs.umass.edu>
In article <······················@netlabs.com> ·····@netlabs.com (Larry Wall) writes:
>In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>: In what way is Lisp "bland ... all the way through"?
>
>There's little visual distinctiveness to distinguish mentally
>distinctive constructs.
Uh, so English is just as bland? Or should we be using curly braces
instead of parentheses? Syntactic Sugar...help!...I'm going
hyperglycemic!! Somebody change my readtable...quick!!
Christopher Ian Connolly ········@cs.umass.edu
Laboratory for Perceptual Robotics wa2ifi
University of Massachusetts at Amherst Amherst, MA 01003
From: Wayne Throop
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <727764541@sheol.UUCP>
:: From: ···@stony-brook.scrc.symbolics.com (Scott McKay)
:: Message-ID: <····················@SUMMER.SCRC.Symbolics.COM>
:: From: ···@stony-brook.scrc.symbolics.com (Scott McKay)
:: In what way does Lisp "push down so hard" on morphology?
: From: ·····@netlabs.com (Larry Wall)
: Message-ID: <······················@netlabs.com>
: One form to rule them all,
: One form to find them,
: One form to bring them all
: And in the darkness bind them.
: In the land of machinery, where the symbols lie.
No. No, I'm sorry, but you've gotten it all wrong.
Lisp is one of the original three elven-rings, untainted by Sauron's
direct touch. It is the Ring of Symbols, most often called the Ring of
Lists. The others are the Ring of Numbers (called the Ring of
Formulas) and the Ring of Bureaucratic Records (called the Ring of
Business, or the Ring of Counting Beans).
But then Sauron tricked the Practical Smiths into forging the
nine-and-ninety Fortran and Regex Variant Rings, and gave them to
the mortal men doomed to die. Among them, C, C++, Awk, Perl, Bliss,
and so on.
And let us not forget the seven-and-seventy Algol Variant Rings, given
to the dwarf-lords in their halls of academia. Pascal, Modula-II,
Oberon, and so on. (I concentrate mainly here on the work Sauron
tricked the WirthSmith into forging.)
And then he attempted to make the One Ring, the Ring that would combine
and control the powers of all the Fortran and Algol Variant Rings,
corrupting and circumventing the Original Rings, and rendering all their
users his helpless wage-slaves.
Lucky for all of us, Sauron outsmarted himself. So many other Beings
were forging Rings of Power along many, many other dimensions during
these troubled times, that the cross-fertilization in the Ring-Forging
business made it nearly impossible to capture all their powers in the
One Ring. The Object Rings, the Functional Rings, the Rings of
Inference. Ada's attempt to be all rings to all peoples largely fell
apart, and so the Original Rings, the Practical Rings, and even the
Academic Rings can nowadays be used safely without fearing the
One Ring.
Which is as it should be, I suppose.
But notice that the Eldest Ring, Lisp, is still around after many
another has faded. It has adapted to the advent of the Object Rings,
the Inference Rings, and even to some extent the Functional Rings.
This is something that is largely missing in the Practical Rings. Once
a Practical Ring like Perl or TCL or C++, or even an Academic Ring like
Modula II, has been cast and decorated with their elaborate engravings
of lexical and syntactic charms (no doubt pleasing to the eye in some
ways), they seem to lose the ability to adapt and subsume
new models of programing.
Yes, C++ is an attempt to add the power of the Object Rings to an older
Practical Ring. And yes, TCL has had several attempts to incorporate
Object Ring powers. But nevertheless, the Eldest Ring, with its lack
of ornamentation, is better able to reflect the job at hand in its
smooth surface, instead of being permanently carved to do the job or
jobs that were at hand once upon a time.
--
Wayne Throop ...!mcnc!dg-rtp!sheol!throopw