merits of Lisp vs Python

[Bill Atkins]

Re: merits of Lisp vs Python

Ken Tilton <kentilton@gmai l.comwrites:

Steven D'Aprano wrote:

>If that's the best example of what macros can be used for, frankly I'm
>unimpressed.

>
We're shocked.

We are.

(Counting lines? Come on.)

[Ken Tilton]

Re: merits of Lisp vs Python



Wolfram Fenske wrote:

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

....

>>Some languages are too expressive.

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

A sad moment in Usenet discourse... a moment of silence, please.

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

[Kaz Kylheku]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

Oh my god! Lisp can echo STRINGS to the interpreter?

Indeed yes, but that's not exactly what's happening here. (And it's not
necessarily an interpreter, by the way. Some Lisp implementations
compile every expression to machine code and branch to it. Corman Lisp,
for instance, doesn't even contain an interpreter).

My point is not to showcase anything about Lisp, but simply to point
out the irony that in the same paragraph in which you are going on
about Lisp being unreadable compared to human written languages, there
appear pieces of parseable Lisp syntax.

Why didn't somebody somebody tell me that!

The answer to that would be: because your being properly informed for
these kinds of debates is your responsibility, and it is assumed.

!!! That *completely* changes my mind about the language!

If you keep up the mind changing, you can maybe trade up to one that
works in perhaps fewer than twenty transactions. (Think: Kyle
MacDonald).

[Bill Atkins]

Re: merits of Lisp vs Python

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

Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
that hypothetical anything-goes language than is healthy. Maybe that's a

Wrongly. And do they? To paraphrase Brian Griffin: "Are you sure it
was people? Are you sure it wasn't...nothin g?"

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?

Even something simple like file I/O can be abused. Example: I've seen

Agreed. This is why I've always argued that I/O should never have
been included in programming languages. Too dangerous. And, let's
face it, pretty old-fashioned these days.

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

Honest to god, the code really was like that!

Holy cow! How incredible!

Is that an argument against factory functions? Damn straight it is:
they are a powerful tool, and in the hands of morons, they can be
dangerous. Does that mean that languages shouldn't permit higher-order
functions? Not necessarily: all programming tools can be misused, but some
can be misused more easily than others. Power and risk is often a
trade-off, and language designers can't eliminate all risk of stupid
behaviour, but they can design the language to allow whatever level of
risk they believe is acceptable. (E.g. there is no doubt that C's raw
pointers are powerful, but many languages deliberately don't use them.)

Could you please calm down?

The risk of stupid factory functions is small compared to the benefit, but
maybe there is some domain somewhere where the ideal solution is a
language that DOESN'T treat functions as first class objects, deliberately
weakening the language so that a particular class of errors (or stupid
behaviour) just cannot happen. But that language isn't Python.

Could you calm down?

When it comes to Lisp's macros, the perception is that the power is

NB: here, "the" means "Steven D'Aprano's" (the number of meanings
"the" can assume in different contexts is quite surprising).

correspondingly greater, and the risk of abuse even more so. The safe

Don't you get tired of making the same arguments? Because I'm getting
tired of making the same counterpoints.

[Ken Tilton]

Re: merits of Lisp vs Python



George Sakkis wrote:

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.

To me in part it means "no one can decide to take away lambda because
they decided they should not have put it in in the first place and then
change their mind and leave it in after I already put a few people on
de-lambdifying our 100kloc system because...", and in part it means
compilation. And it /has/ to have macros. :)

Perhaps it does in some programming language theory research groups.

haha, the same old straw man, Is it not embarrassing to have to resort
to the same defeated argument again and again?

In
the real world, superiority has to do with far more than technical
merits alone, let alone obscure metaprogramming features ...

Metaprogramming by definition cannot be obscure. Metaprogramming means
programming at a higher level. A higher level means "more productive".
More productive is the essence of pragmatism. QED.

...which are
irrelevant to the vast majority of programmers.

You insult them by suggesting they cannot concieve at a higher level.
Mebbe they could if their language aupported it. Yours does not.

I don't know if other lispers
would join you in your feeble attempt to steal a bite from Ruby's
current glory...

Of course we would. You do not get it. The only thing you guys are
bleating about is greater popularity. Now someone is about to eat your
lunch popularity-wise. Live by the poll, die by the poll. And you held
first place for like a week in language geologic time, taken down merely
because...

(mostly thanks to the admirable marketing around the
overhyped Rails framework)

.... a little hype came along? Wow, your fundamental advantage must have
been about zip, and all derived from things unrelated to syntax. <gasp>

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

As Graham said, if some pretty good programmers are jumping up and down
about X, mebbe you should take a look at X. Even if assholes like me
piss you off. :)

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

