merits of Lisp vs Python

[Rob Warnock]

Re: merits of Lisp vs Python

John Thingstad <john.thingstad @chello.nowrote :
+---------------
| (If you want symbols to be case sensitive and default case to be lower
| then most Lisp's allow that, but the ANSI spec dosn't give a standard way.)
+---------------

What about (setf (readtable-case *readtable*) :invert)? That's in ANSI.


-Rob

-----
Rob Warnock <rpw3@rpw3.or g>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sun, 10 Dec 2006 03:37:26 +0000, Kirk Sluder wrote:

>But at least you know that foolib is a module or package. You know what
>from and import do, and that can't change. And you know that bar is an
>object with a method also called bar, it is being called, and the
>argument is a string "somefile". Those things can't change. Imagine a
>hypothetical language where those two lines could mean *anything*.

>
But as was pointed out earlier in the thread, those keywords can be
overshadowed by custom functions in python as well.

Really?

>>def import():

File "<stdin>", line 1
def import():
^
SyntaxError: invalid syntax


Nope, can't shadow or change keywords. (And yes, the error message could
be better.)

The only reason
that we don't assume those two python lines could mean *anything* is
because those mechanisms are not well advertised, and most people
don't have a need to shadow "import."

Or because they can't mean just anything.

Of course, it is possible to abstract away all of the lisp in such a
way that you have a completely new programming language. But is this
really a problem? Perl5 and bash are abstractions of C. Python has
been implemented on both C and java, and chunks of perl6 have been
implemented on top of Haskell.

That depends. If somebody smart is designing a new programming language,
then no, you get a new programming language.

If somebody not-so-smart is merely hammering the round peg of Lisp into
the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
that will be a problem. But apparently, despite the talk of using macros
to implement anything in Lisp, nobody actually does that.

>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?

>
How do you know that operator has not been shadowed or overloaded in
python?

Because the tokens 1 and 2 cannot be anything but ints, and + with two
int args cannot be anything but addition.

>Or maybe it is only an advantage while Lisp programmers are a
>self-selected group of above-average skill. Wait until fifty million VB
>code monkeys start writing Lisp macros and maybe, just maybe, you'll wish
>they were using a less powerful and more restrictive language.

>
Perhaps it's because I'm a social scientist and not a programmer by
training, but I find many arguments for *technical* solutions to
*human performance* problems to be rather weak as a general
practice. In some cases, using a very restrictive language may be
the best solution for the problem.

I don't know about you, but I'm not talking about VERY restrictive
languages -- I'm using Python, which isn't very restrictive at all. But
even Lisp has some restrictions -- you can't jump to an arbitrary memory
location and treat whatever random bytes are there as executable code, can
you?


--
Steven.

[Ken Tilton]

Re: merits of Lisp vs Python



Steven D'Aprano wrote:

On Sat, 09 Dec 2006 22:06:29 -0500, Ken Tilton wrote:
>
>

>>As I type each right parens I eyeball
>>its partner as the editor highlights it to make sure I have not missed
>>anything,

>
>
Er, weren't you one of the people claiming that you don't notice parens
when you're reading or writing Lisp code?

Steve, you seem to be doing everything you can to make what is basically
a decent cultural exchange unpleasant, mostly by bellowing like some mad
rogue elephant over and over again about macros, now by trying to play
gotcha.

I said they disappear. They do. I do not see parens when I look at code.
The "watching of the matching" is only after furious thrashing during
refactoring, and even then it is unconscious most of the time because we
are usually also indenting as we go.

I presume you look to see if your indentation is correct while you are
indenting, with no more effort than I eyeball the highlighted parens.

You think that some gotcha is somehow going to miraculously reveal that
I do in fact have trouble with parentheses? Now /that/ would be dumb of you.

>So, if you're still seeing parentheses, does that mean you've been coding

Lisp for less than a month?

I see you figured it our for yourself. Obviously I love parentheses and
would hate to program without them, so obviously your gotcha falls short.

I myself am simply delighted. I decided I should indeed check out if I
was up against the c.l.p village idiot. Nope, turns out you are the
Master of FUD:

http://www.itwire.com.au/content/view/7359/53/

