merits of Lisp vs Python
Mark Tarver
think that one has over the other?
Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.
Mark
Mathias Panzenboeck
I do not know much about Lisp. What I know is:
Python is a imperative, object oriented dynamic language with duck typing, List is a declarative,
functional dynamic language -> those two languages have different scopes.
For more Information:
http://en.wikipedia.org/wiki/Functional_programming
http://en.wikipedia.org/wiki/Object-oriented_programming
http://en.wikipedia.org/wiki/Dynamic_programming_language
http://en.wikipedia.org/wiki/Lisp_programming_language
http://en.wikipedia.org/wiki/Python_%28programming_language%29
Paul Rubin
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
<http://google.com/search?q=python+lisp&btnI=I'm+feeling+lucky>
Mark Tarver
Thanks; a quick read of your reference to Norvig's analysis
http://norvig.com/python-lisp.html
seems to show that Python is a cut down (no macros) version of Lisp
with a worse performance. The only substantial advantage I can see is
that GUI, and Web libraries are standard. This confirms my suspicion
that Lisp is losing out to newbies because of its
lack of standard support for the things many people want to do.
Mark
Fredrik Lundh
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
"can be seen as, by a Lisp programmer", perhaps. it's not like anybody set out
to make a Lisp-with-other-syntax but "failed"...
</F>
Richard Brodie
"Mark Tarver" <dr.mt...@ukonline.co.uk> wrote in message
news:1165582654.9...@79g2000cws.googlegroups.com...
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
Performance claims are always controversial. So, Python is much slower
doing array multiplication, when you hand roll it, instead of using the
standard numerical packages available.
I see that the effbot has already responded the first part.
Istvan Albert
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
or maybe it shows that Lisp is an obfuscated version of Python with
lots of parentheses, backward logic, and complicated constructs that
run faster.
i.
Tim Chase
> think that one has over the other?
Easy...
Python reads like pseudocode
Lisp reads like line-noise (much like most Perl or Ruby code)
Python makes better use of my time as a programmer because it
maps fairly closely to how I think, as well as being easy to pick
up when you've been away from the code for several months.
-tkc
Harry George
It is not just a newbie thing. Even people who are reasonably fluent
in Lisp use Python for many tasks, and some make python the default
with Lisp as a special case. It would probably be fair to say that
the more you know about a variety of languages, the more you
appreciate Python.
--
Harry George
PLM Engineering Architecture
Alex Mizrahi
(you :wrote :on '(Fri, 8 Dec 2006 14:08:09 -0000))
(
??>> seems to show that Python is a cut down (no macros) version of Lisp
??>> with a worse performance.
RB> Performance claims are always controversial. So, Python is much slower
RB> doing array multiplication, when you hand roll it, instead of using the
RB> standard numerical packages available.
heh, do you have "standard numeric packages" for everything? maybe then
we'll make standard programs for everything -- that will obsolete "slow"
"custom scripts" and we'll just use shell to select what program we want to
run?
certainly, it's possible to write code in C and use FFI to access it, but
it's not suitable for rapid prototyping/fast development, when requirements
may change, or you're just experimenting with different methods.
it's interesting than as of bare "interpreter overhead", python is aprox
order of magnitude (10 times) slower than lisp interpreters. it's also
interesting, that python, perl, php and ruby show very similar peformance,
while lisp and scheme implementations show large improvements -- it makes me
think that there's something "pathalogically scripting" in their
specifications (maybe some obligatory use of strings for method dispatch?).
note that i've mentioned "lisp interpreters" above. as for lisp _compilers_,
they run lots faster than lisp interpreters.
please check http://shootout.alioth.debian.org/
to compare Python to Lisp SBCL. lisp is faster more then 10 times in many
benchmarks, and even more than 100 times faster in two benchmarks.
unfortunately there's no lisp interpreters (CLISP) in the benchmark.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi
(you :wrote :on '(8 Dec 2006 06:11:20 -0800))
(
??>> seems to show that Python is a cut down (no macros) version of Lisp
??>> with a worse performance.
IA> or maybe it shows that Lisp is an obfuscated version of Python
hell no, lisp's syntax is much easier than python's since it's homogenous
(and certainly lisp was invented much 30 years before Python, so that's
Python uses Lisp features)
IA> with lots of parentheses,
that make logic more explicit
IA> backward logic,
??
IA> and complicated constructs that run faster.
no, there are no complicted constructs -- just it's designed with 30-year
history in mind, not like "let's make another simple scripting language".
Ken Tilton
Mark Tarver wrote:
> How do you compare Python to Lisp?
Lisp programmers are smarter and better looking. And better programmers.
Not sure if that is what you were after, though.
> What specific advantages do you
> think that one has over the other?
http://www.googlefight.com/index.php?lang=en_GB&word1=parentheses&word2=white+space
Ouch.
hth,kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Wade Humeniuk
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
Since the late 1950's Lisp has participated in the development of
modern (present day) programming practises. It has shaped and been
shaped by the minds of just not programmers, but people involved
in dealing with the larger impacts and possibilities.
Its been there, is here, and will continue to be there in the future.
Lisp is a human construct that is a force to be reckoned with. Its
construction reflects something very deep and fundamental about
computing. So, it depends on what you want.
What do you want?
W
Richard Brodie
"Alex Mizrahi" <udod...@users.sourceforge.net> wrote in message
news:45797a0c$0$49204$1472...@news.sunsite.dk...
> heh, do you have "standard numeric packages" for everything? maybe then we'll make
> standard programs for everything -- that will obsolete "slow" "custom scripts" and we'll
> just use shell to select what program we want to run?
No, I was observing that, faced with a matrix multiplication problem, most
sensible Python developers would do "apt-get install python-numeric" or
equivalent. Trying to do it in pure Python would be the wrong tool for the
job. If you think that's a weakness of Python compared to Lisp, then so
be it.
Rob Thorpe
> Mark Tarver wrote:
> > How do you compare Python to Lisp? What specific advantages do you
> > think that one has over the other?
> >
> > Note I'm not a Python person and I have no axes to grind here. This is
> > just a question for my general education.
> >
> > Mark
> >
>
> I do not know much about Lisp. What I know is:
> Python is a imperative, object oriented dynamic language with duck typing,
Yes, but Python also supports the functional style to some extent.
> List is a declarative,
> functional dynamic language
Lisp is only a functional language in that it support both functional
and imperative programming styles. Duck typing is almost identical to
latent typing in Lisp.
And, Common Lisp at least is object orientated.
> -> those two languages have different scopes.
Their scope is actually very similar. Learn about lisp and you will
soon discover their similarity.
Kay Schluehr
> it's also
> interesting, that python, perl, php and ruby show very similar peformance,
> while lisp and scheme implementations show large improvements -- it makes me
> think that there's something "pathalogically scripting" in their
> specifications (maybe some obligatory use of strings for method dispatch?).
"The most unusual features of the SBCL compiler (which is very similar
to the original CMUCL compiler, also known as Python) is its unusually
sophisticated understanding of the Common Lisp type system and its
unusually conservative approach to the implementation of type
declarations.
These two features reward the use of type declarations throughout
development, even when high performance is not a concern. Also, as
discussed in the chapter on performance (see Efficiency), the use of
appropriate type declarations can be very important for performance as
well."
http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types
If you'd read the docs of the tools you admire you might find the
answers yourself.
Carl Banks
> This confirms my suspicion
> that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.
Whoa there, that's a pretty big logical jump there, don't you think?
Consumer choice can never be boiled down to one thing; there are so
many factors. No one knows the whole answer. I certainly don't. (If
I did, I'd be courteously turning down the Nobel Prize for Economics on
account of being so rich I really didn't need the extra pocket change.)
I have no doubt that what you say is a contributing factor, but if I
had to guess the main reason why Lisp is losing out to newbies, I'd say
it's first impressions. When newbies see Python they say, "Ok, I can
kind of follow that, it doesn't look too hard to learn." When they see
Lisp they say, "WTF IS THAT???"
It's kind of sad, in a way, that a superficiality would be so crucial.
(Not that I think outward appearance is all superficial--I think humans
have evolved and/or learned to regard as beautiful that which minimizes
effort--but it's not the whole story and not basis for a whole
judgment.)
Carl Banks
hankhero
environment, for me that means Slime for Lisp. For Python I have
several years of experience with IDLE and the win32 Ide, and Slime is
the winner. Press a key and the function you are editing is recompiled
and loaded into memory. The crossreference and the object inspector is
very nice. How about fuzzy-complete, I only have to write de-me and
press tab, and I get define-method-combination.
Slime coupled with the paredit structured editing mode, which lets you
edit Lisp code as list structure rather than characters, is a dream.
Pythons advantages are:
Faster startup-time which makes it a good scripting language.
More platforms, there is no Common Lisp on Nokia phones.
Some clever details, like using minus to index vectors from the right.
(aref "hello" -1) gives an error on Lisp, but the character o on
Python.
Another detail I like is that you can choose how to quote strings, in
Python you can write three double-quotes to start a string that can
include anything, quotes, doublequotes and newlines.
You can use double-quote if you want to embed single-quotes "john's" or
single-quote if you want to embed double-quotes '<id="2">'.
Talking about Lisps advantages will take me too long.
/hankhero, a switcher.
Fredrik Lundh
> Consumer choice can never be boiled down to one thing; there are so
> many factors. No one knows the whole answer. I certainly don't.
it's all due to Python's humongous marketing budget, of course. just
imagine what would have happened if someone had spent that much VC money
on Lisp.
</F>
Bjoern Schliessmann
> hell no, lisp's syntax is much easier than python's since it's
> homogenous
Can you give an example? I cannot imagine how homogenity always
results in easiness.
> (and certainly lisp was invented much 30 years before
> Python, so that's Python uses Lisp features)
I think you acknowledged that the syntax is different and not
borrowed?
[many parentheses]
> that make logic more explicit
Can you give an example?
Regards,
Björn
Xpost cll,clp
--
BOFH excuse #166:
/pub/lunch
Soni Bergraj
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
If you wont to put it this way, go for it. But if you care to give it a
closer look, you may understand that Pythons main advantage is not
seizable by feature and performance charts.
Regards,
--
Soni Bergraj
http://www.YouJoy.org/
George Sakkis
> (message (Hello 'Istvan)
> (you :wrote :on '(8 Dec 2006 06:11:20 -0800))
> (
>
> ??>> seems to show that Python is a cut down (no macros) version of Lisp
> ??>> with a worse performance.
>
> IA> or maybe it shows that Lisp is an obfuscated version of Python
>
> hell no, lisp's syntax is much easier than python's since it's homogenous
It sure is easier... if you're a compiler rather than a human. Also a
lightbulb is much easier understood as a bunch of homogeneous elemental
particles.
George
André Thieme
> Some clever details, like using minus to index vectors from the right.
> (aref "hello" -1) gives an error on Lisp, but the character o on Python.
It would not be difficult to add this feature to Lisp.
> Another detail I like is that you can choose how to quote strings, in
> Python you can write three double-quotes to start a string that can
> include anything, quotes, doublequotes and newlines.
> You can use double-quote if you want to embed single-quotes "john's" or
> single-quote if you want to embed double-quotes '<id="2">'.
You could add a reader macro in Lisp that allows you to do the same.
At the moment I would say that one could pretty much add most Python
features to Lisp. Be it slicing, list comprehension, or, if one wants,
Pythons object system.
On the other hand can I see difficulties in adding macros to Python,
or inventing a new object system, or adding new keywords without
changing the sources of Python itself.
André
--
Petter Gustad
> Can you give an example? I cannot imagine how homogenity always
> results in easiness.
CL-USER> (+ 1 2 3 4 5 6 7 8 9 10)
55
CL-USER> (< 1 2 3 4 5 6 7 8 9 10)
T
CL-USER> (< 1 2 3 4 5 6 7 8 9 10 9)
NIL
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Bill Atkins
> I think you acknowledged that the syntax is different and not
> borrowed?
Um, so does that mean that Python couldn't have borrowed other
features?
Bill Atkins
What was the reasoning behind cross-posting this to c.l.p and c.l.l?
This type of question inevitably leads to controversy.
George Sakkis
> On the other hand can I see difficulties in adding macros to Python,
> or inventing a new object system, or adding new keywords without
> changing the sources of Python itself.
Actually, an even bigger difficulty is the rejection of programmable
syntax by Guido, both for the near and distant future:
"Programmable syntax is not in Python's future -- or at least it's not
for Python 3000. The problem IMO is that everybody will abuse it to
define their own language. And the problem with that is that it will
fracture the Python community because nobody can read each other's code
any more."
http://mail.python.org/pipermail/python-3000/2006-April/000286.html.
George
Alex Mizrahi
(you :wrote :on '(8 Dec 2006 08:03:18 -0800))
(
KS> http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types
KS> If you'd read the docs of the tools you admire you might find the
KS> answers yourself.
SBCL is a COMPILER that explains everything. it's interesting why
INTERPRETER like CLISP is faster.
well, it can be type declarations as well, but maybe something other too..
for example, in languages like Python, PHP and JavaScript, as i understand,
by semantics of the language interpreter MUST use dict to call objects
method -- at any time it can be changed, for any object instance. i'm not
sure whether it has to dynamically resolve package's methods doing lookup in
packages dict.
however, in Common Lisp object methods are dispatched on object types, that
is a special language entity, so as long as new types are not introduced,
interpreter can optimize calls how it wants to. the difference is that while
it's still dynamic, dispatch over types are more controlled/optimizable than
dispatch using dict.
then, symbols in common-lisp package cannot be changed according to spec,
thus compiler/interpreter is safe to do optimizations it wants when sees
that symbols (if we want symbols with same names, we can make other package
with them).
then, Common Lisp standard defines what inlining is. i bet most
optimizations in dynamic languages are not possible if inlining is not
enabled -- since any symbol that is not inlined can change it's meaning in
any time.
JShr...@gmail.com
A Beginners' Meta FAQ for comp.lang.lisp:
http://nostoc.stanford.edu/jeff/llisp/cllfaq.html
The purpose of this page is to help those new to Lisp (aka. "newbies")
gain some background before they enter the fray of comp.lang.lisp
(c.l.l). This is not a complete Lisp FAQ! Once you have a sense of Lisp
and of how c.l.l operates you should have no trouble finding all the
additional information you need, either by your own search efforts or
by asking the community. If you have issues with any of the below
please do not send me email. Rather, post on c.l.l in the weekly thread
where this is announced (heading: "*** C.L.L README/FAQ ***").
Alex Mizrahi
(you :wrote :on '(Fri, 08 Dec 2006 17:31:08 +0100))
(
??>> hell no, lisp's syntax is much easier than python's since it's
??>> homogenous
BS> Can you give an example? I cannot imagine how homogenity always
BS> results in easiness.
homogenity means that i can cut any expression and paste in any other
expression, and as long as lexical variables are ok, i'll get correct
results -- i don't have to reindent it or whatever.
this is aproximately what programmer does -- he paste pieces of code from
his mind into the program.
BS> [many parentheses]
??>> that make logic more explicit
BS> Can you give an example?
also, there's no need for operator precendence to be taken in accound --
order is explicitly defined. expressions are homogenous, they do not depend
on other expressions near them (except lexical variables and side effects).
the other example of homogenous syntax is XML, that is very popular
nowadays, and it's very similar to lisp's s-expressions.
certainly, it's a matter of taste what syntax to prefer -- i prefer lisp
syntax, others might prefer Python, ML or Haskell syntax.
but homogenous syntax is very important for true macros.
??>> (and certainly lisp was invented much 30 years before
??>> Python, so that's Python uses Lisp features)
BS> I think you acknowledged that the syntax is different and not
BS> borrowed?
certainly
Fredrik Lundh
> Sounds like it's time for:
>
> A Beginners' Meta FAQ for comp.lang.lisp:
>
> http://nostoc.stanford.edu/jeff/llisp/cllfaq.html
>
> The purpose of this page is to help those new to Lisp (aka. "newbies")
> gain some background before they enter the fray of comp.lang.lisp
so why are you posting this to comp.lang.python ?
</F>
Mark Tarver
I don't mind controversy - as long as there is intelligent argument.
And since it involves Python and Lisp, well it should be posted to both
groups. The Lispers will tend to say that Lisp is better for sure -
so it gives the Python people a chance to defend this creation.
I'm looking at Python and I see that the syntax would appeal to a
newbie. Its clearer than ML which is a mess syntactically. But I
don't see where the action is in Python. Not yet anyway. Lisp syntax
is easy to learn. And giving up an order of magnitude is a high price
to pay for using it over Lisp.
Mark
Rob Thorpe
> (message (Hello 'Kay)
> (you :wrote :on '(8 Dec 2006 08:03:18 -0800))
> (
>
> KS> http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types
>
> KS> If you'd read the docs of the tools you admire you might find the
> KS> answers yourself.
>
> SBCL is a COMPILER that explains everything. it's interesting why
> INTERPRETER like CLISP is faster.
> well, it can be type declarations as well, but maybe something other too..
I agree with your other points. Python allows the programmer to
override absolutely anything, including things like addition. This
entails extra work.
It's also worth mentioning that Clisp is an hugely optimized
interpreter. A much work has been put in to making it's bytecode
interpreting inner loops as fast as possible.
Kaz Kylheku
> I don't mind controversy - as long as there is intelligent argument.
> And since it involves Python and Lisp, well it should be posted to both
> groups. The Lispers will tend to say that Lisp is better for sure -
> so it gives the Python people a chance to defend this creation.
And that would be our confirmation that this is another trolling
asshole.
Jan Dries
> RB> Performance claims are always controversial. So, Python is much slower
> RB> doing array multiplication, when you hand roll it, instead of using the
> RB> standard numerical packages available.
>
> heh, do you have "standard numeric packages" for everything? maybe then
> we'll make standard programs for everything -- that will obsolete "slow"
> "custom scripts" and we'll just use shell to select what program we want to
> run?
I think you're missing the point. You must know your language's
strengths and weaknesses, and use the approach/function/library that's
right for the job in the given language.
For instance, on my machine the following Python-code:
some_string = ""
while len(some_string) < 100000:
some_string += "*"
outperforms the following C-code:
strcpy(some_string,"");
while(strlen(some_string) < 100000)
strcat(some_string,"*");
by roughly *factor 15*!
The point of course is you shouldn't be using strlen/strcat this way,
nor use this piece of code as a reference for benchmarking C versus
Python performance.
And for the same reason: in the presence of excellent optimized Python
libraries for matrix multiplication, you probably shouldn't be doing
that in pure Python if performance matters, nor use that as a reference
case in benchmarking Python.
Regards,
Jan
Mark Tarver
This would be a confirmation that you are ignorant in your manners and
don't know how to address a straight question.
Mark
Bjoern Schliessmann
> Um, so does that mean that Python couldn't have borrowed other
> features?
No, but he used this point in direct conjunction with the syntax. At
least by my understanding.
Regards,
Björn
Xpost cll,clp
--
BOFH excuse #61:
not approved by the FCC
Bjoern Schliessmann
> Bjoern Schliessmann <usenet-mail-03...@spamgourmet.com>
>> Can you give an example? I cannot imagine how homogenity always
>> results in easiness.
> CL-USER> (+ 1 2 3 4 5 6 7 8 9 10)
> 55
>
> CL-USER> (< 1 2 3 4 5 6 7 8 9 10)
> T
> CL-USER> (< 1 2 3 4 5 6 7 8 9 10 9)
> NIL
Please forgive me, it's too easy for me to understand.
Regards,
Björn ;)
Xpost cll,clp
--
BOFH excuse #262:
Our POP server was kidnapped by a weasel.
Pillsy
[...]
> Pythons advantages are:
> Faster startup-time which makes it a good scripting language.
I agree with the others (especially the cleverness of Python's string
quoting), but on my machine, SBCL starts up and runs a "Hello World"
program a bit faster than Python, and CLisp really blows its doors off.
Cheers, Pillsy
Bjoern Schliessmann
> (message (Hello 'Bjoern)
>> BS> Can you give an example? I cannot imagine how homogenity
>> always BS> results in easiness.
> homogenity means that i can cut any expression and paste in any
> other expression, and as long as lexical variables are ok, i'll
> get correct results -- i don't have to reindent it or whatever.
Ah, so *that's* what you meant ... but I don't really understand the
ease of it.
> also, there's no need for operator precendence to be taken in
> accound -- order is explicitly defined. expressions are
> homogenous, they do not depend on other expressions near them
> (except lexical variables and side effects).
Sorry, I don't get it ;) Where does Python have things like
nonexplicit defined operator order?
> the other example of homogenous syntax is XML, that is very
> popular nowadays, and it's very similar to lisp's s-expressions.
Spoken freely, I don't like XML because it's hardly readable. Is
it "easy"? If yes, what's your definition of "easy"?
Regards,
Björn
Xpost cll,clp
--
BOFH excuse #437:
crop circles in the corn shell
Neil Cerutti
On 2006-12-08, Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
> I'm looking at Python and I see that the syntax would appeal to
> a newbie. Its clearer than ML which is a mess syntactically.
And if you stew it like applesauce, it tastes more like prunes
than rhubarb does.
> But I don't see where the action is in Python. Not yet
> anyway. Lisp syntax is easy to learn. And giving up an order
> of magnitude is a high price to pay for using it over Lisp.
I find it easier to learn syntax than special forms. But either
system comes naturally enough with practice.
--
Neil Cerutti
Aahz
Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
>
>I'm looking at Python and I see that the syntax would appeal to a
>newbie. Its clearer than ML which is a mess syntactically. But I
>don't see where the action is in Python. Not yet anyway. Lisp syntax
>is easy to learn. And giving up an order of magnitude is a high price
>to pay for using it over Lisp.
Speaking as someone who had been programming for more than twenty years
before learning Python (including a brief gander at Lisp), and also
referring to many years of observations of newcomers to Python: Python's
syntax also appeals to experienced programmers.
I would say that your statement about Lisp syntax is wrong. Not that it
is technically inaccurate, but that it completely misses the point, so
much so that it is wrong to say it. One of the key goals of Python is
readability, and while it is indeed easy to learn the rules for Lisp
syntax, observational experience indicates that many people (perhaps even
the vast majority of people) find it difficult to learn to read Lisp
programs.
As for your claims about speed, they are also nonsense; I doubt one
would find an order of magnitude increase of speed for production
programs created by a competent Lisp programmer compared to programs
created by a competent Python programmer.
Consider this: Lisp has had years of development, it has had millions of
dollars thrown at it by VC firms -- and yet Python is winning over Lisp
programmers. Think about it.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Member of the Groucho Marx Fan Club
Ken Tilton
Bjoern Schliessmann wrote:
> Alex Mizrahi wrote:
>
>>(message (Hello 'Bjoern)
>
>
>>> BS> Can you give an example? I cannot imagine how homogenity
>>> always BS> results in easiness.
>
>
>
>>homogenity means that i can cut any expression and paste in any
>>other expression, and as long as lexical variables are ok, i'll
>>get correct results -- i don't have to reindent it or whatever.
>
>
> Ah, so *that's* what you meant ... but I don't really understand the
> ease of it.
Code in the abstract exists as a tree of trees. With parens, we now have
textual markers delimiting these trees. That means I can point to any
arbitrary subtree by pointing to its left or right parens, and tell the
editor to copy or delete "that chunk of logic". And now I am
manipulating chunks of program logic instead of text.
One simple but hopefully illustrative example: suppose I have an if
statement with two big branches. My code then looks like:
(if (condition) (big-branch-1)(big-branch-2))
Please remember that any of those fakes can be arbitrarily deep nested
expressions. Now during refactoring, I decide bb-2 processing goes
elsewhere, maybe somewhere "upstream" in the logic. So I double-click
and then drag-and-drop, or cut and paste.
Then I double-click on the entire if statement, and then do a
control-click on the "then" condition, control-click happening to mean
"paste what I am clicking". Suddenly the "then" is the whole form.
(And, yes, this means my vendor took away from me the normal
copy-and-drop associated with control click <g>, but I could modify
things to get it back if I really cared.)
Of course the next question has to be, how often does that come up? When
refactoring it sometimes feels like I do nothing else. :) It turns out
that this is an insanely natural way to work with code.
Note also that after any amount of dicing I simply hit a magic key combo
and the editor reindents everything. In a sense, Lisp is the language
that handles indentation best.
hth, ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton
Aahz wrote:
> In article <1165598576.6...@16g2000cwy.googlegroups.com>,
> Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
>
>>I'm looking at Python and I see that the syntax would appeal to a
>>newbie. Its clearer than ML which is a mess syntactically. But I
>>don't see where the action is in Python. Not yet anyway. Lisp syntax
>>is easy to learn. And giving up an order of magnitude is a high price
>>to pay for using it over Lisp.
>
>
> Speaking as someone who had been programming for more than twenty years
> before learning Python (including a brief gander at Lisp), and also
> referring to many years of observations of newcomers to Python: Python's
> syntax also appeals to experienced programmers.
>
> I would say that your statement about Lisp syntax is wrong. Not that it
> is technically inaccurate, but that it completely misses the point, so
> much so that it is wrong to say it. One of the key goals of Python is
> readability, and while it is indeed easy to learn the rules for Lisp
> syntax, observational experience indicates that many people (perhaps even
> the vast majority of people) find it difficult to learn to read Lisp
> programs.
No programming language is easy to read, and no Lisp programmer stopped
using Lisp because they had been using it for a month and just could not
get used to reading it. So I think you are just making things up. :)
> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.
Haha, what's the score? And how much time is left in the first quarter?
:)
Alex Mizrahi
(you :wrote :on '(Fri, 08 Dec 2006 19:57:28 +0100))
(
??>> also, there's no need for operator precendence to be taken in
??>> accound -- order is explicitly defined. expressions are
??>> homogenous, they do not depend on other expressions near them
??>> (except lexical variables and side effects).
BS> Sorry, I don't get it ;) Where does Python have things like
BS> nonexplicit defined operator order?
you have an expression 3 + 4 which yields 7.
you have an expression 4 * 1 which yields 4.
if you paste 3 + 4 in place of 1, you'll have 4 * 3 + 4 = 16. as we know, *
is commutative, but 3 + 4 * 4 = 19.
so result depends on implicit operator precendence rules.
in lisp, if you paste (+ 3 4) in (* 4 1), you'll have (* 4 (+ 3 4)), and it
does not depend on order of operands, (* (+ 3 4) 4) yields same results. you
do not have to remember precendence rules -- * and + are not anyhow special
from other functions. all you need to remember is how to call functions.
certainly it's a very simple example, but it shows that generally, homogeous
lisp syntax make expressions much less dependant on context, and there are
much less rules affecting it. thus, work require by brain to understand and
write code can be reduced -- that way it's easier.
Common Lisp specification define internal languages that are not in
homogenous s-expr syntax -- that is formatter and loop macro.
like
(loop for i from 1 to 20 collect i)
or
(loop for e in list
maximizing e into max
minimizing e into min
finally (return (values min max)))
remarkable thing about that is that it's the only place which i cannot
remember and need to lookup quite frequently in the reference.
although it looks almost like plain english and looks quite easy, it's much
harder than other parts of lisp that use uniform syntax.
but certainly this uniform syntax doesn't worth much without macro
facilities.
i'll show an example from my recent experiments.
in this example we want to perform a query into a RDF database
(triplestore), SPARQL-style query, and then we format results as HTML.
here's how it looks in the SPARQL (i'm not fluent in it, so it can be
buggy). basically, we want to query information (firstname, lastname,
salary) or all users in specified departament.
PREFIX myapp: <https://mydomain.net/myapp/1.1/>
SELECT ?fname, ?lname, ?salary
WHERE
{
?user myapp:name ?uname.
?uname myapp:first-name ?fname.
?uname myapp:last-name ?lname.
?user myapp:salary ?salary.
?user myapp:department ?dept.
}
we should feed this text to the query-builder.
then we should bind ?dept to our variable departament (i'm not sure how this
is done in SPARQL, but there should be a way).
then we should iterate over results and output HTML. a python-like
pseudocode:
query = BuildQuery(query_str)
query.bind("?dept", departament)
results = query.execute()
for each rs in results:
print "<tr><td>" + htmlesc(rs.get("?fname")) + "</td><td>" +
htmlesc(rs.get("?lname")) + "</td><td>" + rs.get("?salary") + "</td></tr>"
so how uniform syntax and macros can help here? we can make a macro
rdf:do-query that will both programmatically create query, bind input
variables and then bind results into local variables. also we can wrap HTML
output in a macro too.
so here's a code:
(rdf:do-query
((?user :name ?uname)
(?uname :first-name ?fname)
(?uname :last-name ?lname)
(?user :salary ?salary)
(?user :department department))
(html (:tr
(:td (:princ ?fname))
(:td (:princ ?lname))
(:td (:princ ?salary)))))
as you can find, it's two times less code, it's less clumsy, and there's
even less quotes and parentheses there -- who says that lisp has more
parentheses? also, this code is less error-prone, because some part of
correctless can be checked during compilation time by macros, because it
operates with symbols on semantic level, but not with simple strings.
for example, if i make a type and write ?fnme instead of ?fname in the HTML
output, compiler will report a warning about unbound variable, but if this
variable will be in string-form, compiler will not be able to.
there are other benefits: RDF query language is transparently integrated
into Lisp, there's no need to learn some other language (SPARQL) syntax
additionally. and it strains my brain less when i don't have to switch
between different languages.
is it possible to construct such helper functions (or whatever) to simplify
code in Python?
Stephen Eilert
Alex Mizrahi escreveu:
>
> we should feed this text to the query-builder.
> then we should bind ?dept to our variable departament (i'm not sure how this
> is done in SPARQL, but there should be a way).
> then we should iterate over results and output HTML. a python-like
> pseudocode:
>
> query = BuildQuery(query_str)
> query.bind("?dept", departament)
> results = query.execute()
> for each rs in results:
> print "<tr><td>" + htmlesc(rs.get("?fname")) + "</td><td>" +
> htmlesc(rs.get("?lname")) + "</td><td>" + rs.get("?salary") + "</td></tr>"
I just want to add that this kind of HTML mixed with code is something
that should be avoided, no matter what language is used.
Stephen
Kay Schluehr
object dictionary dispatch.
But do the performance differences vanish when only builtin types and
functions are used to express Python algorithms?
Chris Mellon
results = doQuery(department="Accounting")
for row in results:
for field in ["fname","lname","salary"]:
print "<td>%s</td>" % htmlesc(row[field])
I hide away the binding etc in doQuery as the lisp version does. Note
that in any kind of real code most of the literals that take up the
space are likely to come from elsewhere.
Note how much more trivial it is to change the HTML output of this
version that the lisp - it's a matter of creating a format string,
which you can retrieve from just about anywhere, rather than requiring
a code refactoring. Just because you have macros doesn't mean it makes
sense to use them.
>
> Stephen
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Rob Warnock
+---------------
| hankhero wrote:
| > Pythons advantages are:
| > Faster startup-time which makes it a good scripting language.
|
| program a bit faster than Python, and CLisp really blows its doors off.
On my various machines, CMUCL startup is *slightly*
faster than CLISP, but both are under 20 ms...
I use Common Lisp for scripting a *lot*!
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
JShr...@gmail.com
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
(Common) Lisp is the only industrial strength language with both pure
compositionality and a real compiler. What Python has is stupid slogans
("It fits your brain." "Only one way to do things.") and an infinite
community of flies that, for some inexplicable reason, believe these
stupid slogns. These flies are, however, quite useful because they
produce infinite numbers of random libraries, some of which end up
being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
is rapidly replacing Perl, and Ruby is simultaneously and even more
rapidly replacing Python. Each is closer to Lisp than the last; the
world is returning to Lisp and is dragging the flies with it.
Eventually the flies will descend upon Lisp itself and will bring with
them their infinite number of random libraries, and then things will be
where they should have been 20 years ago, but got sidetracked by Tcl
and other line noise.
Fred Gilham
A suggestion is to mention Dylan as a possibility to people who think
Lisp syntax is too funky but want to see something Lisp-like.
--
Fred Gilham gil...@csl.sri.com
Progressive (adj): Value-free; tolerant; non-judgemental.
E.g. traditional archery instruction methods spent tedious hours
teaching the archer to hit a bulls-eye. Progressive methods achieved
better results by telling the student archer to shoot in the manner he
or she found most comfortable, then calling whatever the arrow hit the
bulls-eye.
Paddy
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
I've never programmed in Lisp but I have programmed in Cadence Skill a
Lisp inspired language with infix notation as an option. I found Skill
to be a very powerful language. At the time I new only AWK, C, Pascal,
Forth, Postcript, Assembler and Basic. Skill was superior and I came
to love it.
But that was a decade ago. Now, I'd rather a company integrate Python
into their product as I find Python to be less 'arcane' than Skill;
with more accessible power, and a great community.
.
Analogy time!
You need Pure Maths, but more mathematicians will be working applying
maths to real-world problems. You need research physicists, but more
physicists will be applying physics in the real world. It seems to me
that Lisp and its basis in maths makes people research and develop a
lot of new techniques in Lisp, but when it comes to applying those
techniques in the real world - switch to Python!
Lisp has a role to play, but maybe a language tuned to research and
with its user base would naturally find it hard to compete in the roles
in which dynamic languages such as Python are strongest.
- Paddy.
Klaas
Aahz wrote:
> As for your claims about speed, they are also nonsense; I doubt one
> would find an order of magnitude increase of speed for production
> programs created by a competent Lisp programmer compared to programs
> created by a competent Python programmer.
Lisp can be compiled into an executable that has c-like speeds. It can
be much faster than python.
-MIke
tayssi...@googlemail.com
> I would say that your statement about Lisp syntax is wrong. Not that it
> is technically inaccurate, but that it completely misses the point, so
> much so that it is wrong to say it. One of the key goals of Python is
> readability, and while it is indeed easy to learn the rules for Lisp
> syntax, observational experience indicates that many people (perhaps even
> the vast majority of people) find it difficult to learn to read Lisp
> programs.
I think this holds true for experienced programmers, who often report a
difficult unlearning process with Lisp. However, for people without
preconceptions, the difference is likely less -- after all, many have
painful memories of poorly-taught math and computer classes in school.
So Python's similarity to gradeschool math may not be such a plus.
Richard Stallman explained about a Lisp variant:
"Multics Emacs proved to be a great success -- programming new editing
commands was so convenient that even the secretaries in his office
started learning how to use it. They used a manual someone had written
which showed how to extend Emacs, but didn't say it was a programming.
So the secretaries, who believed they couldn't do programming, weren't
scared off. They read the manual, discovered they could do useful
things and they learned to program."
<http://www.gnu.org/gnu/rms-lisp.html>
But of course this is anecdotal evidence.
> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.
Even now, Lisp still contains radical concepts (as in latin's radix
meaning "root"), and overly radical ideas tend not to dominate in the
marketplace. So we see an incremental progression towards Lisp ideas.
Guy Steele, a central figure in Java, claimed:
"And you're right: we were not out to win over the Lisp programmers; we
were after the C++ programmers. We managed to drag a lot of them about
halfway to Lisp. Aren't you happy?"
<http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html>
But speaking of the marketplace, there's at least one Lisp company
sustaining itself by asking for a cut of its customers' revenues... The
last Lisp implementation I used "merely" asked for thousands per head
per platform. ;)
(Personally, I used Python before being aware of Lisp. Now I use Common
Lisp all the time, though I will recommend Python when I consider it
more appropriate. A few months ago, I missed the Condition System most
when using Python, and also lexical scope. However, it is nice to work
with friends, who know Python and not Lisp.)
Tayssir
Paddy
JShr...@gmail.com wrote:
What is it about Lisp that despite doing everything first, way before
any other language, people don't stop using anything else and
automatically turn to Lisp? Maybe there is more to this everything than
the Lisp community comprehends.
Maybe Lisp is to science, as Python is to engineering - with a slight
blurring round the edges?
- Paddy.
smal...@juno.com
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> just a question for my general education.
>
> Mark
cmp `which clisp` `which python`
/usr/bin/clisp /usr/bin/python differ: byte 25, line 1
HTH
--S
George Sakkis
I know we shouldn't feed the trolls, but this one was particularly
amusing to resist the urge. The joke about lisp's world domination in
some unspecified point in the future never fails to bring a good
chuckle. I heard it's scheduled right after strong AI and before time
travel, is this still the plan? A quick look at
http://www.tiobe.com/tpci.htm may be helpful as a reality check before
you go back to your ivory tower (interesting how close in ratings and
growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).
Ken Tilton
And it interesting that VB is almost three times "better" than Python,
and that a Honda could kick a Lamboghini's ass for it at Laguna Seca:
http://www.googlefight.com/index.php?lang=en_GB&word1=lamborghini&word2=ford
Come on, COBOL is a great language, even has macros (copy ... replacing)
and the worlds greatest case statement, evaluate. We are proud to be its
neightbor.
Duane Rettig
> Mark Tarver wrote:
>
>> How do you compare Python to Lisp? What specific advantages do you
>> think that one has over the other?
>>
>> Note I'm not a Python person and I have no axes to grind here. This is
>> just a question for my general education.
>>
>> Mark
> I've never programmed in Lisp but I have programmed in Cadence Skill a
> Lisp inspired language with infix notation as an option. I found Skill
> to be a very powerful language. At the time I new only AWK, C, Pascal,
> Forth, Postcript, Assembler and Basic. Skill was superior and I came
> to love it.
Remember; Lisp is a program-language programming language. Sometimes,
one programs in Lisp without really knowing it:
http://www.franz.com/careers/jobs/outside/cadence03.21.06.lhtml
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
George Sakkis
Didn't say better, not even in quotes (and btw, if you're only doing
GUI apps in MS, VB is the path of least resistance in many cases, as is
PHP for quick'n'dirty web apps). What was funny in the GP's post was
the pomposity about "flies eventually descending upon Lisp itself", as
if language popularity (or any popularity for that matter) is
determined solely by theoretical computer science metrics.
George
JShr...@gmail.com
I think that time travel predated strong AI, although I'm not sure
since it's a little hard to pin down the time coordinates of time
travel (probably The Time Machine will do
> A quick look at
> http://www.tiobe.com/tpci.htm may be helpful as a reality check before
> you go back to your ivory tower (interesting how close in ratings and
> growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).
Oh, Right, George... Reality, of course... I completely neglected
random surveys! I suppose that we should all be using VB because this
survey tells us it's the next best things to C++! See that Ruby green
arrow rocketing up behind you, George; better watch your ass, clown. :-)
Paul Rubin
> Thanks; a quick read of your reference to Norvig's analysis
>
> http://norvig.com/python-lisp.html
>
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance. The only substantial advantage I can see is
> that GUI, and Web libraries are standard. This confirms my suspicion
> that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.
There is (IMO) some truth to that, but the flavor of Python
programming is not that much like Lisp any more. Especially with
recent Python releases (postdating that Norvig article) using iterator
and generator objects (basically delayed evaluation streams) more
heavily, Python is getting harder to describe in Lisp terms. It's
moving more in the direction of Haskell.
Paul Boddie
>
> Thanks; a quick read of your reference to Norvig's analysis
>
> http://norvig.com/python-lisp.html
>
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
I'm quite interested in Lisp, at least from the perspective of seeing
how it supports particular kinds of development activities where you'd
have to "do extra laps" with languages like Python, but while it's
possible to frame lots of languages as being Lisp with something
removed, such observations neglect the origins and objectives of those
languages (and the contributions of a number of other languages).
> The only substantial advantage I can see is that GUI, and Web libraries are standard.
This is actually something of a running joke in the Python community.
There's one sort of de-facto GUI library which many people swap out for
one of the many other GUI libraries available, many of which are
actually very good and relate to modern, actively and heavily developed
graphical user interface environments. Meanwhile, Web standardisation
in the Python scene needs more attention, although there's so much
activity and so many end-to-end solutions to choose from that Python is
quite a reasonable choice for Web development.
> This confirms my suspicion that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.
There was a thread on comp.lang.lisp recently [1] where Ian Jackson of
Debian fame attempted to raise awareness of a lack of apparent
community standards for Lisp, amongst other things, at least for those
people developing software for various Free Software platforms. I think
a re-reading of the many and varied responses will give you some ideas
about where the Lisp community stands in that and in other respects.
Paul
[1]
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/ea994085b54de92d
JShr...@gmail.com
Sorry, I missed something here. Why do you need a release to have these
sorts of things? Can't you just expand the language via macros to
create whatever facility of this sort you need... Oh, sorry. You CAN'T
expand the language.... Too bad. I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.
Oleg Batrashev
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> just a question for my general education.
>
> Mark
quite limited knowledge of Haskel, Lisp,Tcl,... .
Im confused with most python answers like triple doublequotes.
For me python is 'strong OOP' scripting language in first place.
Inheritance, generalization and every kind of abstractions togeteher
with clean and simple syntax make python perfect language for medium
size "scripting" projects (ie just explore the code and add your
features, no messing with compilers). Exceptions, finally/except
blocks, automatic reference counts and destructors make it easy to
write "robust" code. Packaging system and libraries are just fine.
So, python is just C++ combined with elegancy of Java and simplicity of
scripting.
Again, Im not Lisp programmer, so would like to here about mentioned
features, do those things work as nicely, especially OOP ones?
And IMHO paren misfeature is bad, although you claim it to has some
advantages. Mostly, when I copy code in python I just need to call
increase-left-margin emacs macro and there are no mentioned a+b*c
problem. So, I imagine my typical 1-2 page, max 4-5 nested python
function with great readabilty and almost no refactoring problems and I
need to add 20*2 parens to make it homogenous. :)
Oleg
bearoph...@lycos.com
> Sorry, I missed something here. Why do you need a release to have these
> sorts of things? Can't you just expand the language via macros to
> create whatever facility of this sort you need... Oh, sorry. You CAN'T
> expand the language.... Too bad. I guess waiting for Guido to figure
> out what Fits Your Mind is part of The Python Way.
There are few programmers that are very intelligent and know how very
well how to design languages, so they can invent such things. They are
able to manage and appreciate the more freedom Lisp gives them. But
*most* other programmers aren't intelligent enough for that, or they
don't know enough language design to produce something working or
something nice. So maybe Lisp is for the more intelligent people, or
for really difficult programs (or for dynamic and flexible programs
that have to run quite faster than Python+Psyco code), where having a
bit simpler language isn't an advantage. All the other people use
Python that contains things already well designed for them, such
language constructs are the same for everybody, they are standards of
the language, like generators, so reading each other code is simpler
and faster too.
Bye,
bearophile
Paul Rubin
> > There is (IMO) some truth to that, but the flavor of Python
> > programming is not that much like Lisp any more. Especially with
> > recent Python releases (postdating that Norvig article) using iterator
> > and generator objects (basically delayed evaluation streams) more
> > heavily, Python is getting harder to describe in Lisp terms. It's
> > moving more in the direction of Haskell.
>
> Sorry, I missed something here. Why do you need a release to have these
> sorts of things? Can't you just expand the language via macros to
> create whatever facility of this sort you need...
Huh? Are you saying Lisp systems never release new versions? And you
can't implement Python generators as Lisp macros in any reasonable
way. You could do them in Scheme using call-with-current-continuation
but Lisp doesn't have that.
> Oh, sorry. You CAN'T
> expand the language.... Too bad. I guess waiting for Guido to figure
> out what Fits Your Mind is part of The Python Way.
Now I begin to think you're trolling.
bearoph...@lycos.com
> Sorry, I missed something here. Why do you need a release to have these
> sorts of things? Can't you just expand the language via macros to
> create whatever facility of this sort you need... Oh, sorry. You CAN'T
> expand the language.... Too bad. I guess waiting for Guido to figure
> out what Fits Your Mind is part of The Python Way.
There are few programmers that are very intelligent and know how very
Carl Banks
> What Python has is stupid slogans
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> stupid slogns.
IOW, you posted the FAQ so you could appear to have highest moral
ground, then you ignore your own advice and promptly head to the very
lowest ground with ad hominem insults. Congratulations! That was
quite a turnaround.
(In fact, it was almost as a big a turnaround as a typical newbie who
tries Lisp.)
Carl Banks
JShr...@gmail.com
> way. You could do them in Scheme using call-with-current-continuation
> but Lisp doesn't have that.
Well, okay, Scheme [same thing (to me), although I realize that they
aren't, quite -- and CWCC is one place where they aren't!] But I don't
follow why you can't come very close by appropriate macrification of
closures. OTOH, this could be my lack of knowledge; it's possible that
Python has somehow gone beyond what one can reasonably do in this way.
But anyway, this wasn't the point of my post; rather, my point was that
Python can't be extended at all (or at least not in the same way that
Lisp can be), not that a given extension can or cannot be done in Lisp.
Bill Atkins
> Huh? Are you saying Lisp systems never release new versions? And you
He's pretty clearly not saying that.
Paul Rubin
> Well, okay, Scheme [same thing (to me), although I realize that they
> aren't, quite -- and CWCC is one place where they aren't!] But I don't
> follow why you can't come very close by appropriate macrification of
> closures.
You have to be able to return from the closure, then re-enter it
(possibly from a different place in the calling program) with all the
lexical variables intact. You have to be able to do this from
multiple places inside the closure. You have to be able to re-enter
and re-exit other such closures between the entry and exit of the
first one. This all has to work with closures that are recursive.
Yeah, Lisp macros are Turing-complete and you could basically
implement a coroutine-supporting compiler out of macros and do all of
the above, but the target language wouldn't be Lisp any more.
JShr...@gmail.com
> implement a coroutine-supporting compiler out of macros and do all of
> the above, but the target language wouldn't be Lisp any more.
First off, it probably would be Lisp, but this is a mere issue of
semantics. More importantly, even if I grant you that it's not trivial
(which I'm happy to so stipulate) my point was that YOU COULD do this
if YOU wanted, whereas in Python, YOU COULD NOT unless GUIDO wanted.
QED.
Bill Atkins
> I would say that your statement about Lisp syntax is wrong. Not that it
> is technically inaccurate, but that it completely misses the point, so
> much so that it is wrong to say it. One of the key goals of Python is
> readability, and while it is indeed easy to learn the rules for Lisp
> syntax, observational experience indicates that many people (perhaps even
> the vast majority of people) find it difficult to learn to read Lisp
> programs.
You see, this is what I meant by "controversy." As much as I'd like
to ignore this whole discussion, I will eventually read something like
the above and feel compelled to respond, thus ensuring that the thread
continues until eventually everyone gives up and we end up....exactly
where we started. (thanks again, Mark Tarver)
This is a silly claim. What observational experience are you talking
about? Lisp is delightfully readable. In fact, I find it more
readable than any other language. Why do you think that is? Could it
be because I use Lisp on a daily basis? Could that also explain why
Python seems more readable than Lisp to you?
> As for your claims about speed, they are also nonsense; I doubt one
> would find an order of magnitude increase of speed for production
> programs created by a competent Lisp programmer compared to programs
> created by a competent Python programmer.
Nonsense? Hardly. Most Lisp implementations compile to native code,
and can take advantage of fifty years of research into making Lisp
compile into efficient code. You are correct, though: the difference
would probably be a little more than an order of magnitude.
> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.
OK, I'm thinking about it. What was supposed to happen?
(BTW, which millions are you talking about? The millions that went
into the AI boom in the 1980's?)
Paul Rubin
> First off, it probably would be Lisp, but this is a mere issue of
> semantics. More importantly, even if I grant you that it's not trivial
> (which I'm happy to so stipulate) my point was that YOU COULD do this
> if YOU wanted,
How?
Paul Rubin
> This is a silly claim. What observational experience are you talking
> about? Lisp is delightfully readable. In fact, I find it more
> readable than any other language. Why do you think that is? Could it
> be because I use Lisp on a daily basis? Could that also explain why
> Python seems more readable than Lisp to you?
Python is more readable than Lisp because it stays readable even if
you don't use it on a daily basis.
Rob Warnock
+---------------
Weird. This is exactly why I use *Lisp* -- because it stays
completely readable even if you don't use it on a daily basis!!!
[That's also why I *don't* use Perl, except when forced to...]
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Paul Rubin
> Weird. This is exactly why I use *Lisp* -- because it stays
> completely readable even if you don't use it on a daily basis!!!
Hmm. I haven't used Lisp in a while and no longer find it so
readable.
Lisp just seems hopelessly old-fashioned to me these days. A
modernized version would be cool, but I think the more serious
Lisp-like language designers have moved on to newer ideas.
alf
> How do you compare Python to Lisp?
A little bit OT but I can not resist it. What always impressed me with
Lisp is that LOGO (any one remembers) is Lisp based yet designed to
teach kids programming. I do not know Lisp but used to program a bit in
LOGO - everything was so natural ...
--
alfz1
samantha
- s
Bjoern Schliessmann wrote:
> Alex Mizrahi wrote:
>
> > hell no, lisp's syntax is much easier than python's since it's
> > homogenous
>
> Can you give an example? I cannot imagine how homogenity always
> results in easiness.
>
> > (and certainly lisp was invented much 30 years before
> > Python, so that's Python uses Lisp features)
>
> I think you acknowledged that the syntax is different and not
> borrowed?
>
> [many parentheses]
> > that make logic more explicit
>
> Can you give an example?
>
> Regards,
>
>
> Björn
>
> Xpost cll,clp
>
> --
> BOFH excuse #166:
>
> /pub/lunch
Gabriel Genellina
> semantics. More importantly, even if I grant you that it's not trivial
> (which I'm happy to so stipulate) my point was that YOU COULD do this
> if YOU wanted, whereas in Python, YOU COULD NOT unless GUIDO wanted.
> QED.
Not true. You could also build closure/coroutine support in pure
python, without needing to change the interpreter. All the required
introspection mechanisms, stack analysis, etc. were there for a long
time.
In fact it was done on 2000 or earlier:
http://mail.python.org/pipermail/python-announce-list/2000-October/000543.html
--
Gabriel Genellina
Pascal Bourguignon
> However, it is nice to work
> with friends, who know Python and not Lisp.)
It would be nicer a friendship if you taught them Lisp...
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Kaz Kylheku
> Lisp just seems hopelessly old-fashioned to me these days. A
> modernized version would be cool, but I think the more serious
> Lisp-like language designers have moved on to newer ideas.
What are some of their names, and what ideas are they working on?
Also, who are the less serious designers?
Bill Atkins
> Lisp just seems hopelessly old-fashioned to me these days. A
Indeed. All the excitement nowadays is centered around youngster
interpreted languages that support type-edit-run development only and
are controlled by a single person. Standardized, mature languages
with good compilers and interactive development just can't keep up
with these modern trends.
David Lees
>> How do you compare Python to Lisp? What specific advantages do you
>> think that one has over the other?
>
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> produce infinite numbers of random libraries, some of which end up
> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> is rapidly replacing Perl, and Ruby is simultaneously and even more
> rapidly replacing Python. Each is closer to Lisp than the last; the
> world is returning to Lisp and is dragging the flies with it.
> Eventually the flies will descend upon Lisp itself and will bring with
> them their infinite number of random libraries, and then things will be
> where they should have been 20 years ago, but got sidetracked by Tcl
> and other line noise.
>
Hmmm. The last time I fooled around with Lisp was 1966 from the Lisp
1.5 Manual Published by MIT in cloth. It was interesting and different
from the other languages I was using, Algol 60, Basic and Macro
assembler for the GE-235 and GE-635. When I read some of the over the
top type hype by Lisp enthusiasts (like the stuff above) it feels like a
flash back to the mid 60's. Personally, I never like Lisp syntax;
Clearly some people, some fanatic judging by this thread :) think easily
in prefix. I am not one of them. Computer languages are tools and
everyone should pick the ones that they are most comfortable and
productive with.
Six years ago, when I drifted back into programming, I had to learn
about Object Oriented programming and C++. I used Python as a means to
update my programming skills (limited though they are) by 30 years or
so. It was a wonderful intro to OO and served me well. I ended up
writing all kinds of little things for work (simple HTTP servers for
load testing, ECAD hacks for the ASIC guys, even a register level chip
simulator) Even better, I find it a pleasure to write small utilities,
to prototype C code and generally do things quickly. I use it by choice
to get things done, not because it is mandated. At my current job as a
Systems Engineer for a large aerospace firm, I do not program daily, but
when I need to write a quick hack, I always use Python.
david
Paul Rubin
> > Lisp just seems hopelessly old-fashioned to me these days. A
> > modernized version would be cool, but I think the more serious
> > Lisp-like language designers have moved on to newer ideas.
>
> What are some of their names, and what ideas are they working on?
http://caml.inria.fr
http://www.haskell.org
etc.
> Also, who are the less serious designers?
The ones like us who waste their time on usenet. ;-)
Steven D'Aprano
> (message (Hello 'Istvan)
> (you :wrote :on '(8 Dec 2006 06:11:20 -0800))
> (
>
> ??>> seems to show that Python is a cut down (no macros) version of Lisp
> ??>> with a worse performance.
>
> IA> or maybe it shows that Lisp is an obfuscated version of Python
>
> hell no, lisp's syntax is much easier than python's since it's homogenous
By that "logic" "BrainF*ck" should be even easier still, since it is even
more homogeneous, with even less syntax.
http://www.muppetlabs.com/~breadbox/bf/
Here's "Hello World" in Brainf*ck:
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++
..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Actually, yes, it is "easier" syntax, if by easier you mean "easier for
the compiler to parse". If you mean "easier for most human beings to
read", then Lisp is easier than Brainf*ck and Python is easier than Lisp.
--
Steven.
Steven D'Aprano
> André Thieme wrote:
>
>> On the other hand can I see difficulties in adding macros to Python,
>> or inventing a new object system, or adding new keywords without
>> changing the sources of Python itself.
>
> Actually, an even bigger difficulty is the rejection of programmable
> syntax by Guido, both for the near and distant future:
Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.
> "Programmable syntax is not in Python's future -- or at least it's not
> for Python 3000. The problem IMO is that everybody will abuse it to
> define their own language. And the problem with that is that it will
> fracture the Python community because nobody can read each other's code
> any more."
>
> http://mail.python.org/pipermail/python-3000/2006-April/000286.html.
I couldn't have said it better myself.
--
Steven.
Ken Tilton
Not sure I understand why, unless you mean folks were raving about Lisp
in the 60s. Today's raving is about a much different language, though
the core elegance remains, and is as much about the contrast with other
languages as it is about the pleasure of Lisp itself. Those raving about
Lisp are quite accomplished at all those other languages, and know about
what they are talking. I doubt the Pythonistas weighing in on this
thread ever got far at all with Lisp, so... should they really be
offering comparative analysis?
> Personally, I never like Lisp syntax;
> Clearly some people, some fanatic judging by this thread :) think easily
> in prefix. I am not one of them.
Yeah, you are, you just did not use it heads down for a month. The way
to tell if you spent enough time on Lisp is to look at Lisp code. If you
see any parentheses, you have not spent enough time. They disappear in a
month.
The typical Pythonista values clean code but trembles in the face of
macros, which exist to hide boilerplate. That means the only thing
showing in any given block of code is exactly the interesting variable
and function names. Talk about readability.
> Computer languages are tools and
> everyone should pick the ones that they are most comfortable and
> productive with.
No, languages are not interchangeable. Python is a fine language, but
Lisp is much more expressive/powerful.
>
> Six years ago, when I drifted back into programming, I had to learn
> about Object Oriented programming and C++. I used Python as a means to
> update my programming skills (limited though they are) by 30 years or
> so. It was a wonderful intro to OO and served me well. I ended up
> writing all kinds of little things for work (simple HTTP servers for
> load testing, ECAD hacks for the ASIC guys, even a register level chip
> simulator) Even better, I find it a pleasure to write small utilities,
> to prototype C code and generally do things quickly. I use it by choice
> to get things done, not because it is mandated. At my current job as a
> Systems Engineer for a large aerospace firm, I do not program daily, but
> when I need to write a quick hack, I always use Python.
Much of Lisp's power would be lost on a non-programmer, but Lisp might
make a programmer out of a non-programmer if they had it in them. You
might have the right language for you because what Python does have is
lotsa libraries, and if you are just hacking scripts to glue together
libraries the expressiveness of Lisp is more than offset by the better
library support in Python.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Wolfram Fenske
Doesn't matter. We are Borg. You will be assimilated. Resistance is
futile. :-)
But seriously, look at how features from Lisp are constantly finding
their way into mainstream programming languages and have done so for
decades (garbage colection, closures, ...). Maybe one day prefix
notation and Lisp style macros will also find their way into other
languages and then Lisp will finally take over. :-) And here's another
thing: All the interesting features that haven't originated from Lisp
(e. g. OO from Smalltalk) could in turn easily be implemented in Lisp
with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
object system, I could write my own as a library and it would be just
as powerful and just as easy to use as the system Common Lisp already
provides. Stuff like this is impossible in other languages.
To summarize: Lispers are not fanatics. And if we appear to be then
it is simply because we recognize that Lisp truly is The Chosen
Language. [1]
Footnotes:
[1] Kidding! :-) ... or am I?
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Steven D'Aprano
>
>
> Aahz wrote:
>> In article <1165598576.6...@16g2000cwy.googlegroups.com>,
>> Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
>>
>>>I'm looking at Python and I see that the syntax would appeal to a
>>>newbie. Its clearer than ML which is a mess syntactically. But I
>>>don't see where the action is in Python. Not yet anyway. Lisp syntax
>>>is easy to learn. And giving up an order of magnitude is a high price
>>>to pay for using it over Lisp.
>>
>>
>> Speaking as someone who had been programming for more than twenty years
>> before learning Python (including a brief gander at Lisp), and also
>> referring to many years of observations of newcomers to Python: Python's
>> syntax also appeals to experienced programmers.
>>
>> I would say that your statement about Lisp syntax is wrong. Not that it
>> is technically inaccurate, but that it completely misses the point, so
>> much so that it is wrong to say it. One of the key goals of Python is
>> readability, and while it is indeed easy to learn the rules for Lisp
>> syntax, observational experience indicates that many people (perhaps even
>> the vast majority of people) find it difficult to learn to read Lisp
>> programs.
>
> No programming language is easy to read,
Well, you've just blown your credibility out the water with that nonsense.
> and no Lisp programmer stopped
> using Lisp because they had been using it for a month and just could not
> get used to reading it.
Or, to put it another way:
"No programmer who learned Lisp ever gave up before he learned Lisp."
I wonder, how many people gave up trying to learn Lisp because the
language was too hard for them to read? Anyone like to bet that the number
was more than zero?
--
Steven.
Ken Tilton
No, but you could have quoted it more completely <g>:
> But please save your breath. Programmable syntax is not in Python's
> future -- or at least it's not for Python 3000. The problem IMO is
> that everybody will abuse it to define their own language. And the
> problem with that is that it will fracture the Python community
> because nobody can read each other's code any more.
The last time c.l.l and c.l.p went to friendly war over macros we kept
wondering why macros were any less comprehensible than functions or
classes. Here it is!:
>
> It's one thing to read code that calls an external function whose
> meaning you have to guess from its name. It's quite another thing to
> realize that you can't even know for sure where the function calls
> are. Let's not go there.
GvR seems to be thinking of something like the loop macro, which in its
most commonly used syntax (it has two!) constitutes a distinct and
unlispy language. If that is how macros were normally used (LOOP is
quite abnormal) then, yikes, every macro could introduce a new language
to be mastered.
Uhhhh, that is not how macros are used normally. And it is a helluva lot
of work to erect a new syntax as LOOP does, so it is not exactly
tempting. So... is GvR being scared off by a straw man?
The other possibility is that he is just trying to justify not doing it
because it would be so hard without the regular syntax of Lisp,
including parens, and with the JIT module resolution problem discussed
earlier in his remarks. Understandable.
A final good reason is, hey, we already /have/ Lisp, Python needs to be
different in order not to get absorbed into the mother of all languages.
hankhero
Python features i could think of that was better than Lisps.
> For me python is 'strong OOP' scripting language in first place.
> Inheritance, generalization and every kind of abstractions togeteher
> with clean and simple syntax make python perfect language for medium
> size "scripting" projects (ie just explore the code and add your
> features, no messing with compilers).
The Common-Lisp object systems has all and more OO-features, some which
you never probably have thought of before. Here's one:
Inheritance lets you specialise a method so a rectangle and a circle
can have a different Draw method. If you wouldn't have OO you would
need a function with if statements to dispatch on thing, if
thing=rectange then drawRectangle if thing=circle then drawCircle.
What if you want a draw method that takes a thing and a backend, then
you need if statements again, draw(self,backend): if backend ==
postscript do one thing else do another.
Maybe you can solve this with multiple inheritance, creating
RectangePostscript and CirclePostscript objects. Lisp supports multiple
inheritance too, but also multimethods which allow a looser coupling
between objects and dispatching on all parameters, not only the first
parameter (self in python speak). Just define one method
draw(rectange,postscript) and another draw(rectangle, pdf)
> Exceptions, finally/except blocks,
Lisp has a unique exception system. Say ReadHtmlTag throws an exception
deep down in your system, UnexpectedChar. In Lisp you can define
recovery strategies all over your system. the IgnoreAttribute recovery
strategy can be in the same method as ReadHtmlTag. You can have another
ways to recover, IgnoreFile, or ReparseFile higher up in your program.
When you catch the error at the highest point in you main function, you
can choose which recovery you want to use. Either IgnoreAttribute and
continue in the ReadHtmlTag method or ReparseFile in the ParseFile
method. The stack and variables will be there right as when the error
occurred. If I write a library I don't have to guess if the users of my
library wan't me to show a nice GUI error message, ignore the error or
whatever. I provide all options and let they choose.
> automatic reference counts and destructors make it easy to
> write "robust" code.
No, Lisp doesn't have anything like that. There is a thing called the
garbage collector however, I think it exists in other languages.
tmh
through python several years ago on the way to lisp. Futhermore, this
is a 2 glass of wine response.
Nota Bene: All references to lisp in this response imply common lisp.
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
Way back, my initial motivation for learning python was the desire for
something to post-process data files with a cleaner syntax than perl.
It did that in spades. Despite having taken a C++ course in college, it
wasn't until I started using python that I grokked concepts of object
orientation. The aforementioned course spent too much time on basic
concepts. I also envisioned being able to rapidly prototype things in
python, then migrate them to C for performance. Long term, that was
going to be the value of python, rapid prototype->C for performance.
After writing a C interface for python to an engineering analysis code,
I realized that there was nothing rapid about prototyping in python
then migrating to C. This was also a period of time where there was
some schizophrenia concerning numpy versus numeric python. I know this
has been hashed out now, but at the time it was a distraction from the
development of the library and I lost patience.
So, I began searching for alternatives. Spent a couple years with a
language that requires everything to be an object. Can someone hand me
a hammer, I have a round peg here and a square hole there. Didn't have
good numeric support, but based on other perceived advantages, I had
hashed out an object system that would have provided numeric support.
As I'm implementing the numeric stuff, I'm getting very annoyed with
changes in the language that are requiring redesign of my objects.
Plus, performance, while not bad, is not the best. The work required
starts to outway the benefits, so here I go again, searching for the
one language to rule them all. That's when I seriously consider lisp.
At this point, if lisp doesn't work out, I'm giving up and going back
to fortran, never to look at another language again. Ever.
So, six months ago, I start digging into lisp. Hmm, lisp promotes
functional programming, but you can do imperative if you really want
to, or objective, or aspect, or your own.
What about types? Well, to quote Yogi Berra, "In lisp, types are not
required until they are required." This is great, I can quickly thrash
out some code, profile, correct the algorithm, profile, add types, bam!
Good performance. Looking over CMUCL/SBCL, really good numeric
performance.
Playing with code that is 30 years old, still runs, nice.
Forced to learn emacs, why was I using vi again? In the correct
settings, slime can be fun. Emacs+SBCL is one setting, I'll let you
think of the other.
What the hell are closures? Oh, yeah, now I get it, functions with
state, I can use that in simulations with state vectors, very
intuitive.
And macros? Well, I don't need a domain specific language, yet, but
using macros to build closures with multiple functions and shoving as
much computation into the compilation stage as possible makes for very
fast iteration over ODE's. Now I'm simultaneously iterating over 3
variations of an ODE in less time than iterating over 1 ODE in the
previous one size fits all language.
Code is data is code. I know, a tired old cliche. But for an engineer
who wastes too much time data processing and not enough time
analyzing/understanding said data, this is very powerful and provides a
warm fuzzy feeling. Yet again, that could be the wine.
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
I've been writing code for engineering solutions for 15 years in
various languages. I've gained more insight into coding in the last 6
months then in the previous 15 years. Since lisp allows you to employ
any and every programming technique, it actually requires you to
understand the techniques well enough to apply them when appropriate. I
still respect python if for no other reason than I learned concepts of
object orientation with it, but I don't consider for my coding.
You should study lisp for at least a year, use it for some decent size
projects. At the end of the day, even if you decide not to continue
using it, you will be a much better coder. My bet, though, is that if
you use it for a year, you won't want to use anything else. Don't be
deterred by the parens or the prefix notation. You will have to rewire
your brain to read lisp code, but the effort is worth it. The parens
disappear and there is an elegance and simplicity to prefix notation
that can't be matched by infix.
Time for some more wine.
Cheers,
Tom
Ken Tilton
Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 14:52:33 -0500, Ken Tilton wrote:
>
>
>>
>>Aahz wrote:
>>
>>>In article <1165598576.6...@16g2000cwy.googlegroups.com>,
>>>Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
>>>
>>>
>>>>I'm looking at Python and I see that the syntax would appeal to a
>>>>newbie. Its clearer than ML which is a mess syntactically. But I
>>>>don't see where the action is in Python. Not yet anyway. Lisp syntax
>>>>is easy to learn. And giving up an order of magnitude is a high price
>>>>to pay for using it over Lisp.
>>>
>>>
>>>Speaking as someone who had been programming for more than twenty years
>>>before learning Python (including a brief gander at Lisp), and also
>>>referring to many years of observations of newcomers to Python: Python's
>>>syntax also appeals to experienced programmers.
>>>
>>>I would say that your statement about Lisp syntax is wrong. Not that it
>>>is technically inaccurate, but that it completely misses the point, so
>>>much so that it is wrong to say it. One of the key goals of Python is
>>>readability, and while it is indeed easy to learn the rules for Lisp
>>>syntax, observational experience indicates that many people (perhaps even
>>>the vast majority of people) find it difficult to learn to read Lisp
>>>programs.
>>
>>No programming language is easy to read,
>
>
> Well, you've just blown your credibility out the water with that nonsense.
I am delighted to learn I had any to begin with.
Perhaps you are thinking of individual lines of code being easy to read.
Sure. I am talking about algorithms. Code cannot be read as if it were
the Sunday comics. At any interesting level of complexity, one has to
slow down and effectively hand-execute code in one's mind, not just read
it as one reads natural language (and some of that makes one slow down
to, no matter how well known are the individual words and grammar).
>
>
>
>>and no Lisp programmer stopped
>>using Lisp because they had been using it for a month and just could not
>>get used to reading it.
>
>
> Or, to put it another way:
>
> "No programmer who learned Lisp ever gave up before he learned Lisp."
That would be the obvious retort, but my observation was empirical, so I
am afraid you need numbers, not word games.
You seem awfully hostile, by the way. Won't that make it harder to
conduct an intelligent exchange of value to lurkers?
> I wonder, how many people gave up trying to learn Lisp because the
> language was too hard for them to read? Anyone like to bet that the number
> was more than zero?
Sorry, no one ever discovered Lisp, decided it would be great for
programming, started learning it and then gave up because they could not
handle the syntax. The syntax is actually easier to master because of
its regularity, and lisp-aware editors handle the parentheses such that
they disappear in a month.
Your position is untenable. It relies on this idea that all these Lisp
programmers not only handle Lisp syntax effortlessly but also praise it
as a significant advantage, they have all mastered several non-Lispy
languages, but...what? They are mutants? Who just happen to have no
problem with C and Java and Prolog and COBOL and Basic? Probably not.
If you are saying someone will glance at a Lisp book and say they cannot
understand it, well, that is not very interesting is it?
Steven D'Aprano
>> There is (IMO) some truth to that, but the flavor of Python
>> programming is not that much like Lisp any more. Especially with
>> recent Python releases (postdating that Norvig article) using iterator
>> and generator objects (basically delayed evaluation streams) more
>> heavily, Python is getting harder to describe in Lisp terms. It's
>> moving more in the direction of Haskell.
>
> Sorry, I missed something here. Why do you need a release to have these
> sorts of things? Can't you just expand the language via macros to
> create whatever facility of this sort you need... Oh, sorry. You CAN'T
> expand the language.... Too bad.
No no, the phrase you want is "too good".
> I guess waiting for Guido to figure
> out what Fits Your Mind is part of The Python Way.
For the benefit of anyone who thinks that the troll has a point, consider
this.
In the real world, programmers aren't lone wolves stalking the programming
landscape doing their own thing. Whether we're talking open
source projects maintained by volunteers, or commercial software teams,
standardized languages are a good thing. It is a good thing that not every
hare-brained idea that some random programmer comes up with can be
implemented as part of the core language.
It is a good thing that when Fred decides to stop contributing to an
open source project (or leave the company), other people can read his code
without having to learn his Uber-Special Custom Macro Extended Language.
Even if Fred's USCMEL ran 35% faster (and thus saved an entire four
seconds on an average run with typical data!) the five or six weeks of
reduced programmer productivity when somebody else has to maintain his
code outweighs that.
--
Steven.
Ken Tilton
tmh wrote:
<snip>
> Time for some more wine.
...and then just cut and paste the snipped bit into:
http://wiki.alu.org/The_Road_to_Lisp_Survey
...if you are not there already. The survey questions are optional and
what you wrote is perfect as is. Tough call on what goes in:
http://wiki.alu.org/RtL_Highlight_Film
Candidates:
"If you use it for a year, you won't want to use anything else."
"I've gained more insight into coding in the last 6 months then in the
previous 15 years."
I'd go with:
"Yet again, that could be the wine."
:)
kt
Paul Rubin
> Not sure I understand why, unless you mean folks were raving about
> Lisp in the 60s. Today's raving is about a much different language,
> though the core elegance remains, and is as much about the contrast
> with other languages as it is about the pleasure of Lisp itself. Those
> raving about Lisp are quite accomplished at all those other languages,
> and know about what they are talking. I doubt the Pythonistas weighing
> in on this thread ever got far at all with Lisp, so... should they
> really be offering comparative analysis?
I've used and implemented Lisp but am not a real expert. Some other
Python newsgroup regulars are very knowledgeable (more than me) about
it. Peter Norvig (author of that comparison page) wrote a Lisp book,
if I remember correctly.
> > Personally, I never like Lisp syntax; Clearly some people, some
> > fanatic judging by this thread :) think easily in prefix. I am not
> > one of them.
The syntax is a pretty superficial thing. The reaction from outsiders
to Lisp's parentheses and Python's indentation-based structure is
about the same. You get used to it either way.
> The typical Pythonista values clean code but trembles in the face of
> macros, which exist to hide boilerplate. That means the only thing
> showing in any given block of code is exactly the interesting variable
> and function names. Talk about readability.
There is just not that much boilerplate in Python code, so there's
not so much need to hide it.
> Much of Lisp's power would be lost on a non-programmer, but Lisp might
> make a programmer out of a non-programmer if they had it in them. You
> might have the right language for you because what Python does have is
> lotsa libraries, and if you are just hacking scripts to glue together
> libraries the expressiveness of Lisp is more than offset by the better
> library support in Python.
Python is more expressive than Lisp in the sense that its built-in
datatypes and simple syntax for using them has to be done through
kludgy macros and libraries with Lisp. I would say Lisp's facilities
for developing very large programs are better, and (for now) Lisp has
much more serious compilers. See the PyPy project for what's
happening in that direction with Python.
Paul Rubin
> with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
> object system, I could write my own as a library and it would be just
> as powerful and just as easy to use as the system Common Lisp already
> provides. Stuff like this is impossible in other languages.
If Common Lisp didn't have lexically scoped variables (most Lisp
dialects before Scheme didn't have them) then it would be very
difficult to add that with macros.
Do you seriously think lexical scoping is the last word in language
features and that there's now nothing left in other languages that
can't straightforwardly be done in CL? Hint:
call-with-current-continuation (also known as call/cc).
I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.
Take a look sometime at Hughes' paper on "Why Functional Programming
Matters":
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.
tayssi...@googlemail.com
This is sort of the top-down philosophy, where you have a "benevolent
dictator" rather than more of a democracy. (People actually call them
benevolent dictators.) Like any other top-down society, the benevolent
dictator tells you that he and his lieutenants are merely protecting
you against anarchism; terrible things will happen if you have too much
freedom.
However, I am paid to write Common Lisp, I've recently seen a terribly
unreadable codebase, and the problem wasn't macros -- merely overuse of
global vars. Nothing exotic.
Do we ban loops and recursion because we face infinite looping? Or, as
"power users," do we do the obvious, which is to learn how to use power
correctly?
How do Lisp users deal with a powerful weapon like macros? Well first,
many people don't define new ones. Instead, they use someone else's
time-tested macros, from some library. However, when they do use
macros, it's to make less readable code more readable.
Is all Python code readable? I somehow doubt it. Is the pressure from
experienced Python users stretching Python away from a clean design? I
suspect it is. (Though I could be wrong, as I don't pay close attention
to Python at the moment.)
I'm not trying to convince anyone that Lisp's radical flexibility here
is "better", just there's a different perspective to consider than what
Guido says. Many in the Lisp community have noticed the frequency of
sentences starting with "Guido said" from the Python world, and maybe
that sounds as disturbing to heavy Lisp users as macros sound to heavy
Python users.
Tayssir
--
"Patriotism is usually the refuge of the scoundrel. He is the man who
talks the loudest."
-- Mark Twain, 1908