[Jon Harrop]

Re: merits of Lisp vs Python

Ken Tilton wrote:

André Thieme wrote:

>def foo(function, args):
> setup(1)
> setup(2)
> function(args)
> cleanup(1)
> cleanup(2)
>>
>The nice thing in Lisp would now be to save a lambda with the macro.
>In Python one would fill the name space with throw away functions that
>get called only one time.

That is a deficiency of Python that doesn't exist in modern FPLs like OCaml,
SML, Haskell, F#...

Omigod. Is that what you meant? You think macros are unnecessary because
one could hard-code their expansions as separate functions? And that
would constitute hiding the boilerplate? What happens when the
boilerplate changes? <game over>

He is correct. When the boilerplate changes, you change your HOF.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists

http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet

[Jon Harrop]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

If that's the best example of what macros can be used for, frankly I'm
unimpressed. Yes, I can see some benefit. But I don't see that the benefit
is worth the added complexity. Maybe there are more complex tasks that
macros are better suited for.

You both seem to be trying to implement a pattern match. It would probably
be productive for you to compare Python and Lisp to languages that have
pattern matching.

For example, look at the symbolic simplifier here:

http://www.ffconsultancy.com/free/ocaml/symbolic.html

or the interpreter here:

http://www.ffconsultancy.com/free/ocaml/interpreter.html

Implementing this kind of stuff in Python is probably a nightmare. At least
you can address Lisp's deficiencies with macros...

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists

http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet

[Bryan]

Re: merits of Lisp vs Python

Harry George wrote:

It would probably be fair to say that the more you know
about a variety of languages, the more you appreciate Python.

+1 QOTW

[Jon Harrop]

Re: merits of Lisp vs Python

Ken Tilton wrote:

Steven D'Aprano wrote:

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

He has a point. Lispers always say that you can't see the superfluous
parentheses after a month of staring at them, yet you must match them. I do
prefer autoindenting though. Giving whitespace meaning seems like a
second-rate alternative to me...

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists

http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet

[Paul Rubin]

Re: merits of Lisp vs Python

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

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.