"According to Steven D'Aprano, operations manager of longstanding open
source services firm Cybersource, Microsoft's new game of attempting to
strike fear into the heart of Linux users by invoking the spectre of
patent infringements may soon take an ominous new twist. Mr D'Aprano
believes that Microsoft may well use similar tactics employed by its
proxy the BSA six years ago when it raided the offices of guitar string
maker Ernie Ball with armed marshalls and found a few machines with
non-compliant software."

I love it, you turning FUD on the FUDster, MS. Good for you! A whole
article with nothing but your unsubstantiated guesses as to Microsoft
suing someone! I do not who impresses me more, you giving such an
interview or the reporter who printed it... no, you guys are allowed to
screw up, the editor should be shot.

Hey, Steve, save that crap for Microsoft, will you?

peace. 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

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:

>I know that. It was more of a rhetorical question -- Lispers are either
>trying to emphasis the radical nature of what you can do with macros, or
>understate it and make them seem just like functions.

>
Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
to PyCells as part of SoC 2006) is another. The latter is the norm.

If macros' advanced usage is rare, and most usage of macros could be done
by functions, then maybe that explains why so many coders don't miss them.


--
Steven.

[Paul Rubin]

Re: merits of Lisp vs Python

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

Or (defmethod name :after ..)?

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

This is something that I've wished Python had. If I try to describe
it I'll probably get it wrong. But basically say Foo is a class with
multiple superclasses. The superclasses each define a "name" method
and Foo itself may also define a "name" method. When you call
Foo.name() you want that to invoke both Foo's name method and the
superclass methods. In Python you have to do grotty things like
super(Bar,self) .name() in the Foo.name() to make this happen by hand,
and you have to keep tweaking that as you add and remove superclasses.
In Lisp, you can set it up so that the multiple "name" calls happen
automatically. The :before, :after, and :around keywords let you say
what order you want the calls to happen in. You'd use :before for
setup actions, :after for cleanup actions, and just plain defmethod
for the stuff that is supposed to happen in between.

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sun, 10 Dec 2006 04:03:25 +0000, Kirk Sluder wrote:

In article
<pan.2006.12.10 .02.57.36.86286 @REMOVE.THIS.cy bersource.com.a u>,
Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrote:
>

>So it is good that English restricts the expressiveness and power of the
>syntax and grammar. While we're talking English, we can both understand
>each other, and in fact people who redefine words and ignore the common
>meaning of them are often covering weaknesses in their arguments.

>
Ohh, can the guy who does discourse analysis for a (meager) living
respond to this?
>
To start with, English does not restrict the expressiveness and
power of the syntax and grammar.

Really? There are no restrictions whatsoever in English syntax and
grammar? None at all?

So, when I say "sits cat rat" it is not only legal English, but you can
tell which animal is sitting on which?

And if I write "i helped my uncle jack off a horse" with no punctuation or
capitalisation, you can tell which of the two meanings I mean?

Although it isn't strictly syntax or grammar, you also understand
precisely what I mean when I say "the gostak distims the doshes" --
because, as you say, English has no restrictions.

And if I write "You are an idiot", you'll understand that in *my* version
of English "You" means watermelon, "are" means to grow, "an" means best,
and "idiot" means in the summertime, and naturally you won't be offended.

But I'm belaboring the point. Of course English has restrictions in
grammar and syntax -- otherwise one could write something in Latin or
Thai or Mongolian and call it English. There are RULES of grammar and
syntax in English, which means that there are possible expressions which
break those rules -- hence there are expressions which one can't write in
legal English.

That doesn't mean that there are concepts which one can't express in legal
English (although there may be). But we can communicate in English because
when I write "Fred hit Barney with a stick" we both agree that it was Fred
who did the hitting, not Barney or the stick, and Barney was the victim.
If English had no grammatical restrictions, we couldn't agree who hit whom
with what.



--
Steven.

[Kirk Sluder]

Re: merits of Lisp vs Python

In some cases lisp macros are a way of saying tomato to something
that would be called "tomahto" in python.

One common use of macros is custom iteration constructs. In my
social network analysis I wanted to do something to each and every
sender-recipient pair in the header line of "mail" messages in my
dataset. (And yes, I did have permission to use this data.) Each
message had one sender, but possibly multiple recipients. Since I
would be doing multiple forms of analysis, I might as well create
one iterator to do this.

The DO-MAIL-RELATIONS macro takes the mail message (line), parses
the sender field and assigns it to (sender), splits the recipient
field and assigns it to (recip) and then performs the logic in the
body which often involved looking up values in a database, and
setting values in a matrix.

(kirk.matrix-process:do-mail-relations (message sender recip)
;;about 12 lines of logic snipped
)

To be pedantic about this call. "KIRK.MATRI X-PROCESS" identifies the
package/namespace for the macro call. "DO-MAIL-RELATIONS" names the
macro as part of the DO family of iteration constructs which are
basic to lisp.

Now that I think about this, in python I'd probably do this using
object logic that returned the recipient list as an iteratable
object:

for sender, recipient in message.relatio nPairs:
#about 12 lines of logic

Would it have been possible to implement DO-MAIL-RELATIONS as a
function? Possibly, but I found trying to compact all of that logic
into a single-use function that could be safely passed to another
function to be more trouble.

Another common macro use is the "WITH-STREAM" family which opens a
stream for IO and closes it at the end.
(with-open-file (file-handle "filename" :direction :output)
(format file-handle "Hello world.~%")
)

The pythonic way to do this would be to create a class that
implements file-like behaviors:

output = fileLike.open()
output.write("H ello world\n")
output.close()

You might want to use a custom "WITH-STREAM" macro or file-like
object if you need to format, filter, or compress the outgoing
stream in any way.

[Wolfram Fenske]

Re: merits of Lisp vs Python

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

On Sat, 09 Dec 2006 14:00:10 +0000, Timofei Shatrov wrote:
>

>On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
><steve@REMOVE. THIS.cybersourc e.com.autried to confuse everyone with this
>message:
>>

>>>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>>>
>>>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.
>>>
>>>Dude. Turing Complete. Don't you Lisp developers know anything about
>>>computer science?

>>
>Here, you've basically shot yourself in the ass. Appealing to
>Turing completeness when talking about programming language
>features is about the dumbest thing you can make. In Turing sense,
>a program is simply a function that takes an argument and returns a
>value. It doesn't say anything about how this function was
>implemented. It could be Turing machine, lambda calculus, Markov
>chains or whatever else. All these methods produce the same set of
>programs, but that doesn't mean you could implement lambda in
>Turing machine for example.

[...]

If you're talking about practicality, then of course you're correct,
not all languages are equally expressive. Some languages are not
expressive enough.

I agree.

Some languages are too expressive.

I disagree. "Too expressive"--what a thing to say.

[...]

Look, all snarkiness aside, it just isn't true that "stuff like this
is impossible in other languages". If Wolfram Fenske had said "stuff
like this isn't easy in many other languages" he would have been
right.

I said that it's impossible to write you own object system in other
languages *and* have it behave like it was part of the language. OK,
you could always write your own pre-processor, i. e., your own
Foo+Objects to Foo compiler. But that's almost like saying it's
impossible. Now, object systems aside, how about that one: One of the
new features of Python 2.5 is a syntax for

--8<---------------cut here---------------start------------->8---
if condition:
x = true_value
else:
x = false_value
--8<---------------cut here---------------end--------------->8---

which becomes

--8<---------------cut here---------------start------------->8---
x = true_value if condition else false_value
--8<---------------cut here---------------end--------------->8---

(see [1]). IMO that's a nice addition because this pattern is
something that has bothered me for some time.

Here's another one, the "with" statement [2]:

--8<---------------cut here---------------start------------->8---
Some standard Python objects now support the context management
protocol and can be used with the 'with' statement. File objects are
one example:

with open('/etc/passwd', 'r') as f:
for line in f:
print line
... more processing code ...

After this statement has executed, the file object in f will have been
automatically closed, even if the 'for' loop raised an exception
part-way through the block.
--8<---------------cut here---------------end--------------->8---

My point is that in Python--and AFAIK any other language except maybe
OCaml and maybe maybe Haskell--, you have to wait for these changes
until the language designers decide to make the for you. And if they
don't, you're out of luck. In Lisp, you can just add this yourself.

And if he had said "and stuff like this carries risks as well as
benefits" he would have come across as less of a language fanatic.

Sure, you can shoot yourself in the foot with macros. But you can do
that in any language of any degree of expressiveness [3]. Come to
think of it, the whole reason why we use high level languages is
because of their expressiveness: We get stuff done faster and
introduce less errors. So "the more expressive, the better," right?
But according to you, there's a point when a language gets "too
expressive". I don't see why.

One of the risks with Python is the ease with which you can modify the
built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
list from 2, 3, and 4, because the built-in list could be redefined.
(In practice, that's not often a real problem, because experienced
Python developers simply learn not to needlessly or confusingly shadow
built-ins. It's not the best system, but it works well enough in
practice.)

So you do trust your developers not to do anything stupid.

But at least the basic syntax and keywords of the language are known
to be constant. With Lisp macros, even that isn't guaranteed.

Let me summarize: you're allowed to redefine every built-in function
you want but introducing new syntax is simply too much. See, this is
the kind of thinking I don't understand. I say macros are good
because a), b), and c) and you answer macros are bad because, uhm,
well, it would be pure anarchy.

Now, if Lispers would say "Oh yes, macros give you great power, and
with great power comes great responsibility. Be careful." then, no
doubt, we'd take you guys more seriously.

Sure, it's a powerful tool but it's not *that* hard to use. Maybe
you're afraid of it because that it's something that's unique to Lisp?
But IMO the reason for that is not that they're too powerful. IMO it
has mostly to do with the fact that other languages' syntaxes make it
too difficult to implement Lisp-style macros.

But we don't hear that -- we hear Lispers going on and on about how
great it is that they can easily redefine every corner of the
language. Do you blame people for *believing them* and imagining
that reading Lisp code is like following some ghostly
will-o-the-wisp across a swamp, where nothing is what it seems and
the landscape is forever shifting?

Come on! You're telling me people don't learn Lisp because they are
afraid of it? Python allows you to redefine built-in functions, as
you said, Ruby allows you to attach new methods to live objects, but
Lisp is simply going too far?

Now, if you want to tell me that, despite all the talk, Lisp coders
don't actually create new syntax or mini-languages all that often,
that they just use macros as functions, then the question becomes:
why do you need macros then if you are just using them as functions?
Why not use functions?

Easy because macros are not functions. Functions allow you abstract
functionality, macros allow you abstract syntax. Look at the examples
above. How would you implement conditional expressions as a function?
Answer: You can't, it's syntax.


Footnotes:
[1] <http://docs.python.org/whatsnew/pep-308.html>

[2] <http://docs.python.org/whatsnew/pep-343.html>

[3] And here's the proof
<http://www.reed.edu/~tuckers/jokes/foot.html:-)

--
Wolfram Fenske

A: Yes.

>Q: Are you sure?

>>A: Because it reverses the logical flow of conversation.

>>>Q: Why is top posting frowned upon?

[Paul Rubin]

Re: merits of Lisp vs Python

Kirk Sluder <kirk@nospam.jo bsluder.netwrit es:

Another common macro use is the "WITH-STREAM" family which opens a
stream for IO and closes it at the end.
(with-open-file (file-handle "filename" :direction :output)
(format file-handle "Hello world.~%")
)
>
The pythonic way to do this would be to create a class that
implements file-like behaviors:
>
output = fileLike.open()
output.write("H ello world\n")
output.close()

Actually the Python example can lose (e.g. leak a file descriptor
temporarily) if output.write raises an exception (prevents
output.close from running). For this reason Python recently
introduced the "with" statement:

with output as fileLike.open() :
output.write("H ello world\n")

Here the file gets closed automatically (by running an exit method in
the fileLike class) when the "with" block exits, whether normally or
through an exception.

[George Sakkis]

Re: merits of Lisp vs Python

JShrager@gmail. com wrote:

1. Lisp is the only industrial strength language

^^^^^^^^^^^^^^^ ^^^^
You keep using that phrase. I don't think it means what you think it
means.

with pure compositionalit y, and that this makes it suprior to Python.

Perhaps it does in some programming language theory research groups. In
the real world, superiority has to do with far more than technical
merits alone, let alone obscure metaprogramming features which are
irrelevant to the vast majority of programmers.

2. Ruby, which is closer to Lisp than Python, is beginning to eat
Python's lunch. We don't have to debate this either because George has
kindly gave support to it through posting a survey that made this point
quite nicely; Thanks, George! :-)

AKA "if you can't beat them, join them". I don't know if other lispers
would join you in your feeble attempt to steal a bite from Ruby's
current glory (mostly thanks to the admirable marketing around the
overhyped Rails framework), but Ruby is much closer to Python than
either of them is to lisp. In fact, if Python suddenly disappeared,
Ruby would probably be my next stop. Both Ruby and Python are high
level dynamic languages with an emphasis on pragmatic needs, not being
the language of the God(s) (see, I can bring up stupid slogans of
languages too). The similarities between Python and Ruby outweigh their
differences, resulting in very few defections from one to the other, so
nobody's eating the other's lunch. They are both appealing alternatives
to different (overlapping) subsets of the Java/C++/Perl/PHP crowd, and
the choice between the two usually comes down to a subjective
preference about the syntax, the availability of libraries or other
non-technical reasons.

BTW, for the record, I don't have anything particularly against Python
aside from its stupid marketing hype and a bit of jealousy over those

Talk about a well-founded reason to diss a language.

George

[Kirk Sluder]

Re: merits of Lisp vs Python

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

On Sun, 10 Dec 2006 04:03:25 +0000, Kirk Sluder wrote:
>

In article
<pan.2006.12.10 .02.57.36.86286 @REMOVE.THIS.cy bersource.com.a u>,
Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrote:

So it is good that English restricts the expressiveness and power of the
syntax and grammar. While we're talking English, we can both understand
each other, and in fact people who redefine words and ignore the common
meaning of them are often covering weaknesses in their arguments.

Ohh, can the guy who does discourse analysis for a (meager) living
respond to this?

To start with, English does not restrict the expressiveness and
power of the syntax and grammar.

>
Really? There are no restrictions whatsoever in English syntax and
grammar? None at all?

Of course I didn't say that: What I said was, "To start with,
English does not restrict the expressiveness and
power of the syntax and grammar. People who use the English language
in specific communities and in specific forms of discourse do. The
key to how this happens occurs on another layer of how language
works which is almost always left out of internet discussions of
language: pragmatics."

As an example of the context-specific nature of pragmatics at work,
if I was your reviewer or editor, I'd reject this manuscript. As a
participant on usenet, I'll just point out that you selectively
quoted the antithesis, and deleted my thesis to argue a straw-man.

Of course there are restrictions, *enforced by users of language in
specific communities.* But the English language is quite malleable,
and includes not only the discourse we are currently engaged in, but
the clipped jargon of internet chat and amateur radio, the
chronically passive discourse of academia, the passionate chants of
protesters, and a wide variety of poetic expression.

This is where wannabe critics of "English grammar" fail to
understand the language they claim to defend, much to the amusement
of those of us who actually do study language as it is, rather than
the mythical eternal logos we want it to be.

Languages are (with some trivial exceptions) human creations. The
laws, rules and restrictions of languages are dynamic and dependent
on community, mode, medium and context. Of course, wannabe
grammarians frequently rise up at this point and say that if such is
the case, then there is nothing to prevent <language of choicefrom
devolving into a babble of incomprehensibl e dialects. To which the
easy response is that the benefits of conformity to linguistic
communities almost always outweigh the costs of nonconformist
expression.

And if you want to bring this back around to computer languages, the
benefits of conformity to said linguistic communities tends to
outweigh the costs of doing your own thing. (Unless you can make a
convincing argument that "doing your own thing" is superior.)

So, when I say "sits cat rat" it is not only legal English, but you can
tell which animal is sitting on which?

What is "legal" in English depends on the communities in which you
are currently participating. Likely there is some community in which
such clipped discourse is understood and therefore legal. If you are
talking to me, I'd express my lack of comprehension by saying
"Pardon?" and ask you to rephrase.

But I'm belaboring the point. Of course English has restrictions in
grammar and syntax -- otherwise one could write something in Latin or
Thai or Mongolian and call it English. There are RULES of grammar and
syntax in English, which means that there are possible expressions which
break those rules -- hence there are expressions which one can't write in
legal English.

