merits of Lisp vs Python

[Wade Humeniuk]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

>
But I also gained a little more insight into why Lispers love their
language. I've learnt that well-written Lisp code isn't as hard to read as
I remembered, so I'd just like to withdraw a comment I made early in the
piece. I no longer believe that Lisp is especially strange compared to
natural languages.
>
Anyway, real life catches up on me, and so I must drop out of this thread.
May it not last for ever.
>

And I have heard why Pythonistas like their language. They can get things
accomplished in it. The best positive feedback is success. You can get
lost in theoretical, metaphorical discussions about computer languages.
It is frustrating and in many cases pointless.

As for why you have seen conflicting answers and, yes, sometimes hostile
responses. I have no idea. But, I think I have come to a point in my
life where I do not need to be right.

W

[Stefan Nobis]

Re: merits of Lisp vs Python

Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrites:

Which just proves my point. If people don't share the same language
constructs, the same words, the same grammar, etc, they can't
understand each other.

Yes, but that depends *much* more on social background, habits,
experience than on technical details like correct syntax, orthography
etc. Do you know about studies with texts where the letters of each
word are disordered except the first and the last and nearly everyone
was able to read this (OK, it took a little bit more time, but it was
readable)? So much to the importance of syntax and orthography.

Essentially every group of people, scene, community has it's own
special language and if you want to communicate with them, you have to
learn this language. Excatly the same goes for software projects with
their libraries -- completley independet of the technical background
of the abstractions (functions, classes, macros,...) the libraries
provide.

It's really funny to see how you try to create and defend a purely
factitious line between abstraction techniques like functions,
classes, and even operator overloading and shadowing on the one side
and those big bad macro monsters on the other side.

--
Stefan.

[Paul Boddie]

Re: merits of Lisp vs Python

JShrager@gmail. com skrev:

>
The reason has little to do with macros (although
they were very helpful, of course, esp. in making Tcl look like a
reasonable language so that we could use Tk)

How long ago was this? ;-)

[Macros in Python]

Either people will not use them, and they will languish and die, and then
at least you can say; "Been there, done that" to the Lisp community.

Well, someone did write Logix probably with the intention of getting
interest from the community:

http://livelogix.net/logix/

It's already been noted what the response has been.

Or, more likely, the some subset of the Python community will get it,
and will figure out how useful they are, although it might take some time.

I've been interested in macros for Python, and you'll find other people
with similar views:

http://www.fiber-space.de/EasyExtend/doc/EE.html

That said, you'll find the discussion about macros to be quite open,
occasionally even on the Python development lists. But it is also
important to note that the development and usage of Python is not
guided from purely technical motivations (or from technically pure
motivations), and the heated discussion about natural language
analogies reveals that just as people are content to form communities
around certain kinds of literature, so are people interested in forming
communities around developing certain kinds of systems.

[...]

you will probably be able to maintain and improve your flagging
position wrt Ruby (which, according to Matz, is more-or-less just Lisp
w/o macros.)

I think this would be a fairly weak argument for what would otherwise
be a reasonable suggestion. "Come over to my way of thinking or be
destroyed" sounds like something the Emperor would say to Luke
Skywalker. And we all know how that ended. ;-)

And on the subject of remarks about Python developers somehow being
remote controlled by the BDFL, I think that anyone who takes a closer
look will see varying levels of dissent and dissatisfaction , just as
you'd find in any community. Again, many more issues must be considered
to understand why people keep using Python (or alternatively stop using
it).

Paul

[Kirk Sluder]

Re: merits of Lisp vs Python

In article
<pan.2006.12.10 .16.44.10.80242 9@REMOVE.THIS.c ybersource.com. au>,
Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrote:

On Sun, 10 Dec 2006 14:35:07 +0000, Kirk Sluder wrote:
>

In article
<pan.2006.12.10 .13.28.42.58190 5@REMOVE.THIS.c ybersource.com. au>,
Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrote:

And here I was thinking that languages fell from the sky like donuts!
Gosh, thank you for explaining that too me. What a fool I must seem!

Certainly that is what you wrote. If you had not meant that English
enforces restrictions on expressiveness, perhaps you should not have
written it.

>
Okay, I'm trying to meet a common ground here, but you're not making it
easy. Of course English, like all languages, restricts what can be said in
that language. I'm talking about grammar and syntax, not semantics, just
like I said at the beginning.

Well again, the question is exactly *what* is doing the restricting?
What will happen if you make an "illegal" statement in English? If
you can't define some sort of mechanism inherent in the English
language that prevents the expression of "illegal" utterances, then
you can't make the claim that "English. .. restricts what can be
said in that language." This is a technical point, but not a
trivial one. That is one heck of an active verb that you are
attributing to an extremely passive noun.

If you want common ground, it appears that we both agree that
language practices are enforced by social communities. Is this not
the case?

Oh, you might also like to look up what a straw-man argument is before
continuing to accuse people of making it. There seems to be this myth on
the Internet and Usenet that a straw-man argument is "any argument I don't
like, or don't understand, or can't refute".

Certainly. A straw man is an artificially weak position that you
attribute to your opponent. You chose to argue against the
artificially weak position of "there are no rules." You attributed
that position to me, not acknowledging my stated position. In what
way is this not a straw man?

You now claim to agree with the position I actually stated: language
is restricted by social communities that use language. If we both
agree on this position, we can move on back to the discussion on how
those norms and practices discriminate against unlispy/unpythonic
language extensions.

That might be true in the case of public code which is open to the entire
community, but it isn't true of all code. Not all code is open to the
wider programmer community to inspect. Code gets written in small teams,
or by individuals, and then it gets used by potentially millions of people
who never got to review the code but have to suffer the consequences of
any bugs in it.

What do people who don't need to read code, or don't need access to
code matter in regards to code readability?

And yes, small teams do constitute a linguistic community of
practice as well. But I don't know of many small teams who don't
have histories as members of larger communities of practice.

(I'm not saying this is uniquely a problem caused by Lisp macros. Don't
misinterpret what I'm saying.)

Which comes back around again to my constant question. Why do these
threads consider macros as a way to extend the language so much more
of an obfuscatory threat compared to other methods of language
extension: (including libraries, operator overloading, and
polymorphism?)

[Bill Atkins]

Re: merits of Lisp vs Python

Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrites:

You know, I'm really starting to think that you Lispers -- and I hate to
generalise, but in this case I feel I'm forced to -- have a real problem

You feel you're forced to generalize about an entire group of language
users based on what a handful of people have posted on a newsgroup?

So which is it? If Lisp is so self-evidently better than every other
language, and if nobody has any fears or concerns with Lisp, why is Lisp a
fringe language? Not as fringe as it was ten years ago, and maybe growing
in popularity, and it is beyond all doubt that Lisp has a lot of influence
amongst language designers, but outside of a few niche areas, its still a
fringe language.

I'd like to know the answer. But the problem most people cite is the
parentheses, not the fear that someone will abuse macros. I have
certainly never seen anyone as worried about macros as you seem to be.

>>My point isn't whether or not their claims are correct (a "couple" of
>>macros? really?) but that things like this feed the perception that Lisp
>>is close to that hypothetical language where anything could be anything.
>>If anything could be anything, do you really know what (+ 1 2) means
>>without reading every line of code?

>>
>Jesus H Christ. Didn't you just get through talking about how easily
>someone can redefine built-ins in Python?

>
Yes. But you can't redefine 1+2 in Python, at least not without hacking
the interpreter. Can you redefine (+ 1 2) in Lisp?

Yes. Can't you redefine standard functions in Python?

Frank Buss correctly points out that you can shadow the + symbol and
make it whatever you'd like it to be. This is true, but now someone
has to intentionally and specifically import the package containing
that shadowed + into their own package. You are never unwittingly
using a different + than the standard CL one, although you really seem
to want this to be the case.

>>(This is an interesting demonstration that any language that allows file
>>I/O and importing of external program files can always treat functions
>>as data, even if the language doesn't directly support it. An alternative
>>would be to keep the strings in memory instead of writing to a module,
>>then use exec on them instead of importing the module.)

>>
>No, it treats code as text. See the difference?

>
Text is data.
>
What is the point of your comment? You don't have to argue about every
thing I say, even the ones we agree on. Look again at what I wrote. Is
there anything that gave you the impression that I think that having the
ability to write text to a file and import it is better than actually
supporting functional programming directly?

Well, text is not code. Text is a syntaxful representation of the
actual code, which is an AST. If I have a string full of text, I
can't do very much meaningful work with it. On the other hand, if I
have an AST, I can transform it or analyze it however I choose.

>Could you calm down?

>
Okay, once was funny. Twice is worrying. What exactly is giving you the
idea I need to calm down? Was it the use of reasoning and logic?
Perhaps it was the attempt to be reasonable and moderate and find some
middle ground that we could agree on, or if not agree, at least say "Well,
I disagree with you, but at least I understand where you are coming from"?

Where I'm coming from? Dude, you're writing paragraph upon paragraph
about the same thing, multiple times per day. You're terrified of
worst-case scenarios that everyone else is telling you are not
realistic.

[Bryan]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

>
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, you bring back awful memories :( in my college days, we had already
learned fortran, pascal, c, snobol, prolog and some assembly. then we took
a lisp class. what a complete nightmare!!! except for that one brainiac
kid who was on "another planet", the rest of the class (about 30 people)
could not grasp lisp at all. the teacher was always pissed off. he kept
telling us it was such an easy language and it's so powerful and kept
saying our lisp code looked like pascal. so, for the final he
intentionally gave us problems that if you don't think in a lisp way you
couldn't solve the problem within the time given. of course everyone
failed or got a D. my point is i know at least 30 people that could code
in other languages just fine, but not lisp. i've tried to learn it on my
own several times since then, but it's just too difficult for me. my brain
just doesn't work that way i guess. with python, my brain doesn't hurt. i
can program in a very relaxed way and it seems that whatever i'm thinking,
i can just write it naturally in python. for me personally that's how i
define "expressiveness " eventhough others here would disagree on
what "expressiveness " means.


bryan

[Pascal Bourguignon]

Re: merits of Lisp vs Python

Bill Atkins <atkinw@rpi.edu writes:

>Yes. But you can't redefine 1+2 in Python, at least not without hacking
>the interpreter. Can you redefine (+ 1 2) in Lisp?

>
Yes. Can't you redefine standard functions in Python?
>
Frank Buss correctly points out that you can shadow the + symbol and
make it whatever you'd like it to be.

Well, there is no "THE + symbol", there are a lot of different symbols
named "+". The one you get when you read the characters of "(+ 1 2)"
depends on the dynamic binding of the COMMON-LISP:*PACKAGE* symbol.

This is true, but now someone
has to intentionally and specifically import the package containing
that shadowed + into their own package. You are never unwittingly
using a different + than the standard CL one, although you really seem
to want this to be the case.

The Common Lisp standard has no provision to and indeed forbid to
modify the function binding of the COMMON-LISP:+ symbol.

On the other hand, implementations may allow, sometimes with the help
of an implementation specific WITHOUT-PACKAGE-LOCK operator, to change
the function binding of the COMMON-LISP:+ symbol.

So, while the standard preserves itself, and wants you to explicitely
say you're using a symbol named "+" from a different package than
COMMON-LISP, rather than modifying CL:+, the implementations may still
allow you to actually modify the COMMON-LISP package, but of course,
this may not be Common Lisp anymore, if you don't follow the
specifications of Common Lisp (and if you do, why are you trying to
modify CL:+ that already implements Common Lisp!?).


--
__Pascal Bourguignon__ http://www.informatimago.com/

This universe shipped by weight, not volume. Some expansion may have
occurred during shipment.

[Bill Atkins]

Re: merits of Lisp vs Python

Pascal Bourguignon <pjb@informatim ago.comwrites:

>This is true, but now someone
>has to intentionally and specifically import the package containing
>that shadowed + into their own package. You are never unwittingly
>using a different + than the standard CL one, although you really seem
>to want this to be the case.

>
The Common Lisp standard has no provision to and indeed forbid to
modify the function binding of the COMMON-LISP:+ symbol.

I'm not talking about redefining the + symbol; I'm talking about
shadowing it and defining a new function on a different symbol that
has the same symbol-name.

[hit_the_lights]

Re: merits of Lisp vs Python

Paul Boddie schrieb:

Given that the meaning of import doesn't need to have changed to bring
out the described consequences, I guess anyone wanting to know more
won't be asking you specifically.

I should have added some lines:

==== python =============== =====

>>import a
>>import b

You sucker thought I'd import b for you.
Instead I'm going to erase your hard drive.

>>a

<module 'a' from 'a.pyc'>

>>b
>>>

=============== ===============

I was suprised that b was defined at all.

[tayssir.john@googlemail.com]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

I'd love to say it has been fun, but it has been more frustrating than
enjoyable. I don't mind an honest disagreement between people who
genuinely are trying to see the other's point of view, but I don't think
that was the case here. What was especially frustrating was that the more
I tried to understand certain Lispers' positions by asking questions, the
more nasty and insulting they became. So now I have an even better
understanding for why Lispers have a reputation for being difficult and
arrogant.

This is only because they openly disagree with your beliefs. Note that
you appear the same way to your Lisp-using flamewarrior counterparts.

We might look in the mirror:
<http://www.escapefromc ubiclenation.co m/get_a_life_blog/2006/04/how_the_technog .html>

Maybe Lisp users are singled out as particularly arrogant because they
claim that the last 20 or so years of the software profession have been
something of a fraud.


Tayssir

[jayessay]

Re: merits of Lisp vs Python

Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:

jayessay <nospam@foo.com writes:

http://caml.inria.fr

http://www.haskell.org

Aren't these "old-fashioned" and boring as well?

>
Maybe not bleeding edge, but more modern than CL in my opinion.

Odd, caml is even older than CL.


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Paul Boddie]

Re: merits of Lisp vs Python

hit_the_lights wrote:

>
I should have added some lines:
>
==== python =============== =====

>import a
>import b

You sucker thought I'd import b for you.
Instead I'm going to erase your hard drive.

>a

<module 'a' from 'a.pyc'>

>b
>>

=============== ===============
>
I was suprised that b was defined at all.

Well, I've done all sorts of things with Python's import machinery, and
I'd prefer not to stare too long at its implementation, but both import
statements by their very nature in Python are still import statements.
Of course you can always argue that some undesirable effect of
redefining the keyword via a macro is also achievable by misusing the
import machinery, that both things are therefore just as dangerous, and
that macros are inherently no more dangerous than exposed library
mechanisms employed by the virtual machine. I'd agree generally with
that reasoning, and you can see in various features of Python that lots
of covert side-effects can be introduced which would prove surprising
to the casual developer when he or she uses some seemingly harmless
construct. (Interestingly, some of the newer features in Python could
have been introduced using macros, and perhaps EasyExtend already
demonstrates this.)

Ultimately, I think that the main point of contention is little to do
with macros or their absence from Python. Instead, it's more about
people coming to an agreement about form and behaviour guarantees for
Python programs - in other words, what you can expect when you open a
Python source file and start reading the code. It should be noted that
attitudes are generally negative towards careless redefinition of
fundamental or common concepts or mechanisms of the language, just as I
imagine it would be with Lisp, and one only needs to consider reactions
to various Ruby-related advocacy to see where the many in the Python
community supposedly draw the line at things like pervasive
monkey-patching of built-in classes. To bring that maligned natural
language analogy back into repute, I'd argue that Python and its
apparent restrictions act a lot like the specialised vocabularies and
familiar structures employed when presenting material in various
scientific disciplines: one could argue, upon reading a paper, that it
would have been a lot easier for the author to have structured the
paper differently and to have defined a one-off vocabulary, but issues
of convenient communication are highly likely to override such
considerations, especially in disciplines where conventions in
communication are already very strictly defined.

Paul

[André Thieme]

Re: merits of Lisp vs Python

Steven D'Aprano schrieb:

On Sun, 10 Dec 2006 01:53:50 +0100, André Thieme wrote:
>

>You could maybe give another example: how would one realize something
>like (memoize function) in Python?

>
By spending thirty seconds googling:
>

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/325205

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498110

>
If your needs are very simple, something as simple as this will do it:
>
def memoize(func):
def f(arg, _cache={}):
if _cache.has_key( arg):
return _cache[arg]
t = func(arg)
_cache[arg] = t
return t
return f
>

Yes, you are right, again this can be done with functional programming.
My examples also were not better than those of Kenny.
But anyway, in Lisp you can save some code. Not much in this situation.
Instead of function = memoize(functio n)
one could just say: memoize(functio n).

>Or (defmethod name :after ..)?

>
I don't even know what that means. Would you like to translate?

Also this won't be very hard to do in Python.
It just means: if you have a method with the name "name" and call it,
then this after-method will be called right after and do some side effect.

In Lisp it is built in. But with some effort it could be done in Python
too. The idea is, that small savings sum up, so macros do make sense.


André
--

[rurpy@yahoo.com]

Re: merits of Lisp vs Python


tayssir.john@go oglemail.com wrote:

Steven D'Aprano wrote:

I'd love to say it has been fun, but it has been more frustrating than
enjoyable. I don't mind an honest disagreement between people who
genuinely are trying to see the other's point of view, but I don't think
that was the case here. What was especially frustrating was that the more
I tried to understand certain Lispers' positions by asking questions, the
more nasty and insulting they became. So now I have an even better
understanding for why Lispers have a reputation for being difficult and
arrogant.

>
This is only because they openly disagree with your beliefs. Note that
you appear the same way to your Lisp-using flamewarrior counterparts.
>
We might look in the mirror:
<http://www.escapefromc ubiclenation.co m/get_a_life_blog/2006/04/how_the_technog .html>
>
Maybe Lisp users are singled out as particularly arrogant because they
claim that the last 20 or so years of the software profession have been
something of a fraud.

Well, having read a lot of this thread, I can see one of the
reasons why the software profession might want to avoid
lispies. With advocacy like this, who needs detractors?

[tayssir.john@googlemail.com]

Re: merits of Lisp vs Python

Paul Boddie wrote:

To bring that maligned natural
language analogy back into repute, I'd argue that Python and its
apparent restrictions act a lot like the specialised vocabularies and
familiar structures employed when presenting material in various
scientific disciplines: one could argue, upon reading a paper, that it
would have been a lot easier for the author to have structured the
paper differently and to have defined a one-off vocabulary, but issues
of convenient communication are highly likely to override such
considerations, especially in disciplines where conventions in
communication are already very strictly defined.

Keeping with the analogy, Lisp offers power to adapt your notation to
the domain you're describing. One thing people expect from a language
is a certain malleability in order for it to somehow resemble the
domain they're describing.

So for example, Lisp may not offer infix syntax by default, but there
exist infix libraries you can download. (Haven't used it myself
though.)

http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html

In this sense, you can see that Lisp's syntax is rather general and can
be molded. Within the constraints of typical text sourcecode.


Tayssir