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