When you make an "illegal" statement in English, exactly who or what
corrects you?

Is it Zeus, the divine Logos, the flying spaghetti monster, some
platonic ideal?

As you can probably tell, this kind of silliness is a bit of a sore
spot for me. So please by all means, do some basic reading of
linguistics before you continue to engage in such silliness. Or at
least learn to properly quote an argument.

[Wolfram Fenske]

Re: merits of Lisp vs Python

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

"Wolfram Fenske" <int2k@gmx.netw rites:

>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.

Alex Mizrahi already took care of that one.

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 straightforward ly be done in CL?

No. My point was more that Lisp is so flexible that it even allows
you to add something as huge as object orientation without requiring a
change to the compiler. What about Aspect-Oriented Programming, for
example? For Java, you need a new compiler/preprocessor, for Lisp, it
can be implemented as a library [1].

Hint: call-with-current-continuation (also known as call/cc).

You're right call/cc is a problem because you basically can't
implement call/cc without having call/cc. I. e. it requires pervasive
changes to the compiler/interpreter if something like it is not
already in there. Still, Scheme--also a Lisp--has call/cc and was
probably the first language to implement it.

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.

Scheme is also a Lisp. So?

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.

Anything in particular? I'd be surprised if the solutions in Scheme
and CL would differ very much because apart from the Lisp-1/Lisp-2
issue and call/cc, Scheme and CL are not that different.


Footnotes:
[1] <http://common-lisp.net/project/closer/aspectl.html>

--
Wolfram Fenske

A: Yes.

>Q: Are you sure?

>>A: Because it reverses the logical flow of conversation.

>>>Q: Why is top posting frowned upon?

[Kirk Sluder]

Re: merits of Lisp vs Python

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

That depends. If somebody smart is designing a new programming language,
then no, you get a new programming language.
>
If somebody not-so-smart is merely hammering the round peg of Lisp into
the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
that will be a problem. But apparently, despite the talk of using macros
to implement anything in Lisp, nobody actually does that.

Then what exactly is your argument here?

And BTW:
CL-USER(defun + (a b))
Lock on package COMMON-LISP violated when setting fdefinition of +.
[Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]

While lisp doesn't prohibit such name conflicts, it does mean that
anyone trying it will generate a fair number of errors each time the
definition is compiled.

Perhaps it's because I'm a social scientist and not a programmer by
training, but I find many arguments for *technical* solutions to
*human performance* problems to be rather weak as a general
practice. In some cases, using a very restrictive language may be
the best solution for the problem.

>
I don't know about you, but I'm not talking about VERY restrictive
languages -- I'm using Python, which isn't very restrictive at all. But
even Lisp has some restrictions -- you can't jump to an arbitrary memory
location and treat whatever random bytes are there as executable code, can
you?

Certainly, and I've even pointed out a few that would mediate
against your claim of incompetent programmers being able to
arbitrarily shadow core functions in a way that is invisible to
anyone else.

[Kirk Sluder]

Re: merits of Lisp vs Python

In article <7xfybo1dlj.fsf @ruckus.brouhah a.com>,
Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrote:

Kirk Sluder <kirk@nospam.jo bsluder.netwrit es:

The pythonic way to do this would be to create a class that
implements file-like behaviors:

.....

>
Actually the Python example can lose (e.g. leak a file descriptor
temporarily) if output.write raises an exception (prevents
output.close from running). For this reason Python recently
introduced the "with" statement:
>
with output as fileLike.open() :
output.write("H ello world\n")
>
Here the file gets closed automatically (by running an exit method in
the fileLike class) when the "with" block exits, whether normally or
through an exception.

Ohhh, shiny!

[Ken Tilton]

Re: merits of Lisp vs Python



Steven D'Aprano wrote:

On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:
>
>

>>>I know that. It was more of a rhetorical question -- Lispers are either
>>>trying to emphasis the radical nature of what you can do with macros, or
>>>understate it and make them seem just like functions.

>>
>>Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
>>to PyCells as part of SoC 2006) is another. The latter is the norm.

>
>
If macros' advanced usage is rare,

Hunh? I have tons of them. Of coure at your level of discourse you will
want to know if those are metric tons or...

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