I'm not persuaded, I haven't examined his example carefully yet but it
looks like basically a reader hack. Lexical scope in Lisp means among
other things lexical closures and (maybe I'm mistaken) it seemed to me
Alex's example didn't supply that. I'm also unconvinced (so far) of
his description of call/cc as a Lisp macro but that's going to take me
some head scratching.

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?

No I don't buy that, you can't say Scheme is Lisp when it suits you to
do so and that it isn't Lisp at other times. I'd say you can map most
of Python's semantics onto Scheme reasonably straightforward ly, but
mapping them to CL is considerably harder, macros or no macros.

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

I took it back, I think you can do it in CL with closures (call/cc not
needed) similar to how it's done in SICP. You could do something
similar in Python but the natural way is with generators.

[Wolfram Fenske]

Re: merits of Lisp vs Python

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

On Sat, 09 Dec 2006 14:57:08 -0500, Bill Atkins wrote:
>

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

>>There is just not that much boilerplate in Python code, so there's
>>not so much need to hide it.

>>
>Well, of course there is. There are always going to be patterns in
>the code you write that could be collapsed. Language has nothing to
>do with it; Lisp without macros would still be susceptible to
>boilerplate.
>>
>Here's a concrete example:
>>
> (let ((control-code (read-next-control-code connection)))
> (ecase control-code
> (+break+
> (kill-connection connection)
> (throw :broken-by-client))
> (+status+
> (send-status-summary connection))
> ((+noop+ +keep-alive+))))
> ;; +X+ indicates a constant

>
Eight lines, excluding the comment, and it doesn't handle the case where
control-code is not one of +break+, +status+, +noop+ or +keep-alive+,
although the ecase macro does. And how many lines of code is ecase?

Doesn't matter because it only has to be written once. For Common
Lisp it's already part of the language. It would of course be bad to
write a macro if pattern comes up only a few times. But that's not
how macros are used.

>All of that boilerplate is handled by the macro. In Python, I
>would need to do something like:
>>
> control_code = connection.read _next_control_c ode()
> if control_code == +break+:
> connection.kill ()
> throw blah
> else if control_code == +status+:
> connection.send _status_summary ()
> else if control_code == +noop+ || control_code == +keep_alive+:
> else:
> error "CONTROL_CO DE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"

[...]

Saving one line of code, at the expense of having another block of code to
write or understand -- is that really the best example of what macros are
used for in practice? You don't really save writing any boilerplate code,
except for else clause, unless you're claiming that "if" and "elif" is
boilerplate.

No, all the "if control_code == SOME_STATUS:" are boilerplate:

--8<---------------cut here---------------start------------->8---
if control_code == STATUS1:
action_1
else if control_code == STATUS2:
action_2
...
else if control_code == STATUSN:
action_n
else:
Exception(...)
--8<---------------cut here---------------end--------------->8---

The pattern is that one value is compared against several possible
values and depending on which one matches, the appropriate action is
taken. Common Lisp's CASE and ECASE macros and the "switch"
statements of C or Java make this pattern explicit and arguably easier
to recognize. In Python you have to type it out yourself.

[...]

Okay, I'm impressed that ecase can pick up on the four constants being
tested against, and feed their names (rather than merely their values)
into an error message. Python has nothing like that, and if you only have
three or four things to test against, *and* they have names, that could be
a useful thing to do. And if I've understood correctly, that's more a
feature of Lisp's symbols than of macros.
>
But if you're testing against fifty different values, well, is it really
useful for your error message to list all fifty names? Or do you have
another macro ecase-with-lots-of-tests?

Now you're being silly.

[...]

If that's the best example of what macros can be used for, frankly I'm
unimpressed. Yes, I can see some benefit. But I don't see that the benefit
is worth the added complexity. Maybe there are more complex tasks that
macros are better suited for.

Here's another example. I had to use a database in one of my Python
programs. Everytime I used the database I had write something like
this:

--8<---------------cut here---------------start------------->8---
self.lock.acqui re()
try:
connection = sqlite.connect( self.dbFile)
connection.row_ factory = dictFactory
try:
# do something with the connection
finally:
connection.clos e()
finally:
self.lock.relea se()
--8<---------------cut here---------------end--------------->8---

In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
name of the connection variable and the code for "do something with
the connection" as arguments. Actually, I ended up writing something
like it as a function in Python:

--8<---------------cut here---------------start------------->8---
def withConnection( self, fun):
self.lock.acqui re()
try:
connection = sqlite.connect( self.dbFile)
connection.row_ factory = dictFactory
try:
return fun(connection)
finally:
connection.clos e()
finally:
self.lock.relea se()
--8<---------------cut here---------------end--------------->8---

What would have been the body in the Lisp macro has to be supplied as
function. It's basically a macro, but it still requires more typing
because you have to define a local function eveytime it is used.
Also, there are things you can do with Lisp macros where this
mechanism isn't applicable.

--
Wolfram Fenske

A: Yes.

>Q: Are you sure?

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

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

[Bill Atkins]

Re: merits of Lisp vs Python

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

>Scheme is also a Lisp. So?

>
No I don't buy that, you can't say Scheme is Lisp when it suits you to
do so and that it isn't Lisp at other times. I'd say you can map most

Quite right.

[Paul Rubin]

Re: merits of Lisp vs Python

Jon Harrop <jon@ffconsulta ncy.comwrites:

The nice thing in Lisp would now be to save a lambda with the macro.
In Python one would fill the name space with throw away functions that
get called only one time.

>
That is a deficiency of Python that doesn't exist in modern FPLs like OCaml,
SML, Haskell, F#...

Nothing stops you from re-using the same internal function name in
your Python code, like you might use "i" as a throwaway loop index in
several places in the same function. It's just like in Scheme, the
function is a first class object like an integer.

[Paul Rubin]

Re: merits of Lisp vs Python

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

In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
name of the connection variable and the code for "do something with
the connection" as arguments. Actually, I ended up writing something
like it as a function in Python:
>
--8<---------------cut here---------------start------------->8---
def withConnection( self, fun):
self.lock.acqui re() # ...

Do you know about Python's "with" statement? You'd define a class for
those db connections, that acquire the lock on entry, and release it
on exit.

[Jon Harrop]

Re: merits of Lisp vs Python

Wolfram Fenske wrote:

But seriously... 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 was under the impression that CLOS was non-trivial to write. There are
many other interesting features that haven't originated from Lisp (e.g.
pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that cannot
be implemented easily in Lisp because they are intrinsically complicated.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists

http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet