Why is Python popular, while Lisp and Scheme aren't?
Oleg
I don't know much about Python, but I looked at this comparison
between Python and Common Lisp (
http://www.norvig.com/python-lisp.html ), and I couldn't help but
wonder why Python is popular, while Common Lisp and Scheme aren't?
Oleg
Tony
appeals to people who like to deliver software.
Lisp has been the mainstay of a lot of traditional AI courses for donkeys
years, Python has been picked up by a lot of the new generation of
programmers who learnt their trade on scripted web applications and needed
something quick, clear and flexible to get the job done as quickly and
painlessly as possible.
I'm not at all familiar with Scheme.
"Oleg" <oleg_i...@myrealbox.com> wrote in message
news:3d5b5ad8.02110...@posting.google.com...
Matthias Heiler
Python comes with a set of really usefull libraries, so you can do many
interesting things easily. For many people this more than compensates for
its slow execution time (compared to compiled common lisp). Open-source
libraries for common lisp are rare. Scheme doesn't even define how a
"library" should look like.
A second reason for Python's popularity might be that the Python community
is particularly friendly towards beginners.
Matthias
Eddie Corns
>Hi
My opinion (the short version anyway) is that because Python is a lot easier
to learn and use. It's a bit like the difference between a point and click
camera and a 'real' one - to use a 'real' camera for even a simple photo you
need to understand the whole biz. However, unlike some languages I won't
mention, Python does its best to give the max. power (of Scheme,Haskell etc.)
for the max. ease of use.
Eddie
Jeff Sandys
>
> ... I couldn't help but wonder why Python is popular,
One reason is that Python has a lower threshold for learning.
We can get a non-programmer productive in Python in 8-16 hours
of training, but it takes 24-40 hours of training for Lisp.
My personal view: Lisp is more powerful, Python is more fun.
Thanks,
Jeff Sandys
Michal Kaukic
>
> Python comes with a set of really usefull libraries, so you can do many
> interesting things easily. For many people this more than compensates for
> its slow execution time (compared to compiled common lisp). Open-source
> libraries for common lisp are rare. Scheme doesn't even define how a
> "library" should look like.
>
> A second reason for Python's popularity might be that the Python community
> is particularly friendly towards beginners.
>
It seems to me that Lush (http://lush.sourceforge.net) has the potential to be really useful.
And, the developers mention "bindings to the JavaVM API and to the Python C API"
(as I can see, this is yet not here, but things are rapidly changing in CVS everyday).
The symbiosis of Lisp and Python can be very interesting...
Mike
------------------------------------------------------------------------
Michal Kaukic (mi...@frcatel.fri.utc.sk)
Dept. of Math. Methods, Fac. of Manag. & Informatics
University of Zilina, Slovak Republic
Tim Lavoie
TG> My guess is that Lisp appeals to people who like predicate
TG> logic and Python appeals to people who like to deliver
TG> software.
TG> Lisp has been the mainstay of a lot of traditional AI courses
TG> for donkeys years, Python has been picked up by a lot of the
TG> new generation of programmers who learnt their trade on
TG> scripted web applications and needed something quick, clear
TG> and flexible to get the job done as quickly and painlessly as
TG> possible.
TG> I'm not at all familiar with Scheme.
My guess is that Lisp doesn't appeal to those who fear anything which
"looks funny", and Python delivers some of the same benefits without
scaring anybody.
New programming languages affect the way you think, some more
gradually than others. Python gives you a little syntax to get over at
first, but the funkier bits can lurk in the background until the user
is ready for them. Lisp is more of a leap at first, but popularity
aside, the mental exercise would do some good. Even if they decide not
to use it, people will have still learned something. Ditto for lots of
other languages too, especially the stranger ones. I still haven't
figured out how to slide some Intercal in at work though... :)
--
Pascal is a language for children wanting to be naughty.
-- Dr. Kasi Ananthanarayanan
Paul Sage
language for computer game work, my feelings about the two are very
different.
I remember LISP was cool in that we could do some neat math proofs with
it, and it had applications that made formula translation (textbook to
code) quick and nifty. However, LISP also was not obvious to me as a
'real-world' language because it just always felt like I had to recreate
the wheel when I used it for anything applicable to a real world
application. We also nicknamed LISP - Little, Insignificant, Stupid
Parentheses. Maybe that holds as my most common complaint, it was darn
hard to read someone else's LISP code quickly.
Python on the other hand has been pretty easy to pick up for the tasks I
need it to do. I have been surprised at just how easy I can do
something useful quickly. The other night I wrote a quick few lines of
code to move files around without even thinking about it.
In all fairness, my impression of LISP was based around a language I had
to learn in college and the tasks that were assigned to me. Python is a
language we are using at work, so I spend more time trying to figure out
what it can do in the real world.
Note, by no means am I a software engineer. I'm just an average Joe who
is mucking around, so that is my average Joe impression.
> -----Original Message-----
> From: Oleg [mailto:oleg_i...@myrealbox.com]
> Sent: Friday, November 08, 2002 6:54 AM
> To: pytho...@python.org
> Subject: Why is Python popular, while Lisp and Scheme aren't?
>
> Hi
>
> I don't know much about Python, but I looked at this comparison
> between Python and Common Lisp (
> http://www.norvig.com/python-lisp.html ), and I couldn't help but
> wonder why Python is popular, while Common Lisp and Scheme aren't?
>
> Oleg
> --
> http://mail.python.org/mailman/listinfo/python-list
Eddie Corns
> I still haven't
>figured out how to slide some Intercal in at work though... :)
Intercal! don't be such a wuss - have a look at
http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/
Eddie
Eddie Corns
Too easy - try <http://galileo.spaceports.com/~bwrhodes/bfi.py>
Seen that :)
and most of the others.
And as for those extensions - a language that needs integers just isn't
trying.
There's probably not much to choose between them really but I prefer
functional style.
Eddie
David Garamond
one sentence: "syntax matters." for people in denial, make it two: "yes
it really does."
or, rephrased: indentation and "1+1" scare people less than parentheses
and "(add 1 1)" or something like that.
but perhaps if lisp were invented thousands of years ago before math and
the plus (+) operator...
--
dave
Simon Brunning
> Intercal! don't be such a wuss - have a look at
> http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/
Cheers,
Simon Brunning
TriSystems Ltd.
sbru...@trisystems.co.uk
-----------------------------------------------------------------------
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot
accept liability for statements made which are clearly the senders own.
Tim Lavoie
Eddie> Tim Lavoie <tool...@spamcop.net> writes:
>> I still haven't figured out how to slide some Intercal in at
>> work though... :)
Eddie> Intercal! don't be such a wuss - have a look at
Eddie> http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/
Heheh. Yeah, that's even better. I checked out the Fibonacci example:
```s``s``sii`ki
`k.*``s``s`ks
``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
`k``s`ksk
All I can think of is that it represents the sound of someone gagging
on their respirator... :)
On the other hand, it might be fun to write a program that writes
Unlambda code, 'cause I sure don't want to read it.
--
The church is near but the road is icy; the bar is far away but I will
walk carefully.
-- Russian Proverb
Just
ed...@holyrood.ed.ac.uk (Eddie Corns) wrote:
> My opinion (the short version anyway) is that because Python is a lot easier
> to learn and use. It's a bit like the difference between a point and click
> camera and a 'real' one - to use a 'real' camera for even a simple photo you
> need to understand the whole biz. [ ... ]
Nice analogy!
Just
Jay O'Connor
Garamond" <davega...@icqmail.com> wrote:
> Oleg wrote:
>> I don't know much about Python, but I looked at this comparison between
>> Python and Common Lisp (
>> http://www.norvig.com/python-lisp.html ), and I couldn't help but
>> wonder why Python is popular, while Common Lisp and Scheme aren't?
>
> one sentence: "syntax matters." for people in denial, make it two: "yes
> it really does."
>
> or, rephrased: indentation and "1+1" scare people less than parentheses
> and "(add 1 1)" or something like that.
Yes, I was a Python advocate in a TCL shop for awhile and had a hard time convincing
people that there was a qualitative difference between.
set x [lindex [lindex $var 5] 5]
and
x = var[5][5]
--
Jay O'Connor
joco...@cybermesa.com
http://www.r4h.org/r4hsoftware
Cameron Laird
Jay O'Connor <joco...@cybermesa.com> wrote:
.
.
.
>Yes, I was a Python advocate in a TCL shop for awhile and had a hard
>time convincing
>people that there was a qualitative difference between.
>
>set x [lindex [lindex $var 5] 5]
>
>and
>
>x = var[5][5]
.
.
Tcl has definite problems that are close to what this
example expresses. Somebody's tilting the idiomatic
playing field, though; the experienced Tcl-ers I know
would write
set x $var(5,5)
rather than deal with the monstrosity above.
What makes Tcl look bad is
set rounded [expr int(a + 0.5)]
vs.
rounded = int(a + 0.5)
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Fernando Pérez
Flawed analogy, I think.
I'd rather say: python is like a modern SLR with full auto modes: you can use
it like a point'n'shoot, but still get very good results and the benefit of
good lenses and a sophisticated exposure system. But once you move the dial
to the 'manual' zone (P,Tv,Av,M for the photo-buffs) you are on your own,
with as much control as you want (from simple adjustments in P to full manual
in M).
So in python the beginner feels comfortable, but he can grow into
sophisticated things without the tool _ever_ getting in his way. That's why
the point'n'shoot analogy is bad: in that case, the tool gets in your way and
limits what you can do.
If you want, Pascal is the point'n'shoot of programming languages: easy for
beginners, utterly useless for serious work (yes, I wrote tons of pascal back
in the day, so I know what I'm talking about).
Lisp feels more like a viewcamera. You can't get _anything_ done unless you
understand the fundamentals very well. But if you do, there are some very
fancy things you can do.
Cheers,
f.
Jay O'Connor
<cla...@lairds.com> wrote:
> In article <20021108.115059...@cybermesa.com>, Jay O'Connor
> <joco...@cybermesa.com> wrote:
> .
> .
> .
>>Yes, I was a Python advocate in a TCL shop for awhile and had a hard
>>time convincing
>>people that there was a qualitative difference between.
>>
>>set x [lindex [lindex $var 5] 5]
>>
>>and
>>
>>x = var[5][5]
> .
> .
> .
> Tcl has definite problems that are close to what this example expresses.
> Somebody's tilting the idiomatic playing field, though; the experienced
> Tcl-ers I know would write
> set x $var(5,5)
> rather than deal with the monstrosity above.
Unfortunately the code I was dealing with was using lists of lists of
lists nested many, many levels deep with no documentation in the code as
to why '5' was a particular field.
Try hundreds to thousands of lines of 'the monstrosity above'
Joerg Woelke
Tim Lavoie wrote:
>
> >>>>> "Eddie" == Eddie Corns <ed...@holyrood.ed.ac.uk> writes:
>
> Eddie> Tim Lavoie <tool...@spamcop.net> writes:
> >> I still haven't figured out how to slide some Intercal in at
> >> work though... :)
>
> Eddie> Intercal! don't be such a wuss - have a look at
> Eddie> http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/
>
> Heheh. Yeah, that's even better. I checked out the Fibonacci example:
>
> ```s``s``sii`ki
> `k.*``s``s`ks
> ``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
> `k``s`ksk
[ snip ]
*ROTFL*
You may have a look at brainfuck:
"http://koeln.ccc.de/projekte/brainfuck/index-e.html"
You gonna like it.
<quote>
Brainfuck is an incredibly easy to learn and incredibly annoying to
program in language, most probably created around 1993. Its author is
Urban Müller from Switzerland, who also wrote the
original interpreter for brainfuck and a compiler for the Amiga.
</quote>
HTH, J"o!
--
sigfault
Cameron Laird
.
.
You have my sympathy. Are you making a subtle point
that Tcl invites bad coding? What you describe sounds
like the moral equivalent of a Pythoneer writing
i = 0
while 1:
if i < 73:
break
i = i + 1
...
rather than
for i in range(limit):
...
I'm little inclined to fault Python when people misuse
it so (and they do).
George Demmy
Close...
Common Lisp is to Python as the Nikon factory is to the D1* ;)
This is lighthearted introspection... not a troll! I use the D1/Python
*much* more often than do I *make* cameras and build systems on top of
CL...
Regards
* D1 is one of Nikon's nifty digital SLRs.
--
George Demmy
Eddie Corns
>Eddie Corns wrote:
>Flawed analogy, I think.
Obviously one doesn't want to push an analogy too far but anyway it depends on
what you think of as 'manual', I'm thinking call/cc and roll your own OO
systems and ... A modern point'n'shoot will allow you to do many of the
things real professionals do (I hope so anyway I'm about to buy one!) but not
the most extreme. Likewise there are things Scheme can do that would be crazy
to try in Python. Perhaps I'm being optimistic about the capabilities of
modern p'n's cameras but my impression is most of us wouldn't really want to
venture much outside what they can do - so they don't get in the way.
Anyway, that's my say on the topic - now it's time to go home and feed the
cat.
Eddie
Jay O'Connor
<cla...@lairds.com> wrote:
No, I'm making the point that TCL is syntactically weaker at expressing
complex structures and this is a qualitative difference between the two
languages
Expanding beyond just getting a single value from a multidimensional list
is what happens when you start throwing in lrange for slicing and other
ways of unwrapping the structure. TCL's approach of using 'functionName
$var1 var2' leads quite easily and naturally to such 'monstrosities' as a
natural consequence of the stucture of the language. When you start
throwing in heterogenous structures, especially dealing with nested
arrays (dictionaries) , etc..the syntactical shortcut doesn't scale very
well to dealing with complex data. (incidentally, your example does not
do the same thing.
set l1 "1 2 3"
set l2 "4 5 6"
set l3 [list $l1 $l2]
set x [lindex [lindex $l3 1] 1]
puts $x
results in '5'
using 'set x(1,1)
results in an error
> What you describe sounds like the moral equivalent of a
> Pythoneer writing
> i = 0
> while 1:
> if i < 73:
> break
> i = i + 1
> ...
> rather than
> for i in range(limit):
If limit is a variable based on conditions within the loop, then your
first example is a valid way of expressing counting until a conditional
is reached. Or, under circumstances, the basic approach is valid and
would only be 'wrong' in the situation where the loop end was static.
Dennis Lee Bieber
I have to wonder about any paper that describes Python as being like
LISP except with in-fix notation...
By that loose definition, ALL languages are like LISP... (which, at a
root, is true, since they all can be equated to a Turing machne <G>).
However, I'd find it more reasonable to declare the Forth is like LISP
-- except backwards <G>
--
> ============================================================== <
> wlf...@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulf...@dm.net | Bestiaria Support Staff <
> ============================================================== <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <
Fernando Pérez
> A modern point'n'shoot will allow you to do many of the
> things real professionals do (I hope so anyway I'm about to buy one!) but
> not
> the most extreme. Likewise there are things Scheme can do that would be
> crazy
> to try in Python. Perhaps I'm being optimistic about the capabilities of
> modern p'n's cameras but my impression is most of us wouldn't really want to
> venture much outside what they can do - so they don't get in the way.
P&S cameras are ok, but their _control_ is fairly limited to none. Some (like
the Oly Stylus Epic) have excellent optics, others have crappy optics (pretty
much all zoom cameras, you just can't make a decent zoom of that size,
physics gets in the way).
If you just want convenience for 4x6 prints from negative, a P&S is fine. But
even a basic SLR like a Canon Rebel is about as easy to use as a P&S, while
allowing you to 'go manual' when you feel like it. What you can't do with a
P&S is to set manually the aperture or speed to what _you_ want, you have to
let the camera decide what it thinks is best.
I learned the techical side of photo taking like that (making _interesting_
pictures is a different story :). I bought a Pentax ZX-5N and used it in auto
modes at the beginning, paying attention to the decisions made by the camera.
Then I started experimenting by changing things a bit. These days I never use
it in full auto, except when I'm in a big hurry or need to give it to someone
else.
Cheers,
f.
ps. The above doesn't quite apply to 'prosumer' digital P&S like the Canon
G2/G3. Because the sensor is so small, those cameras actually have decent
zooms. And they also have all the manual controls typical of an SLR. That's
because it's the only way the companies can sell to the market who wants
manual control but can't afford a 2k-8k true digital SLR.
Jay O'Connor
<joco...@cybermesa.com> wrote:
Typo
> set l1 "1 2 3"
> set l2 "4 5 6"
> set l3 [list $l1 $l2]
> set x [lindex [lindex $l3 1] 1]
> puts $x
>
> results in '5'
>
> using 'set x(1,1)
> results in an error
The actual code is
set x $l3(1,1)
which results in
Error: can't read "l3(1,1)": variable isn't array
while executing
"set x $l3(1,1)"
Cameron Laird
>complex structures and this is a qualitative difference between the two
>languages
>
>Expanding beyond just getting a single value from a multidimensional list
>is what happens when you start throwing in lrange for slicing and other
>ways of unwrapping the structure. TCL's approach of using 'functionName
>$var1 var2' leads quite easily and naturally to such 'monstrosities' as a
>natural consequence of the stucture of the language. When you start
>throwing in heterogenous structures, especially dealing with nested
>arrays (dictionaries) , etc..the syntactical shortcut doesn't scale very
>well to dealing with complex data. (incidentally, your example does not
>do the same thing.
>
>set l1 "1 2 3"
>set l2 "4 5 6"
>set l3 [list $l1 $l2]
>set x [lindex [lindex $l3 1] 1]
>puts $x
>
>results in '5'
>
>using 'set x(1,1)
>results in an error
complexly in analogy to C. It's at least medi-
ocre, though, at handling complex data in its
own idioms.
Yes, I fully understand that "set x(1,1)" above
gives an exception. I'm saying that all the
well-crafted systems for managing matrices in
Tcl do NOT just make them as nested lists. One
possibility for a nicely-engineered Tcl matrix
handler is to refer to the "upper left" element
as "x(1,1)". I'm sorry that your co-workers
imposed such an unaesthetic misuse of Tcl as you
describe on you.
<URL: http://wiki.tcl.tk/2995 > has more on the
subject.
.
[Jay and Cameron talk
past each other more]
.
Cameron Laird
>complex structures and this is a qualitative difference between the two
>languages
>
>Expanding beyond just getting a single value from a multidimensional list
>is what happens when you start throwing in lrange for slicing and other
>ways of unwrapping the structure. TCL's approach of using 'functionName
>$var1 var2' leads quite easily and naturally to such 'monstrosities' as a
>natural consequence of the stucture of the language. When you start
>throwing in heterogenous structures, especially dealing with nested
>arrays (dictionaries) , etc..the syntactical shortcut doesn't scale very
>well to dealing with complex data. (incidentally, your example does not
>do the same thing.
>
>set l1 "1 2 3"
>set l2 "4 5 6"
>set l3 [list $l1 $l2]
>set x [lindex [lindex $l3 1] 1]
>puts $x
>
>results in '5'
.
.
I know a more affirmative way to express my point.
If I were in a Tcl shop, and my colleagues insisted
on expressing matrices in the clumsy way you've
modeled above, then I would adopt the Lispish (to
connect this back to the subject line) approach,
quite natural in Tcl, of defining a special-purpose
syntax for the purpose. In this case, by writing
one procedure definition, I can get the Tcl inter-
preter to evaluate all expressions of the form
puts [x{1,1}]
or
puts $x{1,1}
(you choose) in the way we'd want.
Jay O'Connor
<cla...@lairds.com> wrote:
Well actually, TCL is not bad in handling date in comparison to C (and I
made that point to my co-workers)
However, my comparison was to Python, and in that respect TCL is
substandard to both Python(and a whole host of other languages
invented since C)
> It's at least medi- ocre, though, at handling complex data in its
> own idioms.
Well, the original analogy was that different approaches to syntax in a
language do lead to qualitative differences in the usages of those
languages
> I'm
> saying that all the well-crafted systems for managing matrices in Tcl do
> NOT just make them as nested lists.
Matrices are a simple data structure. Business data tends to be more
complicated. My example was extremely simplistic in comparison the the
heterogenous nested data that was trying to be handled using similar
techniques.
> One possibility for a
> nicely-engineered Tcl matrix handler is to refer to the "upper left"
> element as "x(1,1)".
Which fails when you start trying to put arrays in it.
You're thinking of "[lindex[lindex[.. " as indicating a matrix. I'm
thinking in terms of a list of records where each record contains both
simple data and complex data. As long as you have multi-dimensional data
of simple form, it's easy. When the data is a heterogenous mix of
values, lists, lists of lists, and arrays, the messines of the code gets
quite bad
> I'm sorry that your co-workers imposed such an unaesthetic misuse of Tcl as you describe on you.
Unfortuately I have yet to see that the usage would be considered
'unaesthetic misuse' simply because I have yet to see a working
alternative that is an simpler
> <URL: http://wiki.tcl.tk/2995 > has more on the subject.
Yes, I notice non of the proposals can scale easily beyond simplistic
usage in either size of problem space or complexity of problem.
larry
> Hi
>
> I don't know much about Python, but I looked at this comparison
> between Python and Common Lisp (
> http://www.norvig.com/python-lisp.html ), and I couldn't help but
> wonder why Python is popular, while Common Lisp and Scheme aren't?
>
I think the same could be asked about Perl vs Python:
Why is Perl so much more popular than Python?
Another question that could be asked about Lisp is:
Most people it seems have nothing good to say about lisp:"it's hard to
read,it's slow, nobody uses it, it's hard to learn etc, etc".
Lisp is constantly being bashed
and yet Lisp has survived for over 40 years and several companies
(Franz, Xanalys, Digitool)
seem to make a profit selling lisp compilers. SOMEBODY is using Lisp.
If lisp is such a crummy language why has it survived at all for so
long?
Why do SOME people think Lisp is a fantastic programming langugae?
Are we missing something?
Carl Banks
> Hi
>
> I don't know much about Python, but I looked at this comparison
> between Python and Common Lisp (
> http://www.norvig.com/python-lisp.html ), and I couldn't help but
> wonder why Python is popular, while Common Lisp and Scheme aren't?
As cool as Lisp is, it is too low-level, too hard to learn, too
weird-looking, and way too different from C (at all levels) to gain
much popularity.
The real problem is that, while Python makes a significant effort to
accomodate human thinking (i.e., Python lets programmers think like
humans instead of machines a lot of the time), Lisp doesn't put a high
priority on this. If programming in assembly language is "thinking
like the processor," then programming in Lisp is "thinking like the
compiler."
Examples of way Python accomodates human thinking more than Lisp:
Python represents logical nesting the same way human read it, by
indentation. Lisp repesents all nesting with parentheses, which is
not too different from how humans think if the nesting is not too deep
(and, indeed, Python does use parentheses for nesting expressions).
But when the nesting levels get more than three or so deep, everyone
who isn't Rain Man loses track and has to count parentheses to parse
it.
Python uses infix notation for math. Most humans were brought up to
understand infix.
Python controls evaluation completely, whereas Lisp gives programmers
control of evaluation. Humans don't like to think about when
something will be evaluated, and a lot of Python programmers aren't
even aware of the significance of evaluation time. The reason Python
programmers often don't have to think about it is most of the time
it's intuitive. When a programmer sees a for loop, he or she knows
the statements will be evaluated intuitively, without having having to
explicitly think about evaluation time. In most other cases, the
programmer expects things evaluated immediately. Python accomodates
the human thinker by doing what the human thinker expects (most of the
time--there are always tricky cases like default arguments). Lisp, by
giving control of evaluation to the programmer, forces the programmer
to think about evaluation time rather than intuit it.
Python is more like C than Lisp at all levels. One aspect of human
thinking is that humans can learn new ways to think. Another aspect
of human thinking is that many humans don't like to learn new ways to
think. Most programmers are taught C; and in learning C they learned
a certain way to think. Many programmers realize the limitations of C
and seek a more dynamic language. Python and Lisp will both do, but
Python, requiring less of a change in thinking, is going to be chosen
more.
There are many, many factors that determine the poularity of a
langauge. In this case, I think the main factor is that Python just
thinks more like we do than Lisp.
--
CARL BANKS
Carl Banks
> Oleg fed this fish to the penguins on Friday 08 November 2002 04:54 am:
>
>> Hi
>>
>> I don't know much about Python, but I looked at this comparison
>> between Python and Common Lisp (
>> http://www.norvig.com/python-lisp.html ), and I couldn't help but
>> wonder why Python is popular, while Common Lisp and Scheme aren't?
>>
> I have to wonder about any paper that describes Python as being like
> LISP except with in-fix notation...
Python is more like Lisp than most other languages, though. It's
similar semantically.
--
CARL BANKS
Chad Netzer
>
> Why do SOME people think Lisp is a fantastic programming langugae?
> Are we missing something?
Because for all it's silly, irritating parenthesis, it got some things very
right. Whenever I see a new language, I tend to ask myself: "What subset of
LISP is it trying to do, and what does it give up to do so."
--
Chad Netzer
cne...@mail.arc.nasa.gov
Mark Jackson
> Oleg fed this fish to the penguins on Friday 08 November 2002 04:54 am:
>
> > Hi
> >
> > I don't know much about Python, but I looked at this comparison
> > between Python and Common Lisp (
> > http://www.norvig.com/python-lisp.html ), and I couldn't help but
> > wonder why Python is popular, while Common Lisp and Scheme aren't?
> >
> I have to wonder about any paper that describes Python as being like
> LISP except with in-fix notation...
Well, that *would* explain why it's called Python and not Pyson. . . .
--
Mark Jackson - http://www.alumni.caltech.edu/~mjackson
It is not easy, these days, to go beyond the bounds of taste.
- Paul Goldberger
David Eppstein
Carl Banks <imb...@vt.edu> wrote:
> Python is more like Lisp than most other languages, though. It's
> similar semantically.
This makes little sense to me. Even the most basic data structures are
different: Lisp is based around singly linked lists while Python uses
vectors (with efficient random access unlike Lisp lists) and
dictionaries. They are also not especially similar in programming
style, although both are capable of being used with a wide variety of
styles. The most important similarity I see is that in both languages,
values have types but variables are untyped, but that was also true in
radically different languages such as Snobol and APL; is that really
enough to conclude that Python and Lisp are more like each other than
anything else?
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
Avery Andrews
Perhaps because it's Perl 6? I think a correct answer to why Python
is popular would also have to explain a lot about why Perl is (easy
reusablity of code, inclduing that written in other languages, would
surely be part of the joint answer).
Ian Bicking
way about it as many do about Lisp -- it was a great language and why
didn't people use it more? I think many of Smalltalk's flaws are
similar to Lisp's flaws (and I still like both languages, but actively
use neither).
In both cases the syntax is novel. Smalltalk's syntax is actually quite
aesthetically pleasing (in comparison to Lisp and most other languages,
even Python), but regardless it doesn't look anything like standard
Algol-style syntaxes. Speed is more of an issue with Smalltalk, but
it's certainly no worse than Python.
But I don't think syntax is the biggest problem with either of these
languages. Neither Lisp nor Smalltalk allows a person to move gradually
between environments. My first experience with Python was using it to
create small scripts. They were learning devices to be sure, but they
were also useful. My similar experiments with Smalltalk were not useful
-- and the only way I could truly be useful in Smalltalk without writing
large and complete applications would be to use a Smalltalk
environment. I even considered actually doing this -- living in a
Smalltalk world, with a Smalltalk browser and email client, storing my
documents in Smalltalk objects, the whole deal. But that would be hard,
and I never actually made that leap. People have made that same leap
with Lisp -- the Lisp Machines of yore.
But that's not going to be mainstream. In a heterogeneous environment
both Lisp and Smalltalk have serious issues. Their style isn't friendly
to outsiders, and even worse their environment usually isn't friendly.
Python might not have as many libraries as Perl, but it has a heck of a
lot -- and best, a lot of libraries that connect to C libraries of
significant functionality.
That's not fair, though -- neither language is fundamentally
isolationist. So maybe the real blame lies with timing. Python came
around when free software/open source was becoming a truly functional.
Python gets a lot from that, and it also happens to get a lot from
having a single implementation. Together, when something is implemented
by one (sharing) person, it is shared among all Python programmers --
not programmers of a specific implementation, nor among everyone who
finds it useful enough to pay for. This community could not have come
to exist fifteen or twenty years ago, when those other languages were
still fresh.
There's other important practical issues. It's easy to share Python
programs and modules. It's easy to manage the modules you get from
others. It's easy to install Python, and while it doesn't start up
instantly, it starts up pretty quick (quicker than Common Lisp or
Smalltalk to be sure). People can script in Python, they can't in big
languages. Scripting is a great way to pull people in, and unlike other
languages (*coughperlcough*) they won't be burned when they try
something of significant size. These are all details, but they are very
important details.
Ian
Carl Banks
> In article <aqhmib$ei8$2...@solaris.cc.vt.edu>,
> Carl Banks <imb...@vt.edu> wrote:
>
>> Python is more like Lisp than most other languages, though. It's
>> similar semantically.
>
> This makes little sense to me. Even the most basic data structures are
> different: Lisp is based around singly linked lists while Python uses
> vectors (with efficient random access unlike Lisp lists) and
> dictionaries.
Well, I think the data structures are similar, if you look at the
whole picture instead of just two types that share a name.
Excepting the list types of both languages, neither of which has a
built in analogue in the other, the structures are similar. Python
tuples are like Lisp vectors. Python dicts are like Lisp hash arrays.
Functions are first class objects in both languages.
The numeric system is similar (except Lisp has rationals), it has
similar coercion rules, they treat division problems similarly (i.e.,
distinguishing true and floor division).
The object systems of the languages share some peculiarities. Classes
are objects in both Lisp and Python. In fact, from Python 2.2 on, the
built-in class framework are analogous: Lisp standard-class = Python
type, Lisp standard-object = Python object. Obviously, Lisp's
multiple-dispatch methods are far different from Python methods.
And, getting get back to lists for a second, despite the fact that
they are different, a lot of languages don't even *have* lists built
in.
In the end, I think Python and Lisp have similar data structures that
serve similar purposes. Can you think of any languages that have data
structures more similar to Lisp's than Python? I don't think there
are too many.
> They are also not especially similar in programming
> style, although both are capable of being used with a wide variety of
> styles.
Yes, but hardly any language has a programming style similar to Lisp.
> The most important similarity I see is that in both languages,
> values have types but variables are untyped, but that was also true in
> radically different languages such as Snobol and APL; is that really
> enough to conclude that Python and Lisp are more like each other than
> anything else?
Well, I think that's big. On a related note, they are both highly
dynamic.
Let me clarify something, though: I said Python is a lot closer to
Lisp than most other languages are. I didn't say Python is
necessarily similar, just less unsimilar.
And the converse isn't true: Lisp is not closer to Python than most
other languages are. Python has a lot of friends; Lisp stands far
away from the crowd and hangs out with it's dialectal buddies. But,
Python is standing on the end of the crowd closest to Lisp.
--
CARL BANKS
Roy Smith
> The most important similarity I see is that in both languages,
> values have types but variables are untyped, but that was also true in
> radically different languages such as Snobol and APL; is that really
> enough to conclude that Python and Lisp are more like each other than
> anything else?
The biggest lisp-like thing I see in Python is that from the point of
view of what a container can hold, data and code (and classes, and
modules, and types) are the same kind of thing. A "def" statement is
really just a definition of a lambda body and an assignment of that to a
name (variable) all rolled into one.
That being said, I agree with David; only a computer scientist
interested in language theory would consider Python and Lisp to be
similar.
Gareth McCaughan
> Another question that could be asked about Lisp is:
> Most people it seems have nothing good to say about lisp:"it's hard to
> read,it's slow, nobody uses it, it's hard to learn etc, etc".
> Lisp is constantly being bashed
> and yet Lisp has survived for over 40 years and several companies
> (Franz, Xanalys, Digitool)
> seem to make a profit selling lisp compilers. SOMEBODY is using Lisp.
> If lisp is such a crummy language why has it survived at all for so
> long?
> Why do SOME people think Lisp is a fantastic programming langugae?
> Are we missing something?
I strongly suspect that "larry" knows this already, but:
Yes, Lisp has a lot more going for it than popular rumour
suggests. For instance:
- it's one of the few dynamically typed languages
that can provide execution speeds comparable to
C, Fortran and the like.
- its syntax, offputting though it is to most newcomers,
enables an astoundingly powerful macro system in which
you can do just about anything; in other words, you
can customize the syntax to suit the domain you're
working in.
- its object system is more sophisticated than just about
any other, including
- multiple dispatch (i.e., methods specialized on more
than one parameter's type: say goodbye to the "Visitor
pattern")
- a wide range of "method combinations", allowing a
nice low-effort way to say things like "Make this
method do X, then call the corresponding method on
the parent class" or even "call the corresponding
method on each parent class, and add the results up"
- a "meta-object protocol" (not part of the ANSI standard,
but a de facto standard, presentin every major
implementation) which lets you customize the behaviour
of the object system
- its (unusual) approach to exception handling allows you
to do cool things like continuing execution from the point
where the exception happened, after fixing whatever the
problem was.
- it has decent support for numerical applications: multidimensional
arrays, a well thought out set of arithmetic and transcendental
operations, a variety of floating-point formats, unlimited
precision integers and rationals done right, etc.
Plus a bunch of things that Python does well too, of course.
Lisp has weaknesses. Its standard library, though much better
than (for instance) C++'s in my opinion, is very lacking in
the "real-world" components where Python's shines. No networking,
database connectivity, graphics, web servers, and so on. There
are libraries for all that stuff, but they aren't standardized
and don't come with every implementation. Batteries not included.
The syntax *is* weird. (But one gets to love it, especially for
the convenience it gives to macros.)
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
John Baxter
I was around during LISP's very early days at MIT (as one of several
thousand people who didn't understand anything John McCarthy said beyond
"hello" ;-)). But I wasn't involved. I did get involved with the odd
little interpreted language CoMIT which the Linguistics Department was
working with. (And in Spring of 1958 took a class from a youngish Noam
Chomsky.)
LISP was not as pleasant to work in then as any of the implementations
are now: the interpreter was run in a batch job shop environment with
source code on cards. The interpreter gave no results at all if one was
even one ) short of balancing the (s. Meaning that it was easy to spot
the LISP users: they walked around with cards full of )s in their
pockets to slap onto card decks. [The interpreter gave some sort of
information and results if it saw too many )s.]
If I had my choice and the time to do so, I'd probably do nearly
everything in LISP...as it is I haven't used LISP since Mac Common LISP
moved on from Apple Cambridge.
I spent lots of time with Forth in the late 70s to mid 1980s, as a hobby
(and an excuse for lunch gatherings with Guy Kelly et al).
I've also exercised Smalltalk...I wouldn't be likely to do everything in
Smalltalk, although I like the language and might do something in it.
The rainfall recorder I use now (nothing fancy: manual entry of
readings from the $2.95 high-imprecision rain guage) began in MacForth
in 1989, moved to SmallTalk, moved on to Prograph, to MacApp (Pascal
form) for a while, and back to the Prograph version which I still use.
We were using Perl heavily when I stumbled onto Python. How? Well, the
Bellevue, WA, Tower Books suffered water damage in a rain, and the
water-damaged "Programming Python" was priced to sell (before it
rotted). I found I liked the language, showed it to the boss, and
...now we do Python (starting before 1.5). [We were an early corporate
member of PSA, and I was a member, despite the odd methods one had to
use to join and pay. ;-)]
Why Python and not the others? No deep Computer Science reasons (CS
didn't exist yet in my college years).
Rather: Python just feels right.
--John (who uses RPN calculators and can't manage Algebraic ones)
Cimarron Taylor
> set rounded [expr int(a + 0.5)]
I agree. Here what tclsh gives me:
% set a 1.03
1.03
% set rounded [expr int(a + 0.5)]
syntax error in expression "int(a + 0.5)"
Perhaps you intended to write:
% set rounded [expr int($a + 0.5)]
1
Cim
Dieter Menszner
> In article <aqhmib$ei8$2...@solaris.cc.vt.edu>,
> Carl Banks <imb...@vt.edu> wrote:
>
>
>>Python is more like Lisp than most other languages, though. It's
>>similar semantically.
>
>
> This makes little sense to me. Even the most basic data structures are
> different: Lisp is based around singly linked lists while Python uses
> vectors (with efficient random access unlike Lisp lists) and
> dictionaries. They are also not especially similar in programming
>
This is just wrong. To say 'Lisp is based around singly linked'
is similar as saying C is build around the ASCII character set.
Not totally wrong but ...
Common Lisp has built-in all the usual data types including
hash tables.
Michael Hudson
> In article <aqhmib$ei8$2...@solaris.cc.vt.edu>,
> Carl Banks <imb...@vt.edu> wrote:
>
> > Python is more like Lisp than most other languages, though. It's
> > similar semantically.
>
> This makes little sense to me. Even the most basic data structures are
> different: Lisp is based around singly linked lists
This marks you out as not knowing lisp very well, I'm afraid...
> while Python uses vectors (with efficient random access unlike Lisp
> lists) and dictionaries. They are also not especially similar in
> programming style, although both are capable of being used with a
> wide variety of styles. The most important similarity I see is that
> in both languages, values have types but variables are untyped,
The way bindings and objects and assigment and so on work in Lisp and
Python is almost indistinguishable, esp. compared to C or perl.
> but that was also true in radically different languages such as
> Snobol and APL; is that really enough to conclude that Python and
> Lisp are more like each other than anything else?
Well, it depends on the universe of languages you are considering; if
you have
{ Java, Python, ocaml, Common Lisp, C++, perl }
I'd say Python and CL look pretty similar.
If you have
{ MacLisp, Lisp Machine Lisp, InterLisp, Lisp 1.5, Python }
then Python is obviously the odd one out. And so on.
Cheers,
M.
--
112. Computer Science is embarrassed by the computer.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Michael Hudson
> If lisp is such a crummy language why has it survived at all for so
> long?
Well, obviously: because it's not such a crummy language.
Cheers,
M.
--
We did requirements and task analysis, iterative design, and user
testing. You'd almost think programming languages were an interface
between people and computers. -- Steven Pemberton
(one of the designers of Python's direct ancestor ABC)
Michael Hudson
> Hi
>
> I don't know much about Python, but I looked at this comparison
> between Python and Common Lisp (
> http://www.norvig.com/python-lisp.html ), and I couldn't help but
> wonder why Python is popular, while Common Lisp and Scheme aren't?
For Common Lisp, at least, my guess is: a bizarre mix of history, bad
teaching, things that "everyone knows" that are plain wrong, a fright
reaction on seeing syntax you're not used to[1] and tendency to ignore
the rest of the world.
Scheme, maybe because there are almost as many implementations as
users?
Cheers,
M.
[1] How many people went "significant indentation! ugh!"?
--
SPIDER: 'Scuse me. [scuttles off]
ZAPHOD: One huge spider.
FORD: Polite though.
-- The Hitch-Hikers Guide to the Galaxy, Episode 11
Michael Hudson
Fernando Pérez <fper...@yahoo.com> writes:
> If you just want convenience for 4x6 prints from negative, a P&S is
> fine. But even a basic SLR like a Canon Rebel is about as easy to
> use as a P&S, while allowing you to 'go manual' when you feel like
> it.
What strikes me is that with modern, decent print film, going manual
-- at least wrt. exposure -- makes next to now difference. I don't
know enough about the area to say what's going on, but I was
surprised.
Cheers,
M.
--
> Why are we talking about bricks and concrete in a lisp newsgroup?
After long experiment it was found preferable to talking about why
Lisp is slower than C++...
-- Duane Rettig & Tim Bradshaw, comp.lang.lisp
Johannes Grødem
> Open-source libraries for common lisp are rare.
This might just be my impression, but it seems they are getting less
rare nowadays. Take a look at CLiki, for example.
--
Johannes Grødem <OpenPGP: 5055654C>
Johannes Grødem
> But that's not going to be mainstream. In a heterogeneous environment
> both Lisp and Smalltalk have serious issues.
This is really implementation-specific, not strictly language-
specific. There are Common Lisps that integrate well with C. There
are even Lisps that let you use inline-assembler and inline-C in your
Lisp-code.
Johannes Grødem
> Python represents logical nesting the same way human read it, by
> indentation. Lisp repesents all nesting with parentheses, [...]
When you program in Lisp, you (your editor) indents blocks for you,
which makes it easy to see block structure. Noone actually manually
count parentheses. (All sane editors support paren-matching.)
> Python uses infix notation for math. Most humans were brought up to
> understand infix.
Because Lisp has a powerful macro system, it is actually possible to
have an infix-macro, which lets you use infix-syntax. And you can
write macros to support all sorts of weird syntax, if you want.
> The reason Python programmers often don't have to think about it
> is most of the time it's intuitive. [Evaluation order.]
And when is it not intuitive in Lisp? Sure, you can write macros that
evaluate arguments in unintuitive order, but why would you? For
functions, arguments are evaluated left-to-right, just as you would
expect.
Maybe you're confusing Lisp with Scheme?
Robin Munn
> oleg_i...@myrealbox.com (Oleg) writes:
>> [ ... ] I couldn't help but
>> wonder why Python is popular, while Common Lisp and Scheme aren't?
>
> For Common Lisp, at least, my guess is: a bizarre mix of history, bad
> teaching, things that "everyone knows" that are plain wrong, a fright
> reaction on seeing syntax you're not used to[1] and tendency to ignore
> the rest of the world.
> [1] How many people went "significant indentation! ugh!"?
I think I was weirded out by Python's indentation like just about
everyone else who was coming from something like C -- but I quickly grew
used to it.
Lisp's parentheses, OTOH, I never got used to. Having to constantly stop
and count parentheses to remember where I was in my program structure
quickly went from novel to irritating and never recovered. Most of the
other students in my CS class agreed with me about the Lots of
Irritating Superfluous Parentheses.
The only thing that could make me at all comfortable with using Lisp
would be if I had an editor that would color-highlight not keywords or
strings, as color-highlighting usually goes, but levels of parenthesis
indentation. So that this:
(a (b (c (d e))))
would have 'a' in one color, 'b' in a second, 'c' in a third, and 'd e'
in a fourth.
The prefix notation doesn't bother me overly much, but the parentheses
kill it for me. Of course, this might just be memory from several years
ago...
Nope. Just downloaded the w3 browser and looked at the source. Still
Lots of Parentheses, and still Irritating. I'm willing to grant that
they're not Superfluous, but I still think they're Silly.
So that, in a nutshell, is why I don't like Lisp: the syntax gets in the
way of my scanning the code quickly. Counting parentheses takes far too
long. Whereas with Python I can give the code a once-over with the old
Mark I eyeball and get a pretty good idea of the code structure.
--
Robin Munn <rm...@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838 50FF 2478 CFFB 081A 8338 54F7 845D ACFD 6AFB 6838
Anton Vredegoor
>I don't know much about Python, but I looked at this comparison
>between Python and Common Lisp (
>http://www.norvig.com/python-lisp.html ), and I couldn't help but
>wonder why Python is popular, while Common Lisp and Scheme aren't?
A computer program has to determine what a certain input means before
it can produce output.
In the years when Lisp was becoming popular the first task -
interpreting input - was considered to be hard and the other task -
producing output - was considered to be easy. People *expected* source
code to be difficult to read for humans.
Nowadays some people think that interpreting a given message is
trivial compared to the problem of producing the right output. If the
computer has to decide that we must have meant something else in order
to be able to produce the right output: So be it.
As a consequence we can use a more human like language to communicate
with the computer.
Anton.
42
Johannes Grødem
> A computer program has to determine what a certain input means before
> it can produce output. [...]
You're trolling, right?
Ng Pheng Siong
> { Java, Python, ocaml, Common Lisp, C++, perl }
What language is this funny looking list in? ;-)
--
Ng Pheng Siong <ng...@netmemetic.com> * http://www.netmemetic.com
Donn Cave
| Fernando Pérez <fper...@yahoo.com> writes:
|> If you just want convenience for 4x6 prints from negative, a P&S is
|> fine. But even a basic SLR like a Canon Rebel is about as easy to
|> use as a P&S, while allowing you to 'go manual' when you feel like
|> it.
|
| What strikes me is that with modern, decent print film, going manual
| -- at least wrt. exposure -- makes next to now difference. I don't
| know enough about the area to say what's going on, but I was
| surprised.
Or not so modern color or BW negative film. The constraints are
much tighter with transparency emulsions because they're final
generation. If you look at a negative, it's relatively "flat",
and you can imagine it's easier to manage to get the extreme values
within the range of the emulsion's sensitivity; from there, the
printer just needs to adjust to the correct baseline. That's
simplified, the response functions aren't so linear and exposure
can have subtle effects at the extremes. See Ansel Adams for more
details, and then cube that for color.
Hm, straining for an analogy here ... well, note that the point and
shoot concept is more relevant to today's programming environments
than any differences between programming languages, but maybe one
could observe that there's some class of languages where the programming
environment is less of an issue because of the tolerances.
The "what can you do" issue is more poignant if you go all the way
to the view camera as the hard core alternative, since it lets you
make some fundamental decisions about the way the picture is going
to look - not just focus and exposure but the actual shapes of things.
Definitely not something ``most people want'', but then most people
have no idea what it's about. That probably has its analogies in the
present context, too.
Donn Cave, do...@drizzle.com
Ian Bicking
> > But that's not going to be mainstream. In a heterogeneous environment
> > both Lisp and Smalltalk have serious issues.
>
> This is really implementation-specific, not strictly language-
> specific. There are Common Lisps that integrate well with C. There
> are even Lisps that let you use inline-assembler and inline-C in your
> Lisp-code.
Certainly -- after thought, I now see why Python's canonical
implementation is very important. Whatever problems Python has, we all
have them together. Whatever features and extensions it has, we all
have them together.
Even when you consider all the features available in different
implementations of Lisp -- what would it look like if all of them were
available? Common Lisp is already a huge hodge-podge of stuff...
there's no minimalism. Then if you add more implementation-specific
aspects, it can only get worse. Python manages to introduce features
without such messiness because nothing is implementation-specific (or
everything is).
Ian
Pascal Costanza
> Why do SOME people think Lisp is a fantastic programming langugae?
> Are we missing something?
Someone at comp.lang.lisp pointed out that this discussion is going on
here at comp.lang.python. I have recently switched over to Common Lisp
as my language of choice and have written an article about it, to be
found at http://www.pascalcostanza.de/lisp/guide.html - you might find
it worthwhile.
BTW, I am currently writing a just-in-time compiler for Java bytecode in
Common Lisp - I believe that a similar Python-in-Common-Lisp
implementation along these lines could be extremely valuable for both
the Python and the Common Lisp world...
All the best,
Pascal
--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
Richard Dillingham
> would be if I had an editor that would color-highlight not keywords or
> strings, as color-highlighting usually goes, but levels of parenthesis
> indentation. So that this:
>
> (a (b (c (d e))))
>
> The prefix notation doesn't bother me overly much, but the parentheses
> kill it for me.
I wonder why you aren't writing
(a
(b
(c
(d e)
)
)
)
That's much easier to read than what you had.
The issue with 'Python being easier to read than Lisp,' IMHO, is mainly that
Python FORCES you to use indentation, whereas Lisp does not.
Since Lisp does not force you to write readable code, you have to force
yourself to use indentation.
Whether this is a fault of the programmer for not behaving, or a fault of
the compiler for not forcing the programmer to behave, is debatable.
But I don't see a bunch of C programmers typing
if (a) { if (b) { if (c) { asdf; } else { zzzz; }} else { foo; }} else
{bar;}
like a Lisp coder might type
(if (a) (if (b) (if (c) (asdf) (zzzz)) (foo)) (bar))
Those are both unreadable, and much more reable written as follows:
if (a) {
if (b) {
if (c) {
asdf;
} else {
zzzz;
}
} else {
foo;
}
} else {
bar;
}
Or (and you could put comments in here to show where the else blocks are)
(if (a)
(if (b)
(if (c)
(asdf)
(zzzz)
)
(foo)
)
(bar)
)
Of course, Python's syntax is the easiest of all to read (due to needing no
{}s or ()s at all (for this)):
if a:
if b:
if c:
asdf
else:
zzzz
else:
foo
else:
bar
I personally like not needing the ()s or {}s for situations like this.
Fernando Pérez
> Totally off-topic, but hey...
Indeed :)
>> If you just want convenience for 4x6 prints from negative, a P&S is
>> fine. But even a basic SLR like a Canon Rebel is about as easy to
>> use as a P&S, while allowing you to 'go manual' when you feel like
>> it.
>
> What strikes me is that with modern, decent print film, going manual
> -- at least wrt. exposure -- makes next to now difference. I don't
> know enough about the area to say what's going on, but I was
> surprised.
It's the exposure latitude. Modern print films have about 5 stops of exposure
latitude, so you can really get away with murder. On the other hand, with
slide film a half stop off is already noticeable. I shoot mostly slides, and
occasionally need to use a P&S, which can get a bit tricky :) But with a bit
of luck and good optics, you can get nice shots in situations where pulling
an SLR out might not be practical.
For this shot (http://www-hep.colorado.edu/~fperez/photo/Cotopaxi99/7.html) I
simply couldn't stop to get my SLR out of my bag, but I had my trusty Stylus
Epic in a jacket pocket. I took the shot without barely stopping at all, and
it turned out nicer than all others in that climb, including the ones where I
did pull out my SLR. As they say, it's the moment, not the equipment :)
Cheers,
f.
Martti Halminen
> I think I was weirded out by Python's indentation like just about
> everyone else who was coming from something like C -- but I quickly grew
> used to it.
>
> Lisp's parentheses, OTOH, I never got used to. Having to constantly stop
> and count parentheses to remember where I was in my program structure
> quickly went from novel to irritating and never recovered. Most of the
> other students in my CS class agreed with me about the Lots of
> Irritating Superfluous Parentheses.
>
> The only thing that could make me at all comfortable with using Lisp
> would be if I had an editor that would color-highlight not keywords or
> strings, as color-highlighting usually goes, but levels of parenthesis
> indentation. So that this:
>
> (a (b (c (d e))))
>
> would have 'a' in one color, 'b' in a second, 'c' in a third, and 'd e'
> in a fourth.
The secret in programming in Lisp is not to count the parentheses. After
a few months, they pretty much disappear from sight. Counting parens is
for the compiler and editor, the humans read Lisp code based on
indentation (and the editor (emacs, mostly) takes care of that, so the
programmer doesn't have to bother...).
This should be rather easy for Python programmers to understand :-)
--
Martti Halminen
> > The only thing that could make me at all comfortable with using Lisp
> > would be if I had an editor that would color-highlight not keywords or
> > strings, as color-highlighting usually goes, but levels of parenthesis
> > indentation. So that this:
> >
> > (a (b (c (d e))))
>
> I wonder why you aren't writing
> (a
> (b
> (c
> (d e)
> )
> )
> )
A lisp programmer would write it like this:
(a
(b
(c
(d e))))
or the original: (a (b (c (d e)))) if using so short names and no
control structures causing special indentation.
> The issue with 'Python being easier to read than Lisp,' IMHO, is mainly that
> Python FORCES you to use indentation, whereas Lisp does not.
>
> Since Lisp does not force you to write readable code, you have to force
> yourself to use indentation.
For a beginner it might be forcing, for the professionals it is a major
tool. Not using the canonical indentation style is a sure sign of a
newbie in comp.lang.lisp.
> But I don't see a bunch of C programmers typing
> if (a) { if (b) { if (c) { asdf; } else { zzzz; }} else { foo; }} else
> {bar;}
> like a Lisp coder might type
> (if (a) (if (b) (if (c) (asdf) (zzzz)) (foo)) (bar))
> (if (a)
> (if (b)
> (if (c)
> (asdf)
> (zzzz)
> )
> (foo)
> )
> (bar)
> )
>
(if (a)
(if (b)
(if (c)
(asdf)
(zzzz))
(foo))
(bar))
Would be the normal way to write this.
--
Richard Dillingham
> > (if (a)
> > (if (b)
> > (if (c)
> > (asdf)
> > (zzzz)
> > )
> > (foo)
> > )
> > (bar)
> > )
> >
>
> (if (a)
> (if (b)
> (if (c)
> (asdf)
> (zzzz))
> (foo))
> (bar))
>
> Would be the normal way to write this.
>
> --
I know, but I personally find the way I wrote it to be easier to read.
You'll also note that I didn't use the normal C coding standard in the C
examples, and instead used the Java/C# standard (Which I prefer).
The normal C way to use {}s being:
if (a)
{
asdf;
}
etc.
Martti Halminen
> >
> > (if (a)
> > (if (b)
> > (if (c)
> > (asdf)
> > (zzzz))
> > (foo))
> > (bar))
> >
> > Would be the normal way to write this.
By the way, your newsreader broke the indentation in your reply :-)
>
> I know, but I personally find the way I wrote it to be easier to read.
> You'll also note that I didn't use the normal C coding standard in the C
> examples, and instead used the Java/C# standard (Which I prefer).
>
> The normal C way to use {}s being:
>
> if (a)
> {
> asdf;
> }
>
> etc.
One of the C styles: see
http://www.tuxedo.org/~esr/jargon/html/entry/indent-style.html
- And I seem to remember that Linus prefers a style which isn't strictly
none of those...
--
Carl Banks
> * Carl Banks <imb...@vt.edu>:
>
>> Python represents logical nesting the same way human read it, by
>> indentation. Lisp repesents all nesting with parentheses, [...]
>
> When you program in Lisp, you (your editor) indents blocks for you,
> which makes it easy to see block structure. Noone actually manually
> count parentheses. (All sane editors support paren-matching.)
I know that. But that's just humans using the editor to count for
them. The point was you can't eyeball the nesting of parentheses.
>> Python uses infix notation for math. Most humans were brought up to
>> understand infix.
>
> Because Lisp has a powerful macro system, it is actually possible to
> have an infix-macro, which lets you use infix-syntax. And you can
> write macros to support all sorts of weird syntax, if you want.
The kind of person who writes an infix compiler in Lisp is not the
type of person who's going to be daunted by all the parentheses.
We're talking about the popularity of Lisp, which (as with all
languages) is largely determined by people who are not that kind of
person.
>> The reason Python programmers often don't have to think about it
>> is most of the time it's intuitive. [Evaluation order.]
>
> And when is it not intuitive in Lisp? Sure, you can write macros that
> evaluate arguments in unintuitive order, but why would you? For
> functions, arguments are evaluated left-to-right, just as you would
> expect.
It's not that Lisp goes out of its way to be unintuitive, but you
still can't rely on your intuition because of the many exceptions, and
an understanding of evaulation order is necessary to avoid pitfalls.
Python has a few pitfalls related to time of evaulation; Lisp has
hundreds.
Notes about when a particular form is evaluated are all over the spec.
There are a lot of macros and special forms for which it isn't clear
whether you should quote an argument or not. Just the fact that there
are macros at all (and that they look just like functions) means the
programmer has to be aware of evaulation issues.
Then you throw compiling into this. In every compiled language I
know, with two exceptions, it is completely obvious whether code is
evaluated at compile time or run time. The two exceptions are Perl
and Lisp. In Lisp, sometimes it isn't even *defined* when code gets
evaluated. So, the programmer has to guard against both cases. How
can you do that without understanding evaluation issues?
What I'm saying is, in Python, you can all but ignore time of
evaluation. You can't do that in Lisp.
> Maybe you're confusing Lisp with Scheme?
I don't know what problems Scheme has that Common Lisp doesn't in this
regard. Care to elaborate? Or is that just a common reaction to
criticism of Lisp ("it can't possibly be us, you must be thinking of
that quaint language Scheme")?
--
CARL BANKS
Erik Max Francis
> According to Michael Hudson <m...@python.net>:
>
> > { Java, Python, ocaml, Common Lisp, C++, perl }
>
> What language is this funny looking list in? ;-)
It's standard set notation from mathematics :-).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I'm paranoid. But am I paranoid enough?
\__/ Louis Wu
Official Omega page / http://www.alcyone.com/max/projects/omega/
The official distribution page for the popular Roguelike, Omega.
Erik Max Francis
> * Carl Banks <imb...@vt.edu>:
>
> > Python represents logical nesting the same way human read it, by
> > indentation. Lisp repesents all nesting with parentheses, [...]
>
> When you program in Lisp, you (your editor) indents blocks for you,
> which makes it easy to see block structure. Noone actually manually
> count parentheses. (All sane editors support paren-matching.)
Right. Note that this objection to Lisp is analogous to the objection
that whitespace-insensitive language users (C, C++, Java, Perl, etc.)
often use to discount Python before they've been exposed to it. "If
it's whitespace sensitive," they say, "I'll be stuck fighting with
indentation to get the results I want."
I'm an emacs user, so the first thing I did when I started fiddling
around with Python is installed python-mode. Because of that, I have
never once counted spaces, never once had space/tab problems, never once
had a problem indenting/unintending a region, and whenever I've
forgotten the odd colon, good ol' python-mode has made it very clear to
me what the problem was.
The same goes for Lisp (and all its variants, like Scheme). You might
have to count parentheses if you had to physically write it down with
pencil and paper, but in the real world you'll be using an editor, and
the editor will help you match parentheses and do the gruntwork for you.
Rocco Moretti
> * Carl Banks <imb...@vt.edu>:
>
> > understand infix.
>
> Because Lisp has a powerful macro system, it is actually possible to
> have an infix-macro, which lets you use infix-syntax. And you can
> write macros to support all sorts of weird syntax, if you want.
I've heard this argument a number of times, and have never really
bought it. To me it seems equivalent to saying "Because (Brainf*ck/
Intercal/ Unlambda/ Malbourge /etc) are Turing Complete, you can write
any program in them." Sure, you *can*, but why bother?
It's the same reason why using lists and dictionaries are so much
better in Python than in C. Sure, you *could* write your own type and
various accessory methods to do the same thing, but why should you
have to deal with the boilerplate code to make the language do it?
It's doubly hard when beginning Lisp books only teach the prefix
notation - the beginner could change it, but who, thus thouroghly
vexed, has the stamina to wait until chapter 23 to learn how? That's
why the common rebuttal directed toward Lisp critics is that they
don't *really* know the language. Lisp is a powerful language, but you
have to have the patience and the masochism to make it all the way to
chapter 23.
If-I-wasn't-lazy-I-would-be-doing-it-longhand
Syver Enstad
> I'm an emacs user, so the first thing I did when I started fiddling
> around with Python is installed python-mode. Because of that, I have
> never once counted spaces, never once had space/tab problems, never
> once
>
> had a problem indenting/unintending a region, and whenever I've
> forgotten the odd colon, good ol' python-mode has made it very clear
> to
>
> me what the problem was.
>
> The same goes for Lisp (and all its variants, like Scheme). You might
>
> have to count parentheses if you had to physically write it down with
> pencil and paper, but in the real world you'll be using an editor, and
>
> the editor will help you match parentheses and do the gruntwork for
> you.
I basically agree Erik, the parenthesis in Lisp is a matter of getting
used to something. I do find that when I am coding Elisp, I find it a
bit more work to restructure code, this is because the amount of
parenthesises but also because I follow the usual Lisp practice of
lining up the remaining parenthesis at the end of the line.
On another note, I think the Smalltalk method call (keyword message send)
syntax is fabulously readable, why haven't anybody picked that up?
Code like this is marvelously more understandable than the usual
position based argument list that one uses in Lisp and C.
Ex:
aCircle paintOn: aCanvas at: aPoint
Where aCircle, aCanvas and aPoint are variable names, and what is
happening is that one is calling the method paintOn: at: where aCircle
is self. The alternative:
aCircle.paint(aCanvas, aPoint)
is okay for this example but the smalltalk way lets you convey much
more. Python has a kind of middle ground with its keyword messages,
which is good but not quite as nice as Smalltalk.
--
Vennlig hilsen
Syver Enstad
Gareth McCaughan
> That being said, I agree with David; only a computer scientist
> interested in language theory would consider Python and Lisp to be
> similar.
Q: If you want to find out how similar two languages are,
what sort of person should you consult?
A: A computer scientist interested in language theory.
:-)
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Gareth McCaughan
> >> Python uses infix notation for math. Most humans were brought up to
> >> understand infix.
> >
> > Because Lisp has a powerful macro system, it is actually possible to
> > have an infix-macro, which lets you use infix-syntax. And you can
> > write macros to support all sorts of weird syntax, if you want.
>
> The kind of person who writes an infix compiler in Lisp is not the
> type of person who's going to be daunted by all the parentheses.
> We're talking about the popularity of Lisp, which (as with all
> languages) is largely determined by people who are not that kind of
> person.
The person who writes it needn't be the same as the person who
uses it. There already exist things that let you use infix
syntax for mathematics in Lisp; you don't have to write them
for yourself.
I'm not sure anyone actually *uses* them, mind... :-)
Pascal Costanza
> On another note, I think the Smalltalk method call (keyword message send)
> syntax is fabulously readable, why haven't anybody picked that up?
> Code like this is marvelously more understandable than the usual
> position based argument list that one uses in Lisp and C.
>
> Ex:
>
> aCircle paintOn: aCanvas at: aPoint
>
> Where aCircle, aCanvas and aPoint are variable names, and what is
> happening is that one is calling the method paintOn: at: where aCircle
> is self. The alternative:
>
> aCircle.paint(aCanvas, aPoint)
>
> is okay for this example but the smalltalk way lets you convey much
> more. Python has a kind of middle ground with its keyword messages,
> which is good but not quite as nice as Smalltalk.
In Common Lisp, you can have:
(paint circle :on canvas :at point)
Given that you have defined paint as follows:
(defun paint (&key on at)
...)
You can also have default values.
(defun paint (&key (on default-canvas) (at '(0 0)))
...)
So you can have all of the following.
(paint circle :on canvas)
(paint circle :at '(5 5))
(paint circle)
If you define circle to be a class, you can have the usual overriding of
methods as follows:
(defmethod paint ((object circle)
&key (on default-canvas)
(at '(5 5)))
...)
(defmethod paint ((object rectangle)
&key (on default-canvas)
(at '(10 10))
...)
(paint (make-instance 'rectangle) :on my-canvas :at '(150 10))
...which is to show that you can mix positional and keyword parameters.
In the latter examples, circle and rectangle are classes defined as follows.
(defclass circle (graphical-object)
(radius))
(defclass rectangle (graphical-object)
(width height))
...where graphical-object is the common superclass, and radius, width
and height are slots (instance variables).
etc., etc. ;)
Pascal Costanza
> "Johannes Grødem <joh...@ifi.uio.no> wrote in message news:<lzznsip...@unity.copyleft.no>...
>
>>have an infix-macro, which lets you use infix-syntax. And you can
>>write macros to support all sorts of weird syntax, if you want.
>
> I've heard this argument a number of times, and have never really
> bought it. To me it seems equivalent to saying "Because (Brainf*ck/
> Intercal/ Unlambda/ Malbourge /etc) are Turing Complete, you can write
> any program in them." Sure, you *can*, but why bother?
...because macros in Common Lisp allow you to do extremely powerful
things and write very compact code.
[...]
> It's doubly hard when beginning Lisp books only teach the prefix
> notation - the beginner could change it, but who, thus thouroghly
> vexed, has the stamina to wait until chapter 23 to learn how? That's
> why the common rebuttal directed toward Lisp critics is that they
> don't *really* know the language. Lisp is a powerful language, but you
> have to have the patience and the masochism to make it all the way to
> chapter 23.
Then throw that book away and buy a better one. ;-)
Or better yet, download the freely available "On Lisp" by Paul Graham at
http://www.paulgraham.com/onlisp.html which is the best book on macros
in Common Lisp. (It introduces them in chapter 7, that's 16 chapters
earlier! ;)
The core is extremely simple:
This is a piece of program in Lisp: (gethash "key" table)
This is some data in Lisp, a list: '(gethash "key" table)
In the first example, we have a call of the function gethash with
arguments "key" and table. In the second example, we have a list with
the three elements gethash, "key" and table.
(BTW, this is exactly the reason why Lisp has this seemingly strange
syntax - you can easily switch between program representation and data
representation. On the conceptual level, Lisp makes no difference
between data and programs.)
In the first example, "key" evaluates to a string and table is a
variable that (hopefully) evaluates to a hash table. In the second
example, none of the three elements are evaluated, but they are taken as is.
Sometimes you need lists with some elements evaluated and some not. Here
is an example: `(gethash "key" ,table) - here, gethash and "key" are not
evaluated but table is.
So when you have a function definition (defun f (x) (* x x)), everytime
the Lisp compiler sees for example (f 5), it translates this to a call
to the function f with argument 5 (or it inlines the call, depending on
settings of the environment).
On the other hand, when you have a macro definition (defmacro f (x) `(*
,x ,x)), everytime the Lisp compiler sees (f 5), it calls the macro
function f with the list '(f 5) at compile time. The macro function
returns '(* 5 5) and the compiler takes this as the code that it needs
to compile instead of the original code. (Of course, the result of a
macro function may include further macro calls, and so on.)
So here is a neat toy example for a good Common Lisp macro. Assume you
have two functions lock and unlock to protect objects from some unwanted
access. For example:
(lock ouput)
(write-line "Hello, World!" output)
(write-line "Hi, everybody else!" output)
(unlock output)
A nicer way to do this is to write a macro as follows.
(defmacro with-locked-object (object &rest code)
`((lock ,object)
,@code
(unlock ,object)))
Here, code is a so-called rest arguments - a list of all arguments after
the already processed arguments (in this case object). The splice
operator ,@ takes a list, unwraps one pair of brackets and puts this
list into the surrounding list.
So now you can do the following.
(with-locked-object output
(write-line "Hello, World!" output)
(write-line "Hi, everybody else!" output))
Here, the macro function with-locked-object gets output (unevaluated)
and the list '((write-line "..." output) (write-line "..." output)) as
arguments and creates our original code as output. The nice thing about
this macro is that it frees you from the need to remember to unlock your
object properly. We have essentially defined a language extension!
(This is the way Lisp programmers usually work - they create a kind of
domain-specific language for the problem at hand and use that language
for solving the problem.)
Christian Tismer
> Hi
>
> I don't know much about Python, but I looked at this comparison
> between Python and Common Lisp (
> http://www.norvig.com/python-lisp.html ), and I couldn't help but
> wonder why Python is popular, while Common Lisp and Scheme aren't?
Let me try a shameless plug:
CLisp and Scheme are great for problems. They are great.
Python is great for solutions. It is simple.
No other language is more successful
in vanishing behind the problem.
Python is the second best programming language in the world.
But the best has yet to be invented :-) -- chris
--
Christian Tismer :^) <mailto:tis...@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
Lulu of the Lotus-Eaters
|[1] How many people went "significant indentation! ugh!"?
Oddly many... or at least it seems odd, since I never had that reaction.
But almost no one held on to that "ugh!" feeling after a couple days of
using Python. My feeling is that the "ugh!" over Lisp's parentheses
just never goes away for most people.
--
---[ 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> ]--------------------------
Erik Max Francis
> On another note, I think the Smalltalk method call (keyword message
> send)
> syntax is fabulously readable, why haven't anybody picked that up?
> Code like this is marvelously more understandable than the usual
> position based argument list that one uses in Lisp and C.
>
> Ex:
>
> aCircle paintOn: aCanvas at: aPoint
Objective-C uses basically this same syntax, albeit surrounded by
brackets.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Can I walk with you / Through your life
\__/ India Arie
Kepler's laws / http://www.alcyone.com/max/physics/kepler/
A proof of Kepler's laws.
Robin Munn
> Richard Dillingham wrote:
>
>> > The only thing that could make me at all comfortable with using Lisp
>> > would be if I had an editor that would color-highlight not keywords or
>> > strings, as color-highlighting usually goes, but levels of parenthesis
>> > indentation. So that this:
>> >
>> > (a (b (c (d e))))
>
>>
>> I wonder why you aren't writing
>> (a
>> (b
>> (c
>> (d e)
>> )
>> )
>> )
>
>
> A lisp programmer would write it like this:
>
> (a
> (b
> (c
> (d e))))
>
> or the original: (a (b (c (d e)))) if using so short names and no
> control structures causing special indentation.
Both of you are right with regard to indentation; you can tell that I
don't use Lisp, as I am completely unfamiliar with proper indentation
techniques. The second form (with the closing parentheses lined up)
would confuse me if I tried to read someone else's code, whereas the
first (sort of C-like) form of indentation allows me to see at a glance
which parenthesis is being closed where.
>
>> The issue with 'Python being easier to read than Lisp,' IMHO, is mainly that
>> Python FORCES you to use indentation, whereas Lisp does not.
And that has become one of the major reasons why I like Python: I can
read code written by anyone, even language newbies, and understand it
without having to puzzle out their indentation style. The other reason
why I like Python is the power of introspection. (I have this peculiar
mental "image" of a TV commercial like the "Behold the power of cheese!"
commercials found on US television, except the slogan is "Behold the
power of introspection!")
Well, I can understand the structure behind the canonical Lisp
indentation style. And it might be horizon-broadening to attempt a
serious program in Lisp sometime. But despite the fact that I *know*
there's logical structure to it, seeing Lisp code still makes me think
of "You are in a maze of twisty little parentheses, all similar." :-)
Incidentally, I am not trying to bash Lisp; it's just that my own
initial reactions were negative, and I haven't found the positive in it
that I know to be there. But having found a language (Python) that
thinks the way I do, and being able to have my thoughts flow into real
code without the language getting in the way, I find myself disinclined
to invest time and mental energy learning a language that *doesn't* flow
for me.
My general take on why Python is popular, while Lisp and Scheme aren't?
For most people, learning Lisp seems to be an uphill struggle, whereas
Python simply *flows*.
Andrew Dalke
> I have recently switched over to Common Lisp
> as my language of choice and have written an article about it, to be
> found at http://www.pascalcostanza.de/lisp/guide.html - you might find
> it worthwhile.
It's a discussion of Lisp, with only a few points specifically of
why you switched from Java to Lisp and one mention of Python. (There
were two references to Monty Python, from which Python the language got
its name.) I was hoping for a more philosophical rumination of why
you chose Java over Python. :(
Some points that are weaker in a Python/Lisp comparison are
- Python doesn't have as many "funny names" as Lisp
- Python also does run-time typing rather than static typing
- You say
> Please remember that due to their syntax, C-like languages and Pascal
> might also run into trouble when curly braces or begin/end keywords
> are used incorrectly in conjunction with control statements (like if,
> while, switch/case, and so on)
But Python doesn't have that problem, given neither braces nor begin/end
keywords. Indeed, you seem to suggest that all Algol-derived languages
are like C/C++/Pascal/Java in having explicit delimiters, a separate
compilation step, static typing,
- You say:
> A nice thing about Lisp is that it doesn't noticeably distinguish
> between built-in functions and user-defined functions.
The same is true for Python.
You talk about Lisp's macro feature. That's come up several times
on c.l.py. I understand at least theoretically the usefulness of
macros. However, I am quite worried about the supportability of
defining your own language on the fly. For the comparison I would
have like to have seen, I was hoping for comments on the
maintainability of macros, especially given that some people like
you have found "them to be conceptually quite simple and easy to
write" while others find them "seemingly hard to understand." I
believe the answer is you want a language which emphasises your
personal expressive power and not which which emphasises the
team's/project's/group's power.
A discussion on the pros and cons of macros has come up on c.l.py
before so there's no need to respond to it now, I'm just pointing
out what I was hoping to see and why I found this to be less
than that.
I read your mention that Lisp allows recoverability at the place
where the exception took place. I recall reading in my progamming
languages book back in college that that ends up not being all that
useful, but I can't provide a reference for that now. In my
own current thinking, I agree with the book.
I've used exceptions for many years now, and while thinking about
that book's comment. I haven't found a place where I needed
continuation from the exception point but many where continuations
would be harder to handle. For example, sometimes when the error
occurs I need to raise different exceptions given the results,
possibly after doing a bit of probing. If all exceptions offered
rerun-at-raise point, this means my code needs to handle a return
to that point, followed by (in essense) a rerun of the code which
caused the error. This can be tricky.
So I would also have prefered more examples of why a feature was
not only available in Lisp but why that feature is useful for
most programming tasks. (And you are a fan of "practical things
that you need in every-day programming" so should stress usefulness
over ability.)
Andrew
da...@dalkescientific.com
Sean 'Shaleh' Perry
>
> The core is extremely simple:
>
> This is a piece of program in Lisp: (gethash "key" table)
> This is some data in Lisp, a list: '(gethash "key" table)
>
> In the first example, we have a call of the function gethash with
> arguments "key" and table. In the second example, we have a list with
> the three elements gethash, "key" and table.
>
> (BTW, this is exactly the reason why Lisp has this seemingly strange
> syntax - you can easily switch between program representation and data
> representation. On the conceptual level, Lisp makes no difference
> between data and programs.)
>
I have picked up lisp a few times and put it back down each time. As I become
a better programmer I find lisp makes more sense. The prefix thing no longer
bothers me because I just parse it as a function call and not algebra like I
learned in school.
What always bothers me though is the quote syntax. '(this text) is different
from (this text). I find that when reading code it is very, very easy to
miss that silly quote. Sure you just learn to look for it but it is still
what irks me most.
Ian Bicking
> What always bothers me though is the quote syntax. '(this text) is different
> from (this text). I find that when reading code it is very, very easy to
> miss that silly quote. Sure you just learn to look for it but it is still
> what irks me most.
I'm not sure if I'm replying to this, or just to all the Lisp syntax
issues that have been raised. But since I've seen so many, I thought
I'd bring Logo to people's attention.
Logo (the teaching language, famous for its turtles) is very much Lisp,
but with some small changes that makes the syntax much simpler. When
Logo is parsed, you use the arity (number of arguments) of a function to
determine the grouping. So, given that RIGHT, LEFT, and FORWARD take
one argument, and PENUP takes none, you can parse:
FORWARD 100 RIGHT 90 PENUP FORWARD 10
into:
(FORWARD 100)
(RIGHT 90)
(PENUP)
(FORWARD 10)
You can use parenthesis to force grouping, for instance when there's
optional arguments. You can also use compound statements, and
essentially each function grabs as many arguments as it needs. It also
happens to have infix operations as a sort of add-on, but you could
ignore that and Logo still has a lot of advantages (the infix can also
be confusing in terms of precedence).
The other detail is that quoted lists use [], so:
REPEAT 100 [FORWARD 100 RIGHT 90]
is actually calling the function REPEAT (not a special form) with two
arguments, 100 and [FORWARD 100 RIGHT 90]. REPEAT could be implemented
as:
TO REPEAT :N :EXPR
IF :N > 1 [EVAL :EXPR REPEAT :N - 1 :EXPR]
END
(Forgot to mention that variables have their own namespace and are
preceded with : -- this is necessary for the syntax to work as well)
The disadvantage to this is that the arity of the function needs to be
known before you can parse the statement. Since most Logos are strictly
interpreted (not byte-compiled or anything) this isn't a problem. A lot
of the same issues with optimization that exist for Tcl also exist for
Logo -- I actually think the languages are very similar (except Logo has
lists instead of Tcl's strings). It also means it can be confusing,
because the reader can't parse the expression without knowledge of the
functions being used. In that way it's vaguely like Forth...
Anyway, I think it's a novel solution to the parenthesis problem. I
also think it's a language that deserves more attention -- in its
domain, I still think it's the most thoughtful and useful language out
there. If Python wants to be used with the very young, it would do well
to take lessons from Logo (and Boxer, a semantically closer language
with some cool ideas). In general Logo is a good language, though.
Ian
Chris Humphries
do not exist. probably the closest thing to that being standardized
is man style on *bsd, or the linux kernel coding doc about coding
standards for code (forget the name).
the people have enough of a time just keeping a language standard,
much less the syntax. i use C syntax of openbsd's man style, lisp
syntax that emacs uses, and python syntax i use at work that we
agreed to use.
standards are syntax are generally relative to what scope you are in
when actually coding, not as some universal rule.
-chris
Erik Max Francis
> On Sun, 2002-11-10 at 01:20, Sean 'Shaleh' Perry wrote:
>
> > What always bothers me though is the quote syntax. '(this text) is
> > different
> > from (this text). I find that when reading code it is very, very
> > easy to
> > miss that silly quote. Sure you just learn to look for it but it is
> > still
> > what irks me most.
...
> Logo (the teaching language, famous for its turtles) is very much
> Lisp,
> but with some small changes that makes the syntax much simpler.
It's fair to point out at this point that Logo does have quoting on
words (the Logo equivalent of Lisp words), but with double quotes
instead of single quotes. (Logo lists don't get quoted in this way,
however.)
Your overall point is valid, though. Logo is actually a Lisp derivative
that is cleverly disguised. The turtle graphics portion of the Logo is
the most widely known feature, but actually within the language it is
almost an afterthought; Logo (Greek for _word_) was originally designed
to manipulate English sentences, which is why the list-forming
construct, for instance, is called SENTENCE.
> The other detail is that quoted lists use [], so:
>
> REPEAT 100 [FORWARD 100 RIGHT 90]
>
> is actually calling the function REPEAT (not a special form) ...
And, in fact, TO (the procedure which creates new procedures) is the
only special form in Logo.
> Anyway, I think it's a novel solution to the parenthesis problem.
I have seen variants of Lisp -- at least notational variants -- that do
a similar thing by eliminating "unambiguous" parentheses. In Lisp
proper, I found this really irritating, because it put the onus on me to
do the parsing. In Logo it makes sense, but in Lisp itself I don't
think it does.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Will I disappoint my future / If I stay
\__/ Sade
The laws list / http://www.alcyone.com/max/physics/laws/
Laws, rules, principles, effects, paradoxes, etc. in physics.
Anton Vredegoor
<joh...@ifi.uio.no> wrote:
>* an...@vredegoor.doge.nl (Anton Vredegoor):
>
>> A computer program has to determine what a certain input means before
>> it can produce output. [...]
>
>You're trolling, right?
FYI, accusing someone of trolling, without providing any explanation
is considered to be rude. Quoting a few lines and relying on the
selfexplanatory nature of ones assumptions is showing a bit of a
selfcentered worldview. To me there's no evidence of trolling in the
quoted lines.
Anton.
Jacek Generowicz
> one sentence: "syntax matters." for people in denial, make it two:
> "yes it really does."
Yes, it really does. The point that most people find difficult to
grasp is that Lisp's syntax is one of its huge strengths. (If you[*]
do not know what I mean by this, but are prepared to have your mind
expanded, then you might want to give Lisp a try. If you do not know
what I mean and are tempted to follow up with comments about the
abundance of parentheses, then don't bother; such discussions are
invariably fruitless. If you already know what I mean ... great.)
> or, rephrased: indentation and "1+1" scare people less than
> parentheses and "(add 1 1)" or something like that.
Sigh ...
jacek > clisp
[large startup message elided]
[1]> (+ 2 3)
5
Recently, I wrote a number-crunching program in Lisp. A typical
function in which look something like this:
(defun Hpp (x s z)
#i(sqrt(Vpp(x s z)-gamma)/(x^2+s^4) -
exp(sin(Tpp(x s))/(2*b1(x s)))))
(Incidentally, Lisp's _syntax_ made it possible for me to write a
macro which automatically re-structures my numerical functions in a
way which makes the program run 17 times faster.)
> but perhaps if lisp were invented thousands of years ago
Perhaps you last looked at Lisp thousands of years ago ...
> before math and the plus (+) operator...
Continuing the clisp session from above:
[2]> (/ 2 3)
2/3
[3]> (+ 1 2/3)
5/3
[4]> (sqrt -1)
#C(0 1)
Hmm ...
jacek > python2.2
Python 2.2.1 (#3, Jun 4 2002, 09:56:27)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.sqrt(-1)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: math domain error
>>> 2/3
0
>>> 1 + 2/3
1
... perhaps Python was invented before math and rational and complex
numbers (yes, I *do* know Python has complex numbers, just FUDding in
your style, yes I *do* know that integer division is Python is being
fixed).
Why, in my opinion, is Lisp less popular? There are a number of
reasons, but the most significant is probably that most people hear a
lot of lies about lisp, before they ever get to hear any of the truth.
Lisp is a slow, interpreted, purely-functional language, in which the
only datatype is the list, it needs specialst hardware to run on, is
solely responsible for the failure of AI, and died over a decade
ago. Right?
(Just in case anyone doesn't get it, _everything_ in the previous
paragraph is a lie.)
[*] Anyone reading this, that is.
Jacek Generowicz
> Another question that could be asked about Lisp is:
> Most people it seems have nothing good to say about lisp:"it's hard to
> read,it's slow, nobody uses it, it's hard to learn etc, etc".
These people, invariably, haven't got a clue about Lisp.
Chad Netzer <cne...@mail.arc.nasa.gov> writes:
> On Friday 08 November 2002 15:48, larry wrote:
> >
> > Why do SOME people think Lisp is a fantastic programming langugae?
> > Are we missing something?
> Because for all it's silly, irritating parenthesis, it got some
> things very right.
Yes ... including the parentheses. [*]
> Whenever I see a new language, I tend to ask myself: "What subset of
> LISP is it trying to do, and what does it give up to do so."
This is the perfect cue for mentioning ...
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C
or Fortran program contains an ad-hoc, informally-specified bug-ridden
slow implementation of half of Common Lisp."
(Some people like to add the caveat: This includes implementations of
Common Lisp.)
[*] Acutally, there are no parentheses in Lisp, but let's leave that
discussion for another day.
Jacek Generowicz
> Lisp is based around singly linked lists while Python uses
> vectors (with efficient random access unlike Lisp lists)
Sigh. More FUD.
Please look at
http://www.lispworks.com/reference/HyperSpec/Body/15_.htm
It is the chapter of the Hypertext version of the Common Lisp ANSI
standard, which describes that which you imply does not exist.
(On second thoughts, don't look at it, because once you have, you may
well become disappointed with what Python has to offer in terms of
arrays.)
> and dictionaries.
http://www.lispworks.com/reference/HyperSpec/Body/18_.htm
(There are also alists and plists which can serve a similar purpose,
and may well be more appropriate is some situations.)
> They are also not especially similar in programming style,
You'll find plenty of people who disagree.
Jens Axel Søgaard
> Rocco Moretti wrote:
>> "Johannes Grødem <joh...@ifi.uio.no> wrote in message
>> news:<lzznsip...@unity.copyleft.no>...
>>
>>> Because Lisp has a powerful macro system, it is actually possible to
>>> have an infix-macro, which lets you use infix-syntax. And you can
>>> write macros to support all sorts of weird syntax, if you want.
>>
>>
>> I've heard this argument a number of times, and have never really
>> bought it. To me it seems equivalent to saying "Because (Brainf*ck/
>> Intercal/ Unlambda/ Malbourge /etc) are Turing Complete, you can write
>> any program in them." Sure, you *can*, but why bother?
>
>
> ...because macros in Common Lisp allow you to do extremely powerful
> things and write very compact code.
[A very nice example]
A frequently asked question for new comers to Python is "Why did
you leave out my favorite loop construction?". I mean, there are always
someone that likes do-while better than repeat-until and vice versa.
In a language with macros such as CommonLisp or Scheme one can use
macros to make new control structures. One example is the "missing"
loop. The point is that the programmer can add to the power of the
language without asking Guido first.
Another example is pattern matching. Scheme is born without, but using a
library written using macros one can use pattern matching the SML-way.
To some extent this objection the objection "There are no macros" has
the same cause as the the reaction to the displine-and-bondage language
Pascal. Is it the language designer or the programmer that has the final
word?
Is new control structures useful? To a newcomer to the world of macros
the answer seems to be no. But once you have gotten uses to the idea,
one an amazing amount of uses. Pascal Constanzas example showed one use.
Michael Hudson
> Michael Hudson <m...@python.net> wrote previously:
> |[1] How many people went "significant indentation! ugh!"?
>
> Oddly many... or at least it seems odd, since I never had that reaction.
> But almost no one held on to that "ugh!" feeling after a couple days of
> using Python. My feeling is that the "ugh!" over Lisp's parentheses
> just never goes away for most people.
Did for me. Using a sensible editor[1] helps a lot.
At first I found it helpful to break everything up into loads of tiny
functions to avoid getting lost in the parens, but after a while you
stop seeing them. Do you count braces in C? I know there aren't so
many, but it's the same sort of thing.
Cheers,
M.
[1] This means Emacs.
--
I wouldn't trust the Anglo-Saxons for much anything else. Given
they way English is spelled, who could trust them on _anything_ that
had to do with writing things down, anyway?
-- Erik Naggum, comp.lang.lisp
Michael Hudson
> On 8 Nov 2002 04:54:01 -0800, oleg_i...@myrealbox.com (Oleg) wrote:
>
> >I don't know much about Python, but I looked at this comparison
> >between Python and Common Lisp (
> >http://www.norvig.com/python-lisp.html ), and I couldn't help but
> >wonder why Python is popular, while Common Lisp and Scheme aren't?
>
> A computer program has to determine what a certain input means before
> it can produce output.
>
> In the years when Lisp was becoming popular the first task -
> interpreting input - was considered to be hard and the other task -
> producing output - was considered to be easy. People *expected* source
> code to be difficult to read for humans.
Did you know that s-exps (i.e. the paren heavy Lisp we know today) was
intended to be a temporary syntax, and that John McCarthy intended to
develop a more familiar syntax for Lisp? Somehow he never did --
maybe because it turned out to be a bad idea?
> Nowadays some people think that interpreting a given message is
> trivial compared to the problem of producing the right output. If the
> computer has to decide that we must have meant something else in order
> to be able to produce the right output: So be it.
>
> As a consequence we can use a more human like language to communicate
> with the computer.
With all the ambiguities that make human languages such fun? Shudder.
Have you used AppleScript?
Cheers,
M.
--
Darned confusing, unless you have that magic ingredient coffee, of
which I can pay you Tuesday for a couple pounds of extra-special
grind today. -- John Mitchell, 11 Jan 1999
Michael Hudson
> According to Michael Hudson <m...@python.net>:
> > { Java, Python, ocaml, Common Lisp, C++, perl }
>
> What language is this funny looking list in? ;-)
You could make it CL with a reader macro...
But it was meant to be a set, as Erik said.
Cheers,
M.
--
If i don't understand lisp, it would be wise to not bray about
how lisp is stupid or otherwise criticize, because my stupidity
would be archived and open for all in the know to see.
-- Xah, comp.lang.lisp
Jacek Generowicz
> As cool as Lisp is, it is too low-level,
This must be some usage of the term "low-level" with which I was not
previously familiar.
> The real problem is that, while Python makes a significant effort to
> accomodate human thinking (i.e., Python lets programmers think like
> humans instead of machines a lot of the time), Lisp doesn't put a high
> priority on this.
Funny, I find that Lisp offers me great help in concentrating on what
I want to do, rather than the details of how I am going to make the
machine do it.
> Python uses infix notation for math. Most humans were brought up to
> understand infix.
So download an infix notation macro ...
> Python is more like C than Lisp at all levels.
?
Would you say that Python is weakly, statically typed, like C, or
strongly, dynamically typed, like Lisp?
How about bindings in Python ... look almost identical to bindings in
Lisp.
Functions are first class objects in Python. Is that similar to C or
Lisp?
Introspection?
Not having to bother with memory management is yet another example of
how Python is more like C than Lisp "at all levels", right ?
> There are many, many factors that determine the poularity of a
> langauge. In this case, I think the main factor is that Python just
> thinks more like we do than Lisp.
I would say that the biggst ones (in no particular order) are
- Python is simpler than Lisp. Entry is easier.
- Most people _know_ that Lisp is a slow, arcane language with the
list as the only data type (and other such lies). Such lies get
repeated, and as a consequence most people don't bother to give Lisp
a single look. Python does not suffer from this.
- Batteries included: Python's library of packages is larger and more
rapidly growing.
Gareth McCaughan <Gareth.M...@pobox.com> writes:
> Carl Banks wrote:
> > The kind of person who writes an infix compiler in Lisp is not the
> > type of person who's going to be daunted by all the parentheses.
> > We're talking about the popularity of Lisp, which (as with all
> > languages) is largely determined by people who are not that kind of
> > person.
>
> The person who writes it needn't be the same as the person who
> uses it. There already exist things that let you use infix
> syntax for mathematics in Lisp; you don't have to write them
> for yourself.
>
> I'm not sure anyone actually *uses* them, mind... :-)
Sure, I do, whenever I have to write involved mathematical
functions. Would never dream of using them for anything else ... just
like I wouldn't dream of writing complex maths in prefix notation.
Pascal Costanza
> Pascal Costanza:
>
>> I have recently switched over to Common Lisp as my language of choice
>> and have written an article about it, to be found at
>> http://www.pascalcostanza.de/lisp/guide.html - you might find it
>> worthwhile.
>
> It's a discussion of Lisp, with only a few points specifically of
> why you switched from Java to Lisp and one mention of Python. (There
> were two references to Monty Python, from which Python the language got
> its name.) I was hoping for a more philosophical rumination of why
> you chose Java over Python. :(
This was merely an accident. Back in 95 I based my diploma thesis on
Java, and this decision was influenced by many factors. It wasn't until
recently that I learned about Python.
> Some points that are weaker in a Python/Lisp comparison are
>
> - Python doesn't have as many "funny names" as Lisp
I guess you are referring to "car", "cdr" and the like. They're actually
not funny but very useful. ("car" returns the first element of a list,
"cdr" the list of all elements but the first. You can also use "first"
and "rest" instead, and also "second", "third", and so on, and also "nth".)
> - Python also does run-time typing rather than static typing
Yes, I like that. :)
> - You say
> > Please remember that due to their syntax, C-like languages and Pascal
> > might also run into trouble when curly braces or begin/end keywords
> > are used incorrectly in conjunction with control statements (like if,
> > while, switch/case, and so on)
>
> But Python doesn't have that problem, given neither braces nor begin/end
> keywords. Indeed, you seem to suggest that all Algol-derived languages
> are like C/C++/Pascal/Java in having explicit delimiters, a separate
> compilation step, static typing,
You're right, I should be more careful with my wording in this regard. I
will check that.
> - You say:
> > A nice thing about Lisp is that it doesn't noticeably distinguish
> > between built-in functions and user-defined functions.
>
> The same is true for Python.
:)
> You talk about Lisp's macro feature. That's come up several times
> on c.l.py. I understand at least theoretically the usefulness of
> macros. However, I am quite worried about the supportability of
> defining your own language on the fly. For the comparison I would
> have like to have seen, I was hoping for comments on the
> maintainability of macros, especially given that some people like
> you have found "them to be conceptually quite simple and easy to
> write" while others find them "seemingly hard to understand." I
> believe the answer is you want a language which emphasises your
> personal expressive power and not which which emphasises the
> team's/project's/group's power.
I don't think that Lisp favors personal expressive power over group's
power. Maybe the group that uses Lisp has to agree on more conventions
than in other languages (but I am not sure about that).
Macros are conceptually very simple: they just process lists of code
before it is actually executed. This gives you lots of power, but of
course you need to be a good programmer to be able to wisely use this
power. Lisp is a programming language for experts.
> I read your mention that Lisp allows recoverability at the place
> where the exception took place. I recall reading in my progamming
> languages book back in college that that ends up not being all that
> useful, but I can't provide a reference for that now. In my
> own current thinking, I agree with the book.
It can be useful in some situations. For example, imagine you have a big
and expensive calculation running, and after, say, three days there is a
little bug in some code section that handles a very special case. In
Common Lisp there's a chance that this bug throws a correctable error
(exception) - this is reported at the Lisp prompt. Then you can correct
the buggy code section and try to restart the calculation at the spot
where the error occurred, without any loss of intermediate results.
Similar situations are conceivable for example in the case of web
applications that you usually don't want to shut down, etc.
I think that correctable errors are less useful in languages that don't
offer some form of interactivity.
> So I would also have prefered more examples of why a feature was
> not only available in Lisp but why that feature is useful for
> most programming tasks. (And you are a fan of "practical things
> that you need in every-day programming" so should stress usefulness
> over ability.)
Thanks a lot for your very useful feedback - I will try to incorporate
it into future versions of my article.
All the best,
Pascal Costanza
> Did you know that s-exps (i.e. the paren heavy Lisp we know today) was
> intended to be a temporary syntax, and that John McCarthy intended to
> develop a more familiar syntax for Lisp? Somehow he never did --
> maybe because it turned out to be a bad idea?
He did. But the programmers who were already using Lisp didn't accept
the new syntax. They preferred s-exps.
Johannes Grødem
>>You're trolling, right?
> [...]
> To me there's no evidence of trolling in the quoted lines.
Oh, come on. You're implying that Lisp's syntax is the way it is
because the makers of Lisp-compilers are unable to parse more
complicated syntax. If you don't think that is trolling, you'd better
put down whatever it is you're smoking and come back later.
--
Johannes Grødem <OpenPGP: 5055654C>
Jacek Generowicz
> However, LISP also was not obvious to me as a 'real-world' language
> because it just always felt like I had to recreate the wheel when I
> used it for anything applicable to a real world application.
Funny, when it comes to wheels (data types/structures and
algorithms/utilities) Common Lisp has the most comprehensive set built
in to the language.
Its weakness is the relative lack of libraries built out of those
components, compared to what you would find for, say, Python.
> In all fairness, my impression of LISP was based around a language I
> had to learn in college and the tasks that were assigned to me.
And such college courses are notorious for giving a very strange (and
damaging) introduction to Lisp, and for giving Lisp a bad name.
Anton Vredegoor
wrote:
>Did you know that s-exps (i.e. the paren heavy Lisp we know today) was
>intended to be a temporary syntax, and that John McCarthy intended to
>develop a more familiar syntax for Lisp? Somehow he never did --
>maybe because it turned out to be a bad idea?
That option seems to be available only to people having access to time
machines.
Wouldn't it be possible to write a macro for Lisp so that it uses
newlines and indentation instead of parens?
I know almost all computer languages are indebted heavily to Lisp and
it still has a lot more to give, but maybe it could accept something
back?
Like having Python "repay the debt"?. (A kind of expression used by
go-players at the time one wins for the first time against the player
that has teached one the game).
>> As a consequence we can use a more human like language to communicate
>> with the computer.
>
>With all the ambiguities that make human languages such fun? Shudder.
Python's way of checking for protocols instead of checking for types,
and handling protocol errors graciously at runtime can be seen -with a
bit of imagination- as leaving a lot of ambiguity in interpreting the
source code.
If I read it correctly psyco even goes a step further in generating
multiple possible execution paths and choosing the fastest path that
doesn't break assumptions. If that's not what Psyco does: Some
processors use a trick like this.
If one insists on early fixation of names to specific types of objects
this may seem to disqualify Python as it would not be "safe and
reliable".
On the other hand for someone that is looking for readable code and
generalizing kinds of operations on objects, the added transparency of
the code can compensate for the loss in "safety and reliability" and
then some! Checking algorithm's instead of syntax introduces
"ambiguity" but its worth the price.
Probably you already know all this, and if my speculations or
formulations - ambiguities are assets that are not politically correct
- are too far off the mark I trust that they will be corrected,
Regards,
Anton.
Alex Martelli
...
> A frequently asked question for new comers to Python is "Why did
> you leave out my favorite loop construction?". I mean, there are always
> someone that likes do-while better than repeat-until and vice versa.
>
> In a language with macros such as CommonLisp or Scheme one can use
> macros to make new control structures. One example is the "missing"
> loop. The point is that the programmer can add to the power of the
> language without asking Guido first.
I think these two paragraphs come closest than any other attempt so far to
answer the question that is this thread's subject.
CL and Scheme have powerful macros, which you can basically use to change
the language in any odd way, WITHOUT the supervision of a superb language
architect like Guido. Python does not: you cannot inflict such deep
changes in the language -- it's always the language Guido designed.
Surprise, surprise: the language that's always itself, always well designed,
is popular; the languages that anybody can change arbitrarily aren't.
Doesn't surprise ME one bit.
It's not the prefix form and the parentheses. Dylan uses infix form, AND
some of its semantics are superb. BUT it has powerful macros... kiss of
death: and, surprise surprise, Dylan isn't popular either.
It's exactly BECAUSE every newcomer longs for some weird set of feechurs
that are better done without, that a language that lets such newcomers add
all the weird things, changing the language itself and turning it from a
(hopefully) well-designed whole to a hodge-podge, is not going to be
popular with the masses. Some brilliant individuals -- a tiny minority --
are no doubt going to use such power wonderfully well, building several
different complex, specialized languages. The rest of us, the vast
majority of the human race, is BY FAR best served by having to use one
well-designed language rather than by letting each make up their own.
*Simplicity* is an often-forgotten but nevertheless crucial criterion of
good design. A slightly harder-to-express but also important criterion is
*unity of vision* -- a system should feel like an integrated whole, not as
a disparate jumble of parts. Python meets both criteria. I believe that
introducing powerful-enough macros to Python would make it more likely than
not for most programmers to break both criteria, and thereby probably doom
Python, too, to eventual obscurity.
Alex
Anton Vredegoor
That's not what I was implying. Possibly what I wrote could give the
impression that I imply that, but this seems highly unlikely to me.
Since there is no quote whatsoever of the relevant lines I don't have
any clue as to how this impression is generated. Maybe it's better to
take a shortcut and to directly say what I *think* I was implying: The
perceived difficulty of the parens (and it doesn't matter at all if
this difficulty is real or imagined) increased Lisp's popularity in
the early days because at that time it was thought that a programming
language worth its wits had to be difficult to read. I hope this is
solved now, and I would like to state again that this whole matter
could have been avoided if quotes had been used. I would like to add
at this stage that "ad hominem" attacks like suggesting that I have
been smoking - peculiar things maybe?- are also considered to be bad
form.
Regards,
Anton.
Jens Axel Søgaard
> It's exactly BECAUSE every newcomer longs for some weird set of feechurs
> that are better done without, that a language that lets such newcomers add
> all the weird things, changing the language itself and turning it from a
> (hopefully) well-designed whole to a hodge-podge, is not going to be
> popular with the masses. Some brilliant individuals -- a tiny minority --
> are no doubt going to use such power wonderfully well, building several
> different complex, specialized languages. The rest of us, the vast
> majority of the human race, is BY FAR best served by having to use one
> well-designed language rather than by letting each make up their own.
Theoretically this could be true. In practice everybody follows the
conventions.
Anders J. Munch
> Michael Hudson wrote:
>
> > Did you know that s-exps (i.e. the paren heavy Lisp we know today) was
> > intended to be a temporary syntax, and that John McCarthy intended to
> > develop a more familiar syntax for Lisp? Somehow he never did --
> > maybe because it turned out to be a bad idea?
>
> He did. But the programmers who were already using Lisp didn't accept
> the new syntax. They preferred s-exps.
I'm curious: what exactly did McCarthy's new syntax look like? Have
you got any pointers to specs, examples or such on the web?
- Anders