In the context of LATEX, some Pythonista asked what the big
successes of Lisp were. I think there were at least three *big*
successes.
a. orbitz.com web site uses Lisp for algorithms, etc.
b. Yahoo store was originally written in Lisp.
c. Emacs
The issues with these will probably come up, so I might as well
mention them myself (which will also make this a more balanced
post)
a. AFAIK Orbitz frequently has to be shut down for maintenance
(read "full garbage collection" - I'm just guessing: with
generational garbage collection, you still have to do full
garbage collection once in a while, and on a system like that
it can take a while)
b. AFAIK, Yahoo Store was eventually rewritten in a non-Lisp.
Why? I'd tell you, but then I'd have to kill you :)
c. Emacs has a reputation for being slow and bloated. But then
it's not written in Common Lisp.
Are ViaWeb and Orbitz bigger successes than LATEX? Do they
have more users? It depends. Does viewing a PDF file made
with LATEX make you a user of LATEX? Does visiting Yahoo
store make you a user of ViaWeb?
For the sake of being balanced: there were also some *big*
failures, such as Lisp Machines. They failed because
they could not compete with UNIX (SUN, SGI) in a time when
performance, multi-userism and uptime were of prime importance.
(Older LispM's just leaked memory until they were shut down,
newer versions overcame that problem but others remained)
Another big failure that is often _attributed_ to Lisp is AI,
of course. But I don't think one should blame a language
for AI not happening. Marvin Mins ky, for example,
blames Robotics and Neural Networks for that.
Jul 18 '05
303  17398 
"Francis Avila" <fr***********@yahoo.com> wrote in message news:<vo************@corp.supernews.com>... "Christian Lynbech" <ch***************@ericsson.com> wrote in message
<snip an enormous long bit of post and re-post>
I believe people don't like Lisp because the Lisp community keeps
writing long, whiny, threads about why people don't like Lisp -- and
posting them in groups that concern entirely different languages.
In article <DL********************@comcast.com>,
"Terry Reedy" <tj*****@udel.edu> wrote: Did all the LMI companies adopt the same version of Lisp so an outside
Lisper could write one program and sell it to run on all? Or did they
each adopt proprietary versions so they could monopolize what turned
out to be dried-up ponds? Again, did they all adopt uniform formats
for distribution media, such as floppy disks, so that developers could
easily distribute to all? Or did they differentiate to monopolize?
(LMI is a name of a Lisp machine company)
Well, all did adopt Common Lisp. The reason for Common Lisp
was to come up with a common Lisp and work against the
fragmentation of the Lisp language. Some very large
software packages (like KEE) were able to run on all
of those. But much of the software has been developed
before Common Lisp (mid 80) in the 70s.
Btw., floppies were not used in the early times - the
machines had tape drives instead.
A. Lloyd Flanagan wrote: "Francis Avila" <fr***********@yahoo.com> wrote in message news:<vo************@corp.supernews.com>...
"Christian Lynbech" <ch***************@ericsson.com> wrote in message
<snip an enormous long bit of post and re-post>
I believe people don't like Lisp because the Lisp community keeps
writing long, whiny, threads about why people don't like Lisp -- and
posting them in groups that concern entirely different languages.
To recap: Someone asked whether it would make sense to add macros to
Python. He specifically cross-posted this to c.l.l in order to get an
opinion from users of a language that has a long history of supporting
macros.
Some strong claims were made why macros might have been the reason that
Lisp has failed. Lispers dispute that macros are bad in this way and
that Lisp has already failed. That's just a natural progression of such
a discussion.
Pascal jo****@corporate-world.lisp.de (Rainer Joswig) writes: The animations for the ground breaking TRON movie were done on Lisp
machines.
Many sources say TRON were made using the one and only Foonly F1,
which was a PDP-10 clone.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
A. Lloyd Flanagan wrote: "Francis Avila" <fr***********@yahoo.com> wrote in message news:<vo************@corp.supernews.com>...
"Christian Lynbech" <ch***************@ericsson.com> wrote in message
<snip an enormous long bit of post and re-post>
I believe people don't like Lisp because the Lisp community keeps
writing long, whiny, threads about why people don't like Lisp -- and
posting them in groups that concern entirely different languages.
Whoa, that is a rather unpleasant addition to the archives.
What part of the subject line do you not understand? Just ignore us.
Python shares a lot of DNA with Lisp; maybe some Pythonistas would be
interested in knowing their Roots.
Especially if they really like Python and want to enjoy many of its
qualities while undertaking something requiring a full-blown
general-purpose language, they might benefit from knowing that the AI
winter and Lisp's loss of mindshare were accidents of history, not signs
of some flaw in the language.
People don't like Lisp because of misconceptions, and threads like that
help dispel those. That has to be a Good Thing, because NGs like this
are where Early Adopters like Pythonistas learn new things to explore,
even when those things were first conceived in 1956.
kenny
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
On Fri, 17 Oct 2003 17:38:23 +0200, an***@vredegoor.doge.nl (Anton
Vredegoor) wrote: Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote:
Asperger syndrome inflexibility is a different thing. If you were
constantly overloaded (from lack of intuition about what is going on,
thus having to figure out everything consciously), I expect you would
probably cling too much to what you know as well.
It is tempting to claim that my post was implying Aspergers to be
potentially *more* flexible because of lack of innateness, however
knowing next to nothing about Aspergers and making wild claims,
linking it to anthropology and computer science, may be a bit prone to
making oneself misunderstood and to possibly hurting people
inadvertently in the process of formulating some consistent theory. So
I'd rather apologize for any inconveniences and confusion produced
sofar, and humbly ask my post to be ignored.
No offence was taken.
I could be tempted to claim that people with Aspergers would be more
flexible than other people, *if* they didn't have to deal with a world
full of normal people.
I suspect that this would be just as wrong, though.
The tendency is that less innateness = more flexibility, but only in
healthy individuals. People with Asperger syndrome have lost a subset
of innate social abilities - but not all of them, and we haven't all
lost the same ones. We have less innate abilities, but we are not
adapted to have less innate abilities. When neurological development
processes break down, there is no order to the abilities that remain
and no guarentee that they will work together.
Learning helps fill the gaps, but it isn't magic.
--
Steve Horne
steve at ninereeds dot fsnet dot co dot uk
On Fri, 17 Oct 2003 09:41:31 -0700, Dave Kuhlman <dk******@rexx.com>
wrote: Asperger's syndrome? -- I did a search and read about it. And,
all this time I thought I was a *programmer*. If I had only known
that I've had Asperger's disorder, I could have saved myself all
those many years of debugging code. It's been fun though,
especially with Python, even if the DSM IV does authoritively say
that I'm just crazy.
:-)
Actually, getting back to being serious...
There is a common misconception that Asperger syndrome is 'mild
autism'. In a sense this is correct, but in terms of causes it is
fairer to say that there are two types of neurological damage. One
damages social intelligence and is present in autism and asperger
syndrome. The other damages general intelligence and is present in
mental retardation and the certain types of autism. High functioning
autism and asperger syndrome are much the same thing, and some people
with asperger syndrome should be considered low functioning - low
general intelligence isn't the only way to become low functioning
('executive function' deficit - another prefrontal cortex issue -
seems to be a major cause of the 'low functioning' label).
Basically, the original Kanner autism is in fact a combination of two
disorders - mental retardation plus a disorder which includes all the
autism features that are not mental retardation. Because the parts of
the brain involved are close together, there is a significant
statistical link.
MR has a cutoff point at an IQ of 'around' 70 (there is room for
judgement, and additional symptoms are required beyond the low IQ),
but the IQ scale is continuous.
What I am getting at is that if you were to read that people with
mental retardation 'find academic study difficult', you might well
decide that you were retarded - after all, we all find academic study
difficult at some point, after all. But you may believe that even if
your IQ were actually 130.
There have been attempts to create a scale of autistic symptoms. You
might like to take the AQ (autistic quotient) here, for instance... http://www.wired.com/wired/archive/9.12/aqtest.html
This test was one of those used in screening prior to my diagnosis. My
score then was 38. I just took it again and got 42. I guess I'm
feeling a bit more pessimistic these days.
What would it look like to have asperger syndrome, but milder? http://www.udel.edu/bkirby/asperger/putnampaper.html
So basically, yes, some of the autistic symptoms seem an aweful lot
like things that are common in normal people. Women will probably tend
to think that all men have asperger syndrome. And nerds will have more
autistic tendencies than other men. And many autistic symptoms can
arise through other causes.
But that doesn't mean Asperger syndrome doesn't exist. You can see the
effects of the neural damage on a PET or MRI scanner, so it is very
hard to claim it doesn't exist.
BTW - the criteria used for my diagnosis are the CLASS criteria, which
are stricter than the DSM IV criteria. They were very interested, for
instance, in symptoms such as my headbanging when I was 3 years old.
I don't think that is particularly typical of programmers.
Neither is the fact that almost everyone with Asperger syndrome
reaches adulthood with severe trauma related disorders due to the
stress in their childhood.
--
Steve Horne
steve at ninereeds dot fsnet dot co dot uk
Google ate my long post, so I'll make it simple.
Lisp failed (yes, it did) because of the parentheses. Normal people
can't parse 13 close-parens easily. Functional notation is
non-intuitive and hard to read.
The world is moving in the direction of languages like Python, that
fit naturally with how we speak and write.
"Francis Avila" <fr***********@yahoo.com> wrote in message news:<vo************@corp.supernews.com>... "Christian Lynbech" <ch***************@ericsson.com> wrote in message
news:of************@situla.ted.dk.eu.ericsson.se.. .>>>> "mike420" == mike420 <mi*****@ziplip.com> writes:
It is still a question of heated debate what actually killed the lisp
machine industry.
I have so far not seen anybody dipsuting that they were a marvel of
technical excellence, sporting stuff like colour displays, graphical
user interfaces and laser printers way ahead of anybody else.
I think what helped kill the lisp machine was probably lisp: many people
just don't like lisp, because it is a very different way of thinking that
most are rather unaccustomed to. Procedural, imperative programming is
simply a paradigm that more closely matches the ordinary way of thinking
(ordinary = in non-programming, non-computing spheres of human endevor) than
functional programming. As such, lisp machines were an oddity and too
different for many to bother, and it was easy for them to come up with
excuses not to bother (so that the 'barrier of interest,' so to speak, was
higher.) Lisp, the language family (or whatever you want to call it), still
has this stigma: lambda calculus is not a natural way of thinking.
This isn't to make a value judgment, but I think it's an important thing
that the whole "functional/declarative v. procedural/OO" debate overlooks.
The same reason why programmers call lisp "mind-expanding" and "the latin of
programming languages" is the very same reason why they are reluctant to
learn it--its different, and for many also hard to get used to. Likewise,
Americans seem to have some repulsive hatred of learning latin--for people
who are used to english, it's just plain different and harder, even if it's
better. (Ok, that last bit was a value judgement. :)
Python doesn't try (too) hard to change the ordinary manner of thinking,
just to be as transparent as possible. I guess in that sense it encourages a
degree of mental sloth, but the objective is executable pseudocode. Lisp
counters that thinking the lisp way may be harder, but the power it grants
is out of all proportion to the relatively meager investment of mental
energy required--naturally, it's hard to convince someone of that if they
don't actually _use_ it first, and in the end some will probably still think
it isn't worth the trouble. It will take very significant and deep cultural
and intellectual changes before lisp is ever an overwhelmingly dominant
language paradigm. That is, when it becomes more natural to think of
cake-making as
UD: things
Gxyz: x is baked at y degrees for z minutes.
Hx: x is a cake.
Ix: x is batter.
For all x, ( (Ix & Gx(350)(45)) > Hx )
(i.e. "Everything that's a batter and put into a 350 degree oven for 45
minutes is a cake")
...instead of...
1. Heat the oven to 350 degrees.
2. Place batter in oven.
3. Bake 45 minutes
4. Remove cake from oven.
(i.e. "To make a cake, bake batter in a 350 degree oven for 45 minutes")
...then lisp will take over the universe. Never mind that the symbolic
logic version has more precision.
Google ate my long post, so I'll make it simple.
Lisp failed (yes, it did) because of the parentheses. Normal people
can't parse 13 close-parens easily. Functional notation is
non-intuitive and hard to read.
The world is moving in the direction of languages like Python, that
fit naturally with how we speak and write.
"Francis Avila" <fr***********@yahoo.com> wrote in message news:<vo************@corp.supernews.com>... "Christian Lynbech" <ch***************@ericsson.com> wrote in message
news:of************@situla.ted.dk.eu.ericsson.se.. .>>>> "mike420" == mike420 <mi*****@ziplip.com> writes:
It is still a question of heated debate what actually killed the lisp
machine industry.
I have so far not seen anybody dipsuting that they were a marvel of
technical excellence, sporting stuff like colour displays, graphical
user interfaces and laser printers way ahead of anybody else.
I think what helped kill the lisp machine was probably lisp: many people
just don't like lisp, because it is a very different way of thinking that
most are rather unaccustomed to. Procedural, imperative programming is
simply a paradigm that more closely matches the ordinary way of thinking
(ordinary = in non-programming, non-computing spheres of human endevor) than
functional programming. As such, lisp machines were an oddity and too
different for many to bother, and it was easy for them to come up with
excuses not to bother (so that the 'barrier of interest,' so to speak, was
higher.) Lisp, the language family (or whatever you want to call it), still
has this stigma: lambda calculus is not a natural way of thinking.
This isn't to make a value judgment, but I think it's an important thing
that the whole "functional/declarative v. procedural/OO" debate overlooks.
The same reason why programmers call lisp "mind-expanding" and "the latin of
programming languages" is the very same reason why they are reluctant to
learn it--its different, and for many also hard to get used to. Likewise,
Americans seem to have some repulsive hatred of learning latin--for people
who are used to english, it's just plain different and harder, even if it's
better. (Ok, that last bit was a value judgement. :)
Python doesn't try (too) hard to change the ordinary manner of thinking,
just to be as transparent as possible. I guess in that sense it encourages a
degree of mental sloth, but the objective is executable pseudocode. Lisp
counters that thinking the lisp way may be harder, but the power it grants
is out of all proportion to the relatively meager investment of mental
energy required--naturally, it's hard to convince someone of that if they
don't actually _use_ it first, and in the end some will probably still think
it isn't worth the trouble. It will take very significant and deep cultural
and intellectual changes before lisp is ever an overwhelmingly dominant
language paradigm. That is, when it becomes more natural to think of
cake-making as
UD: things
Gxyz: x is baked at y degrees for z minutes.
Hx: x is a cake.
Ix: x is batter.
For all x, ( (Ix & Gx(350)(45)) > Hx )
(i.e. "Everything that's a batter and put into a 350 degree oven for 45
minutes is a cake")
...instead of...
1. Heat the oven to 350 degrees.
2. Place batter in oven.
3. Bake 45 minutes
4. Remove cake from oven.
(i.e. "To make a cake, bake batter in a 350 degree oven for 45 minutes")
...then lisp will take over the universe. Never mind that the symbolic
logic version has more precision.
dan wrote: Google ate my long post, so I'll make it simple.
Lisp failed (yes, it did) because of the parentheses. Normal people
can't parse 13 close-parens easily.
Aaaaannnnnndddd they're off! (for another four hundred messages)
Nobody looks at or counts parentheses, except in languages other than
Lisp. We have editors that not only help keep them straight, but also
let us move chunks of code in the meaningful semantic chunks defined by
parentheses. So editing with parentheses is actually the best possible
way to edit code.
Functional notation
I do not think you know much about Lisp. Lisp does imperative as well as
functional. It is a multi-paradigm language. I prefer functional,
because it exposes the structure of my algorithm. YMMD.
is non-intuitive and hard to read.
All code is non-intuitive and hard to read.
The world is moving in the direction of languages like Python,
And Python is moving in the direction of Lisp, tho I do not know if
Python has abandoned its original modest intentions and now wants to go
all the way and be a full-blown HLL. Already seems perty close, just not
sure if the Mission Statement has been changed.
fit naturally with how we speak and write.
You only /think/ you speak and write that way because you have written
step-wise code for so long. If you are a real old fart this started with
Fortran and Basic, maybe Assembler.
From the above it is clear you know nothing about Lisp, so of course it
seems strange to you. But don't you think a language an order of
magnitude better than anything else will have to be different enough to
seem strange?
The good news is how fast you will adjust and your old language seems
strange.
kenny
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|People don't like Lisp because of misconceptions, and threads like that
|help dispel those.
In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).
As soon as I try to learn more by reading discussions, I am bombarded
with weirdly fanatical (and very long) posts that are overwrought with
many misrepresentations (e.g. Python has "Lisp DNA", when pointedly it
does not by GvR's indication). Not that different Lispers even bother
with the same misrepresentations--just so long as they are clear that
programmers of all other languages are ignorant and stupid.
Or tortured threads about things that are only possible in Lisp... but
as soon as any example is presented, it is obvious that the same thing
is not only possible, but much easier and more direct, in (some) other
languages. Then special pleading accompanies the weaknesses of doing
something in Lisp: you have to use some other distribution (maybe a
really expensive commercial one); if only you wrote these difficult and
huge macros it would be easy; you don't -have- to use the syntax since
the semantics is abstract; you shouldn't want to do -that-, but rather
this other thing; etc.
Yours, Lulu...
--
_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
_/_/ ~~~~~~~~~~~~~~~~~~~~[me***@gnosis.cx]~~~~~~~~~~~~~~~~~~~~~ _/_/
_/_/ The opinions expressed here must be those of my employer... _/_/
_/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them! _/_/
da*******@yahoo.com (dan) writes: Google ate my long post, so I'll make it simple.
Thank you.
Lisp failed (yes, it did) because of the parentheses. Normal people
can't parse 13 close-parens easily. Functional notation is
non-intuitive and hard to read.
Yes, you're right, lisp failed, it's dead, and has been for about two
decades now. (Search google for posts like yours from the last century
to confirm this.) But somehow this doesn't stop it thriving, so it's
probably one of the the healthiest dead languages in the history of
IT.
And of course the culprit is the parantheses. (Thank you for telling
us about it! Dylan people will be especially delighted about the
news.) Although ten years ago it was GC, and before that it was that
it needed special hardware to run at acceptable speed.
It's also true that normal people can't parse 13 close parens. Most
Lispers probably can't either, and they definitely don't. Do
pythonistas count whitespace?
I'm grateful for your concise critique of "functional notation". I
assume you mean prefix notation, and considering that algoloid
languages also use this for functions, you should probably switch to
Forth (too bad you probably think it's dead, too). Silly me, I thought
that the charm of infix notation disappears at functions of arity 3 or
more.
The world is moving in the direction of languages like Python, that
fit naturally with how we speak and write.
This is _so_ true, I wonder why it reminds me of the following:
"A French politician once wrote that it was a peculiarity of the
French language that in it words occur in the order in which one
thinks them."
Wittgenstein, PI 336
Bye,
Andras
Lulu of the Lotus-Eaters wrote: Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|People don't like Lisp because of misconceptions, and threads like that
|help dispel those.
In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).
You don't like Lisp because you don't like some other guy who is using it?!?
As soon as I try to learn more by reading discussions, I am bombarded
with weirdly fanatical (and very long) posts that are overwrought with
many misrepresentations (e.g. Python has "Lisp DNA", when pointedly it
does not by GvR's indication). Not that different Lispers even bother
with the same misrepresentations--just so long as they are clear that
programmers of all other languages are ignorant and stupid.
That's just your interpretation of what they say. I think both "sides"
have their fair share of beliefs that they cannot back by argument
and/or empirical assessments. Every language has features that people
have learned to appreciate because of hands-on experience. It's in fact
an esoteric experience in the truest sense of the word: one that cannot
be described in words.
I haven't actually ever used Python in practice, so I can't really tell
whether the syntax or some other features of Python will make me go
eureka when I use them. And I don't care because I already have made
that experience wrt s-expressions and macros, and I hope that I will
never have to go back to a language without macros. All the counter
arguments I have heard so far seem to be made on the basis that people
haven't made that experience yet that I am talking about. Yes, every
language feature has its dangers. What matters is whether the advantages
outweigh the dangers or not. In the case of macros, IMHO you shouldn't
guess, you should just try.
If you are really interested to find out whether macros work in practice
or not, it is extremely easy to do so. Pick one of the free commercial
or non-commercial implementations of Common Lisp, download the free book
"On Lisp" by Paul Graham from his website, try to understand what he is
saying about macros, try to write your own. Maybe you will get it, maybe
not.
These are just my opinions, they are not proven facts. Actually, I don't
really care whether you try it or not. I have made up my mind, and if
someone asks whether macros are useful or not - and this was the start
of this thread - I am going to try to share my experience.
For every discussion, you can concentrate on what are seemingly the most
extreme statements and counter them on the basis that they are too
extreme, or you can try to find out by yourself what actually hides
beneath those statements. (Or you can just ignore a topic if you're not
interested.)
Pascal
Lulu of the Lotus-Eaters wrote: In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).
Do you often let the behavior of others control how you think
about technical topics?
Paul
dan wrote: The world is moving in the direction of languages like Python
Yes, and that's a good thing.
It's a good thing because it means that static approaches are replaced
by dynamic approaches.
Pascal
Lulu of the Lotus-Eaters wrote: Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|People don't like Lisp because of misconceptions, and threads like that
|help dispel those.
In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).
So you would charge right out and use Lisp, except you do not like me?
Hmmmm....
As soon as I try to learn more by reading discussions, I am bombarded
with weirdly fanatical (and very long) posts that are overwrought with
many misrepresentations (e.g. Python has "Lisp DNA", when pointedly it
does not by GvR's indication).
I phrased that with a vague metaphor precisely to avoid saying anything
about Python's history and motivation, about which I am largely
ignorant. I have no idea where the ideas for garbage collection,
first-class functions, and a MOP came from, but Peter Norvig, a Python
fan, writes:
"Basically, Python can be seen as a dialect of Lisp with "traditional"
syntax (what Lisp people call "infix" or "m-lisp" syntax). One message
on comp.lang.python said "I never understood why LISP was a good idea
until I started playing with python." Python supports all of Lisp's
essential features except macros, and you don't miss macros all that
much because it does have eval, and operator overloading, and regular
expression parsing, so you can create custom languages that way."
That's at: http://www.norvig.com/python-lisp.html
Note that Norvig is not saying how Python ended up so close to Lisp,
just that it has. Me neither/too.
Not that different Lispers even bother
with the same misrepresentations--just so long as they are clear that
programmers of all other languages are ignorant and stupid.
Nonsense. We actually hope a few Pythonistas will come help us build up
some free libraries for Lisp to solve a weak point for us. We recognize
Pythonistas as (a) Early Adopters who (b) groove on interactive,
dynamic, powerful languages.
We are recruiting, not flaming.
Or tortured threads about things that are only possible in Lisp... but
as soon as any example is presented, it is obvious that the same thing
is not only possible, but much easier and more direct, in (some) other
languages.
It's funny this never occurred to me, but my own Cells hack uses macros
big time. Here is a before/after in which I manually macroexpanded the
code and spliced the output back into where it would have expanded:
Before:
(make-instance 'boiler1
:temp (cv 20)
:status (c? (if (< (temp self) 100)
:on :off))
:vent (c? (ecase (^status)
(:on :open)
(:off :closed))))
After:
(make-instance 'boiler1
:temp (make-c-variable :value 20)
:status (make-c-dependent
:rule (lambda (c &aux (self (c-model c))
(.cache (c-value c)))
(if (< (temp self) 100) :on :off)))
:vent (make-c-dependent
:rule (lambda (c &aux (self (c-model c))
(.cache (c-value c)))
(ecase (let ((*synapse-factory* nil))
(status self))
(:on :open) (:off :closed)))))
Some observations:
(1) This is an extreme case, because Cells is an ambitious hack. But the
principles are the same for simpler applications
(2) If I did not have macros, I could compress the above 20%, but no more
(3) Expanding the macros exposes implementation details. I use Cells a
lot, and I refactor a lot. Exposing internals is not just a theoretical
no-no, I'd be dead.
(4) So as not to overstate my case, I snipped this clause from the
actual expansion:
:code '((ecase (let ((*synapse-factory* nil))
(status self))
(:on :open) (:off :closed)))
That is just plain scary. What I am doing is not only expanding the user
code into a lambda form, but also generating /this/ code to dynamically
(at run-time) stuff the code's source (in symbolic form, what the macro
gets its hands on at compile-time) into a slot in the cell data
structure to help with debugging at crash-time. (ie, the source level
debugging on my particular implementation could be a lot better (I just
learned they are working on it) but I have anyway worked around that
with macros.
(5) Leaving aside exposed implementation (a fatal problem, mind you) "I
can do that in Python without macros" is /not/ an objection, unless the
code comes out as terse as the "before". One thing we Lispniks should
have emphasized early on is that one thing macros do is compress and
prettify the code. Surely Pythonistas will acknowledge the value of that.
(6) Paul Graham says it better: http://www.paulgraham.com/onlisp.html
kenny
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey da*******@yahoo.com (dan) writes: Lisp failed (yes, it did) because of the parentheses. Normal people
Lisp hasn't failed as long as emacs is around, and uses Lisp.
Actually, one of the problems with Lisp might be the steep learning
curve. Lisp does not offer the instant appeal of Python. The most
common initial impression of Lisp is "yuck" (parens), while w/ Python
it's mostly "wow, I didn't know code could be so readable and
powerful" (though the whitespace is sometimes an issue, the shock
might last for several minutes).
Now that neither Lisp not Python has the idustry-dominating status
(unlike Java, C++), instant appeal matters a lot. If people are
expected to hop in as a hobby, Python wins hands down. It takes just
3-4 toilet sessions (if you have the habit of reading in toilet) to
master Python, whereas w/ Lisp you have to hack the code for a
while. And still, you can't read the code fast enough; it's fast
enough to write, but reading can be painful initially (unlike perl,
where the pain lasts indefinitely).
Lisp offers a bit more power than Python (macros), but after a while
with Python, one notices that none of the power that is missing is
actually even needed. Python has just the right
features. Period. There are one or two warts (dangling variable after
list comprehensions comes to mind), but the language as a whole feels
natural. Lisp feels natural if you are writing a compiler or want to
be as orthogonal as possible, Python feels natural for most (all
except drivers/applications with extreme performance requirements) of
the real world applications.
The world is moving in the direction of languages like Python, that
fit naturally with how we speak and write.
Yes it is; that doesn't mean that Lisp would be dead after a while. At
least not until emacs supports Python natively :-). Seriously though,
Lisp is one of the more programmer centric (== least evil) languages
around, loved by programmers and shunned by the managers. If Python
(and ruby, which I view mostly as a Python with different syntax)
weren't around, Lisp would be the language of choice for most
pythoneers.
Hmm, I guess I should leave usenet alone on saturday nights, but what
the heck :-).
--
Ville Vainio http://www.students.tut.fi/~vainio24
Pascal Costanza wrote: I haven't actually ever used Python in practice, so I can't really tell
whether the syntax or some other features of Python will make me go
eureka when I use them.
FWIW, I have used Python in anger, and the textual clarity of my code
was indeed remarkable.
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Ville Vainio <vi********************@spamtut.fi> writes: Lisp offers a bit more power than Python (macros), but after a while
with Python, one notices that none of the power that is missing is
actually even needed. Python has just the right
features. Period. There are one or two warts (dangling variable
after list comprehensions comes to mind), but the language as a
whole feels natural. Lisp feels natural if you are writing a
compiler or want to be as orthogonal as possible, Python feels
natural for most (all except drivers/applications with extreme
performance requirements) of the real world applications.
No language feels more natural than Lisp. There's a real sense that
while Python was invented by a brilliant programmer, Lisp is built
into of the structure of the Universe. Bob Kanefsky's song "The
Eternal Flame" is a humor piece for sure, but it expresses that
sentiment beautifully. I can't imagine it being written about Python
or any other language than Lisp. http://www.songworm.com/lyrics/songw...rnalFlame.html
|> In my own mind, the biggest impediment to really liking Lisp is not the
|> annoying parentheses and awful syntax... it's many Lispers (especially
|> those like Tilton).
Pascal Costanza <co******@web.de> wrote previously:
|You don't like Lisp because you don't like some other guy who is using
|it?!?
Absolutely! One of the things that is greatest about Python is its
programming community, and its newsgroup. Quite apart from any matters
of syntax or semantics, or OOP vs. FP, or any of that stuff, it's a
heck of a lot nicer working in a language where you can get friendly,
helpful, informative answers to questions... and ones that lack scorn
and contempt. From what I can tell, Lisp would be a terrible choice from that POV.
Python is good, but so are, e.g., Ruby or Haskell in slightly different
ways. Perl, PHP, C++, and Java would probably be ranked in descending
order here, but still mostly positive.
The only languages I've seen with truly vindictive and nasty user
communities are Lisp... and VB. It's a strange closeness of the two.
All the more so because VB has a lot of poorly educated, not
particularly bright, user who are merely boastfully defensive about the
only thing they know. To the contrary, I clearly recognize that
Lispers--even most of the most over-the-top rude ones--are startlingly
intelligent. I'm not sure which is worse though... someone like Tilton
is easily smart enough to avoid sophistry, and yet he engages in it.
All that said, I also know that you cannot choose a language ONLY on its
user community. Obviously issues like static/dynamic typing, available
libraries, platform ports, and lots of issues cannot be brushed off.
Even speed of execution occassionally matters.
Yours, Lulu...
--
mertz@ _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis _/_/ Postmodern Enterprises _/_/ s r
..cx _/_/ MAKERS OF CHAOS.... _/_/ i u
_/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/ g s
Lulu of the Lotus-Eaters <me***@gnosis.cx> writes: The only languages I've seen with truly vindictive and nasty user
communities are Lisp... and VB.
We are a wicked gang indeed. Actually we were thrown out of the hotel
at the ILC this week because we were harrasing the other guests with
nasty lamda expressions in the elevators!
--
(espen)
Kenny Tilton <kt*****@nyc.rr.com> writes: what is sophistry?
The story goes that in ancient Greece the sophists were recognized
experts on public speaking, who took pride in being able to sway their
audience into any point of view they liked, or got paid for. (Much
like todays "spin doctors", I believe.) This in contrast to the
philosophers, who were the experts on what is True, regardless of
popularity or any pragmatics.
So sophistry usually means something like a lot of fancy talk that
isn't very helpful in establishing what is true, or important, or
right, or bestest of parens and white-space.
--
Frode Vatvedt Fjeld
Hi Lulu of the Lotus-Eaters, Kenny Tilton <kt*****@nyc.rr.com> wrote previously: |People don't like
Lisp because of misconceptions, and threads like that |help dispel
those.
In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).
Sure David. Please don't make this personal as some may be less gracious
in overlooking your failings to even post correctly indented
Python-the-language code when arguing against Lisp and its syntax:
<http://groups.google.com/groups?selm=mailman.1065550637.20363.python-list%40python.org>
Can't even insert four spaces without destroying the semantics of your
code three times in a row? I note you didn't later acknowledge the three
flaws, which indicates that you still couldn't see them when reviewing
your code:
<http://groups.google.com/groups?selm=mailman.1065555441.8896.python-list%40python.org>
You may have more numerous libraries and a larger set of groupies but you
will never have the satisfaction of using a superior language. Please let
me know if this response makes me a shining example of a "truly vindictive
and nasty" Lisp user. Posters to comp.lang.lisp are extremely likely to
receive polite and extraordinary help. For a long time all newbies to
comp.lang.lisp could expect to be humiliated. That time has passed.
Regards,
Adam da*******@yahoo.com (dan) writes: Google ate my long post, so I'll make it simple.
Lisp failed (yes, it did) because of the parentheses. Normal people
can't parse 13 close-parens easily. Functional notation is
non-intuitive and hard to read.
Damn, but I wish we'd noticed that! It would have saved us such
trouble. Who'd have thought that it was something as simple as
parenthesis?
I'm really surprised that McCarthy didn't realize this and invent some
sort of meta-language for lisp that resembled FORTRAN. Why didn't
someone with expertise in the translation of English into logical
expressions, like Vaughn Pratt for example, *do* something about this?
Perhaps we should have used curly braces?
The world is moving in the direction of languages like Python, that
fit naturally with how we speak and write.
That is to say:
world.MovingDirection = fit(we.speak() and \
we.write, fitfunctions.Naturally))
Frode Vatvedt Fjeld wrote: Kenny Tilton <kt*****@nyc.rr.com> writes:
what is sophistry?
The story goes that in ancient Greece the sophists were recognized
experts on public speaking, who took pride in being able to sway their
audience into any point of view they liked, or got paid for. (Much
like todays "spin doctors", I believe.) This in contrast to the
philosophers, who were the experts on what is True, regardless of
popularity or any pragmatics.
So sophistry usually means something like a lot of fancy talk that
isn't very helpful in establishing what is true, or important, or
right, or bestest of parens and white-space.
And it often involved asking questions, whose answers were already known.
--
Jens Axel Sřgaard
Lulu of the Lotus-Eaters <me***@gnosis.cx> writes: Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|People don't like Lisp because of misconceptions, and threads like that
|help dispel those.
In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).
Yeah, that Tilton guy....
Hey, he's not looking. Let's all join comp.lang.python and ditch him.
Lulu of the Lotus-Eaters <me***@gnosis.cx> writes: I'm not sure which is worse though... someone like Tilton is easily
smart enough to avoid sophistry, and yet he engages in it.
What can I say? Lisp attracts a more sophistricated kind of programmer.
....it could have something to do with its users.
Now, if just someone would take this thread, and put it further up than
the sun will ever reach...
--
-rune
Incognito, ergo sum.
Espen Vestre wrote: Lulu of the Lotus-Eaters <me***@gnosis.cx> writes:
The only languages I've seen with truly vindictive and nasty user
communities are Lisp... and VB.
We are a wicked gang indeed. Actually we were thrown out of the hotel
at the ILC this week because we were harrasing the other guests with
nasty lamda expressions in the elevators!
The Savages of comp.lang.lisp!
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Frode Vatvedt Fjeld wrote: Kenny Tilton <kt*****@nyc.rr.com> writes:
what is sophistry?
The story goes that in ancient Greece the sophists were recognized
experts on public speaking, who took pride in being able to sway their
audience into any point of view they liked, or got paid for.
Oh, OK, thx. That was back in '71, I realized I could argue awesomely on
either side of a debate, and spontaneously lost all interest in
debating. After then...
(Much like todays "spin doctors", I believe.) This in contrast to the
philosophers, who were the experts on what is True, regardless of
popularity or any pragmatics.
....yes, I went in search of the Tao.
kenny
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Jens Axel Sřgaard wrote: And it often involved asking questions, whose answers were already known.
Guilty! Guilty! Guilty! i did that when I asked someone about using
symbols as initargs instead of keywords on defstructs, when of course
defstruct creates the initargs without offering any overrides, so I knew
the answer: "um, no, those are keywords".
But then I felt my subterfuge would be obvious and it would be
understood to be a clever way to point out that there was a standard
practice the symbol initarg crowd was corrupting in order to calm their
package paranoia (induced by package abuse (necessitated by bad naming)).
kenny "the sophist"
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Rune Steffensen wrote: ...it could have something to do with its users.
more personal attacks? <yechh> what part of the thread subject do you
not understand? You are reading this thread voluntarily, and your only
contribution is bile. Super.
The fact is, Pythonistas are using python because Java (and C++) did not
meet their needs. ie, thy are not sheep. They think for themselves.
Lispniks consider such folk Deeply Worthy.
This thread arose (in a prior incarnation) only because Python merely
/considered/ macros. Some mis-characterizations of macros arose and a
few of us swung by to say those characterizations did not match our
experience. We (I) do not give a rat's ass if Python adopts macros, but
we have a ball with them and we thought Pythonistas should have the Best
Information before rejecting them.
kenny
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
|Kenny Tilton <kt*****@nyc.rr.com> writes:
|> what is sophistry?
Frode Vatvedt Fjeld <fr****@cs.uit.no> wrote previously:
|The story goes that in ancient Greece the sophists were recognized
|experts on public speaking, who took pride in being able to sway their
|audience into any point of view they liked...
This is a good description of the word. But I think Kenny, in this
case, was making a rather nice joke: Being sophistical by pretending
not to know the word... a slightly self-deprecating self-reference.
If so, I give him many positive points for the meta-discourse.
Yours, Lulu...
--
---[ to our friends at TLAs (spread the word) ]--------------------------
Iran nuclear neocon POTUS patriot Pakistan weaponized uranium invasion UN
smallpox Gitmo Castro Tikrit armed revolution Carnivore al-Qaeda sarin
---[ Gnosis Software ("We know stuff") <me***@gnosis.cx> ]---------------
Adam Warner <us****@consulting.net.nz> wrote previously:
|in overlooking your failings to even post correctly indented
|Python-the-language code when arguing against Lisp and its syntax:
Sure... but just imagine how badly matched my parentheses would have
been had I attempted to post Lisp code.
|You may have more numerous libraries and a larger set of groupies but
|you will never have the satisfaction of using a superior language.
Nah... I think Paul Graham has them lined up around the block, my
groupies only straggle in slowly. Still, do my callous remarks mean
that I will be blocked from downloading other programming language
distributions? Or is it just that I am too doltish to ever really enjoy
the satisfaction of CL?
|Please let me know if this response makes me a shining example of a
|"truly vindictive and nasty" Lisp user.
Not so much. I think my personal posting foibles slightly miss the
point, but the sting in observing them is in good enough humor.
Yours, David...
--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <me***@gnosis.cx> ]--------------------------
Hi David Mertz, Sure... but just imagine how badly matched my parentheses would have
been had I attempted to post Lisp code.
I suspect you pasted in validly formatted Python code:
def categorize_compose(filters, iter):
results = tuple([[] for _ in len(filters)])
for x in iter:
results[compose(filters)(x)].append(x)
return results
Before proceeding to indent it for display:
.....def categorize_compose(filters, iter):
..... results = tuple([[] for _ in len(filters)])
..... for x in iter:
..... results[compose(filters)(x)].append(x)
return results
Making this mistake will not affect the semantics of Lisp code. If you had
attempted to indent valid Lisp code you could not have made the same
mistake.
Even if you ultimately remember to indent everything correctly for display
you are still changing the semantics of the program with every interim
indentation change (and an interim failure could leave you with invalid
code). A related issue is moving a block of Python code within a program
and having to fix indentation of every line in the block to avoid changing
its original semantics.
Lisp parentheses combined with form analysis provide enough information to
automatically reformat any arbitrary block of code. Lisp's parentheses and
syntax are one of Lisp's greatest assets (and they also support effortless
code generation). One could say Lisp's syntax is essential for achieving
these aims. One could also say Python's syntax is essential for achieving
its aesthetic aims and markedly distinguishing it from other programming
languages.
Regards,
Adam
|I suspect you pasted in validly formatted Python code:
|Before proceeding to indent it for display:
Nah... that's not the specific error I made. It's plausible, sure. But
I rather hastily wrote the code directly in my newsreader, rather than
in a Python shell or Python-aware editor (and made some other
non-indentation errors in the process too).
Of course, then I copied the same function a couple times to create
variations of the behavior... never noticing the error in each of them.
Definitely a kicking myself moment (as I wrote in the subsequent post...
admittedly not belaboring every individual error).
I -did- do a little bit of Scheme programming lately (I guess before I
was barred from all future downloads :-)). Admittedly, this was
starting from little familiarity with the language (and also I cannot
get my little brain around emacs, and jEdit on my Powerbook doesn't seem
to want to reindent for me--maybe there's a plugin to do that).
I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of misplaced
parentheses (most of the rest were from a fuzziness about the different
between strings and symbols; but I think I've worked that out). I sure
had to stare a LOT longer at those parens (and do lots of counting on my
fingers) than I would have had to look at wrongly indented Python code.
In fact, this much would be true even compared to way back during my
first few weeks of Python programming.
But maybe that error will go away over time. I have some doubts, but
also an open mind.
Yours, David...
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
Hi David Mertz, |I suspect you pasted in validly formatted Python code:
|Before proceeding to indent it for display:
Nah... that's not the specific error I made. [...]
OK!
I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of misplaced
parentheses (most of the rest were from a fuzziness about the different
between strings and symbols; but I think I've worked that out). I sure
had to stare a LOT longer at those parens (and do lots of counting on my
fingers) than I would have had to look at wrongly indented Python code.
In fact, this much would be true even compared to way back during my
first few weeks of Python programming.
There is not one single gratuitous parenthesis in Lisp. But there are a
number of special forms and before those become hard coded into the brain
it's confusing. For example, consider LET:
(let ((symbol value))
...)
The binding of the symbol to the value is nested within another set
of parentheses because LET handles multiple bindings:
(let ((symbol1 value1)
(symbol2 value2))
...)
There is another less commonly used variation of LET that binds every
symbol to NIL, i.e.:
(let (symbol1 symbol2)
...)
Is shorthand for:
(let ((symbol1 nil)
(symbol2 nil))
...)
After one internalises _why_ each parenthesis is included everything falls
into place. Before that point the parentheses feel like line noise instead
of critical structure. The next step comes with automatic (re-)indentation
of code. To see a fault in a program one can just look at the indentation.
It's at this final point that the parentheses fade from consciousness
(incorrect indentation indicates a problem!)
Code may be slightly more verbose because of the parentheses but they also
encode some of the information required to reconstruct the formatting
of the code. Not having to manually reformat a function (I just press
C-M-q) is a big win.
As this reply was solely about (Common) Lisp I've set the followup-to
comp.lang.lisp only. But I also replied to comp.lang.python so you could
see my reply.
But maybe that error will go away over time. I have some doubts, but
also an open mind.
Everyone begins with doubts about Lisp, and the doubts easily intensify
before there is any obvious payback.
Regards,
Adam
Lulu of the Lotus-Eaters <me***@gnosis.cx> wrote in message news:<ma*************************************@pyth on.org>... As soon as I try to learn more by reading discussions, I am bombarded
with weirdly fanatical (and very long) posts that are overwrought with
many misrepresentations (e.g. Python has "Lisp DNA", when pointedly it
does not by GvR's indication). Not that different Lispers even bother
with the same misrepresentations--just so long as they are clear that
programmers of all other languages are ignorant and stupid.
It is very strange. The Pythonista in me wonders if Common Lispers
(as a whole) realize what appeals to Python users. But then, their
most coherent marketing story is an attempt to reach those attracted
to Python for its powerful nature, not necessarily the mainstream
Python user.
The big appealing argument in favor of macros is with-open-files. You
set up a block, and the power of macros close the file automagically
when you're done. None of this try/finally madness. The try/finally
is hidden inside the macro.
So you basically have something like:
with_open_file f (filename, 'r'):
# read from f, do what you want;
# once you leave the block it will be autoclosed!
# Even if the clever user reassigns f it will be closed!
(In fact, I keep on wanting to describe Emacs's save-excursion as a
fantasy that you wake up from at the end. The system protects you
from the likely negative consequences of your actions.)
Alex Martelli argued that macros create hidden things that affect code
at-a-distance. But there are CL tools to fix this! I just used
macroexpand to see what with-open-file "really" becomes.
macroexpand(with_open_file f (filename, 'r')) would become something
like:
try:
unique_temp = open(filename, 'r')
f = unique_temp
# do work here with f
finally:
if unique_temp:
unique_temp.close()
Now, I don't know if macros can seriously be done within Python, it's
just a demonstration on how safe macros can make a language.
Another nicety of the lisps is you can have almost whatever names you
like, for functions and variables. Something like "number->string"
could be a name of a function that converts a number into a string.
Everyone gets those destructive Python functions like list.sort()
wrong at first, thinking that it returns a list. Why not have it be
sort!() for something that returns None? Of course, many of these
names would be up to kindly people like Guido & Co, so that coherent
guidelines could ripple through the Python continuum.
It's not absolutely clear if Common Lisp is readable in the small. I
believe the normal CL argument is about readability in the large,
since the Lisps have good abstraction facilities. (This way, you can
"name" nasty pieces of code with simple representations.) Scheme is
very readable in the small; but it's unclear whether it will evolve a
highly used Lisp anytime soon. But in terms of WRITING code, I prefer
Common Lisp even though Python's nicer to read. So a lot of CL is
invisible. In particular, the difficulty of reading CL may be partly
due to CLers removing patterns whenever they come up.
Anyway, just my opinion, as someone with the Pythonic and Lisp DNA.
On Sun, 19 Oct 2003 03:59:07 -0400, me***@gnosis.cx (David Mertz) wrote: I -did- do a little bit of Scheme programming lately (I guess before
I was barred from all future downloads :-)). Admittedly, this was
starting from little familiarity with the language (and also I
cannot get my little brain around emacs, and jEdit on my Powerbook
doesn't seem to want to reindent for me--maybe there's a plugin to
do that).
I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of
misplaced parentheses (most of the rest were from a fuzziness about
the different between strings and symbols; but I think I've worked
that out). I sure had to stare a LOT longer at those parens (and do
lots of counting on my fingers) than I would have had to look at
wrongly indented Python code. In fact, this much would be true even
compared to way back during my first few weeks of Python
programming.
It is my experience that this definitely goes away very quickly if
you're actually using the language. When I started with Lisp some
years ago I initially had some problems with things like DO, LET, or
COND. It seemed to me as if I would forever have to look up the
definition and count the parens before I could use one of these.
It turned out that this only lasted for a couple of days. In fact,
once you get it, you realize that every single form in Lisp has
exactly the right number of parentheses and as long as you know the
arglist (tools like ILISP will help with that) it's a no-brainer to
know how many parens you'll need. Plus, should I ever make a mistake
with parens I'll notice immediately after hitting RETURN because Emacs
will get the indentation wrong.
As others have pointed out it is _essential_ to use Emacs or an Emacs
clone (like Hemlock or the editors coming with the commercial Lisps)
if you're going to write Lisp programs. Your editor should be able to
at least get the indentation right automatically, it should be able to
show matching parentheses, and it should feature a couple of
convenient ways to navigate through s-exps and lists, see for example
<http://www.google.com/groups?selm=d6d7ef84.fsf%40ccs.neu.edu>.
Edi.
On Sun, 19 Oct 2003 13:18:38 +0200, Edi Weitz wrote: In fact, once you get it, you realize that every single form in Lisp
has exactly the right number of parentheses and as long as you know the
arglist (tools like ILISP will help with that) it's a no-brainer to know
how many parens you'll need.
The problem is not that I don't know why each paren is there. I know it.
It doesn't help with the fact that there are a lot of them and that code
is not easily readable because of deep nesting.
As others have pointed out it is _essential_ to use Emacs or an Emacs
clone (like Hemlock or the editors coming with the commercial Lisps)
if you're going to write Lisp programs.
What about reading (in books, on WWW)? I guess you would say
"indentation"...
Indentation in Lisp is not clear enough. Let's look at an example from http://www-users.cs.umn.edu/~gini/ai...m/onlisp.lisp:
(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.
Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):
def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};
| Lisp | Python | above
-------------------------------------------+------+--------+-------
different amounts of indentation | 10 | 4 | 3
at the beginnings of lines | | |
| | |
maximum number of nested parens | 9 | 1 | 4
| | |
maximum number of adjacent closing parens | 5 | 1 | 2
| | |
total number of parens | 60 | 16 | 18
where paren = ()[]{} | | |
This is why I don't find Lisp syntax readable. It requires apparently
3 times more complicated nesting structure to express the same thing.
--
__("< Marcin Kowalczyk
\__/ qr****@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Lulu of the Lotus-Eaters wrote: |Kenny Tilton <kt*****@nyc.rr.com> writes:
|> what is sophistry?
Frode Vatvedt Fjeld <fr****@cs.uit.no> wrote previously:
|The story goes that in ancient Greece the sophists were recognized
|experts on public speaking, who took pride in being able to sway their
|audience into any point of view they liked...
This is a good description of the word. But I think Kenny, in this
case, was making a rather nice joke: Being sophistical by pretending
not to know the word... a slightly self-deprecating self-reference.
I was reaching for my dictionary when it occurred to me that coming
clean on my ignorance was the best response/joke I could make. See sig
for my exemplar (whatever that means).
kenny
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
"I don't know what 'truculent' means, but if it's good, that's me."
-- Muhammad Ali, without missing a beat, after Howard Cosell
remarked on Ali's sullenness during an interview.
Francis Avila wrote: Procedural, imperative programming is
simply a paradigm that more closely matches the ordinary way of thinking
(ordinary = in non-programming, non-computing spheres of human endevor) than
functional programming.
There is no such thing as "the" ordinary way of thinking, except in
the mind of people who have not enquired enough about the ways of thinking
of other people to discover this "astonishing" fact - but I will concede that
failure to enquire is more likely to occur among adepts of procedural and
imperative authority (authority - not thinking).
This said, I find it a bit ridiculous to oppose lisp and python along that
scale; compared to logic programming (eg Prolog), or even to reverse-polish
stack-based syntax like in PostScript - and given that both python and lisp
are dynamic and don't require types declarations - programming in python and
programming in lisp feel very similar (except for a few things you can do in
lisp but not in python).
.... The same reason why programmers call lisp "mind-expanding" and "the latin of
programming languages" is the very same reason why they are reluctant to
learn it--its different, and for many also hard to get used to.
Everybody finds one's own mother's style of cooking more palatable, but that's
no excuse to reflect on things as if everybody had the same mother.
Python doesn't try (too) hard to change the ordinary manner of thinking,
just to be as transparent as possible. I guess in that sense it encourages a
degree of mental sloth, but the objective is executable pseudocode.
Python and lisp imho compete for the status of easiest language to program in;
python differs from lisp in that in leaves you less freedom to shoot yourself
in the foot with meta-programming (having access to code as an easy data
structure, something Prolog has too). And python also has for itself a free
reference implementation running on all platforms, with an extensive standard
lib (that's why I use it rather than lisp).
Lisp
counters that thinking the lisp way may be harder, but the power it grants
is out of all proportion to the relatively meager investment of mental
energy required--naturally, it's hard to convince someone of that if they
don't actually _use_ it first, and in the end some will probably still think
it isn't worth the trouble. It will take very significant and deep cultural
and intellectual changes before lisp is ever an overwhelmingly dominant
language paradigm.
The real issue is what language gets taught to beginners and what language is
required by employers, and such choices are mostly historical accidents of fad
and fashion.
That is, when it becomes more natural to think of
cake-making as
UD: things
Gxyz: x is baked at y degrees for z minutes.
Hx: x is a cake.
Ix: x is batter.
For all x, ( (Ix & Gx(350)(45)) > Hx )
(i.e. "Everything that's a batter and put into a 350 degree oven for 45
minutes is a cake")
...instead of...
1. Heat the oven to 350 degrees.
2. Place batter in oven.
3. Bake 45 minutes
4. Remove cake from oven.
(i.e. "To make a cake, bake batter in a 350 degree oven for 45 minutes")
This is not serious. Write down a piece of idiomatic python, and I'm sure some
lisper will show you how well lisp can mimic that.
...then lisp will take over the universe. Never mind that the symbolic
logic version has more precision.
Lisp isn't symbolic logic. Symbolic logic isn't the example you gave.
Marcin 'Qrczak' Kowalczyk wrote: Indentation in Lisp is not clear enough. Let's look at an example from
http://www-users.cs.umn.edu/~gini/ai...m/onlisp.lisp:
(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.
Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):
def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};
Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
another verson in Common Lisp (and this is not a dream language ;):
(defmethod mostn (fn (list (eql nil)))
(declare (ignore fn list))
(values nil nil))
(defmethod mostn (fn list)
(loop with result = (list (car list))
with max = (funcall fn (car list))
for object in (cdr list)
for score = (funcall fn object)
when (> score max) do (setq max score
result (list object))
when (= score max) do (push object result)
finally return (values (nreverse result) max)))
Pascal
Paul F. Dietz wrote:
Do you often let the behavior of others control how you think
about technical topics?
In a stretched sense of "to control" and "to think" such as is implied by
context, I start with ridding myself of any illusion that my manner of
"thinking about" technical topics could be free from any "control" by the
behavior of other people.
Frode Vatvedt Fjeld wrote: Kenny Tilton <kt*****@nyc.rr.com> writes:
what is sophistry?
The story goes that in ancient Greece the sophists were recognized
experts on public speaking, who took pride in being able to sway their
audience into any point of view they liked, or got paid for. (Much
like todays "spin doctors", I believe.) This in contrast to the
philosophers, who were the experts on what is True, regardless of
popularity or any pragmatics.
So sophistry usually means something like a lot of fancy talk that
isn't very helpful in establishing what is true, or important, or
right, or bestest of parens and white-space.
In Zen and the Art of Motorcycle Maintenance, Robert Pirsig discusses the
philosopher vs sophist debate and to some extent resurrects the honor of
the sophists. According to Pirsig, the sophists thought the most important
question was 'What is Good?'. The philosophers thought the more important
question was 'What is Truth?'. The philosophers seem to have won the
debate, at least in the West. And as they say, the victors write the
history books, so sophistry came to mean fancy arguments intended to evade
or obscure the truth.
For good or ill, the history of western civilization has been driven in
large part by that outcome. In almost every field of human endeavor, we
have brilliant technical solutions to almost every problem. All too often,
the solution only creates another problem. A modern day sophist (a real
one, not the snake oil salemen who have inherited the name) might say with
a certain smugness, "A clever man will do what makes sense, even if it
isn't any good. A wise man will do what is good, even if it doesn't make
any sense."
--
budr at netride dot net
Pascal Costanza <co******@web.de> writes: Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
another verson in Common Lisp (and this is not a dream language ;):
(defmethod mostn (fn (list (eql nil)))
(declare (ignore fn list))
(values nil nil))
(defmethod mostn (fn list)
(loop with result = (list (car list))
with max = (funcall fn (car list))
for object in (cdr list)
for score = (funcall fn object)
when (> score max) do (setq max score
result (list object))
when (= score max) do (push object result)
finally return (values (nreverse result) max)))
C'mon guys, live a little,
(defun mostn (fn list)
(let ((max (apply #'max (mapcar fn list))))
(values (remove max list :test-not #'= :key fn) max)))
-Luke
Pascal Costanza wrote:
Marcin 'Qrczak' Kowalczyk wrote:
Indentation in Lisp is not clear enough. Let's look at an example from
http://www-users.cs.umn.edu/~gini/ai...m/onlisp.lisp:
(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.
Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):
def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};
Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
another verson in Common Lisp (and this is not a dream language ;):
(defmethod mostn (fn (list (eql nil)))
(declare (ignore fn list))
(values nil nil))
(defmethod mostn (fn list)
(loop with result = (list (car list))
with max = (funcall fn (car list))
for object in (cdr list)
for score = (funcall fn object)
when (> score max) do (setq max score
result (list object))
when (= score max) do (push object result)
finally return (values (nreverse result) max)))
i must admit, that i share this imputed aversion. you see, loop does something
counterproductive in the conventional formatting: it makes language constructs
which have different semantics and/or different scope appear similar. this is
something which m.kowalczyk, despite the thougtful exposition, fails to
understand. to have not been able to characterize the respective indentation
with any more precision than "in the middle of lines" indicates a deficiency
in reading comprehension.
there is a difference between an operator, an argument, a binding, an
antecedant, a consequent, etc. the conventional lisp indentation enables the
literate reader to assign these roles directly upon comprehending the operator
and - surprise, surprise - the indentation, and without having to comprehend
the content of the dependant form. this means that the reader need attend to
the dependant form only if that is their actual focus.
the form of the loop macro interfers with this.
as does the conventional formatting of the posted python example.
ps, if the cond is that simple, one might consider (cond ((> score max) (setq max score result (list obj)))
((= score max) (push obj result)))))
....
On Sun, 19 Oct 2003 17:22:17 +0200, Luke Gorrie wrote: C'mon guys, live a little,
(defun mostn (fn list)
(let ((max (apply #'max (mapcar fn list))))
(values (remove max list :test-not #'= :key fn) max)))
I can write it shorter that way in Python and in my language too, and it's
not even equivalent because it applies fn twice for each element, so my
point stands.
Yours would be a valid point if Lisp provided a significantly different
paradigm. But it was about the syntax of function calls, local variables,
loops, conditionals, variables etc. which are about as common in Lisp as
in those languages.
def mostn(fn, list):
Max = max(map(fn, list))
return [x for x in list if fn(x) == Max], Max
def mostn Fn List {
let Max = map List Fn->maximum;
select List ?X {Fn X == Max}, Max
};
--
__("< Marcin Kowalczyk
\__/ qr****@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
"Edi Weitz" <ed*@agharta.de> wrote in message
news:87************@bird.agharta.de... It turned out that this only lasted for a couple of days. In fact,
once you get it, you realize that every single form in Lisp has
exactly the right number of parentheses and as long as you know the
arglist (tools like ILISP will help with that) it's a no-brainer to
know how many parens you'll need.
Last night I accepted the repeated suggestion to download and read
(some of) OnLisp. Problem: I *don't* know the arglist structure of
every form Graham uses, and since Graham assumes such knowledge, I had
to count parens to reverse engineer function prototypes and determine
what is an argument to what. A Python beginner would more easily do
this with Python code.
What is ILISP. Is there a usable online CL reference that would let
me lookup, for instance, DO and get the prototype and short
description?
I will admit that after a few chapters, the parens did begin to fade a
bit. They are a surface issue. I think some others are more
important.
As others have pointed out it is _essential_ to use Emacs or an
Emacs clone (like Hemlock or the editors coming with the commercial Lisps)
if you're going to write Lisp programs. Your editor should be able
to at least get the indentation right automatically, it should be able
to show matching parentheses,
Lisp-aware editors do not solve the problem of reading Lisp code
embedded in text, as with OnLisp formatted .ps or .pdf.
Terry J. Reedy This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: RobertMaas |
last post by:
After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways. Each has a decent size library of useful utilities...
|
by: mike420 |
last post by:
I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro...
|
by: nobody |
last post by:
This article is posted at the request of C.W. Yang who
asked me to detail my opinion of Lisp, and for the benefit
of people like him, who may find themselves intrigued by
this language.
The...
|
by: nobody |
last post by:
Howdy, Mike!
mikecoxlinux@yahoo.com (Mike Cox) wrote in message news:<3d6111f1.0402271647.c20aea3@posting.google.com>...
> I'm a C++ programmer, and have to use lisp because I want to use
>...
|
by: Mark Tarver |
last post by:
How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?
Note I'm not a Python person and I have no axes to grind here. This is
just a question for...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| |
