merits of Lisp vs Python

[Juan R.]

Re: merits of Lisp vs Python

greg ha escrito:

I don't know about the other Pythonistas in this
discussion, but personally I do have experience with
Lisp, and I understand what you're saying. I have
nothing against Lisp parentheses, I just don't agree
that the Lisp way is superior to the Python way in
all respects, based on my experience with both.

Parentheses have two advantages over identation. First is they can be
used both inline and block.

The inline (a b (c d (e f g))) needs to be formatted in several Python
lines. Therein SLiP (Python) got problems for inline mixed markup but
LML (LISP) or SXML (Scheme) do not.

Second is that i do not need special editors for writting/editting. It
is more difficult to do identation and editing by hand in 'Notepad'
that adding parens from keyboard[*].
[*] Tip. Type always () and next move your cursor inside ( _ ). You
never forget a closing ) this way!

[metawilm@gmail.com]

Re: CLPython (was Re: merits of Lisp vs Python)

Paul Rubin wrote:

metawilm@gmail. com writes:

a = 'hello'
a[0] = 'H' # attempt to change first letter to upper case

As CLPython mirrors Python semantics, this results in a TypeError. The
internal representation of an immutable Python string is a mutable Lisp
string, but there is no way you can actually modify it from within CLPython.

>
How do you manage that? The compiler can't check. Is there some kind
of special dispatch on the assignment statement instead of turning it
into a setf?

Indeed, the assignment of subitems is dynamically dispatched, and
always goes via __setitem__ methods, as specified in the language. The
__setitem__ methods for strings and tuples raise exceptions. The ones
for lists and vectors could be translated into a simple (setf (aref ..)
...) and (setf (nth ..) ..), unless the index is actually a slice and
actually a subsequence must be replaced.

Now, the above description using __setitem__ methods is how it
apparently works, as observed from the outside. Internally there is a
generic function (setf py-subs) that does the work itself, skipping the
lookup and calling of __setitem__, if the object is a vector or dict.
(The user can call x.__setitem__ explicitly, so that method must exist
internally.)

Maybe you were thinking that CLPython, given Python code, outputs a big
pile of self-contained equivalent Lisp code that can be run
independently, and then CLPython is finished. Instead, only a small
amount of Lisp code is generated, but that code can only be run when
the CLPython environment is loaded. The generated code refers to that
environment, e.g. s[0] = 'x' is translated into a call to (setf
(py-subs ..) ..), and function (setf py-subs) is part of the CLPython
environment that must be loaded at run-time.

If you compile a Python function, the result is a (mostly) normal Lisp
function - its origin from the Python world does not really matter.
Also, all Python data structures are first-class Lisp data. Thus
CLPython objects live happily together with "normal" Lisp objects in
the same image.

And now we arrive at the most exciting part: other Lisp libraries can
be loaded in the same image, and we can create connections. Like, after
loading CLIM and defining how CLPython objects should be presented, we
should get a Python interpreter where classes are displayed graphically
and where you can inspect and modify them by mouse. Imagine that you
have interactively added a method to a class by dragging a function to
a class, then being able to right-click and select "write method",
which will write the definition of the method in the right place in the
class definition source code in your Climacs (CLIM-based Emacs) buffer.

That's the kind of features I have in mind, and the best thing is that
conceptually a lot of the work consists of connecting dots that already
out there. But as there are so many of them, a few extra pencils would
be quite welcome <wink>

- Willem

[Hendrik van Rooyen]

Re: merits of Lisp vs Python

"greg" <greg@cosc.cant erbury.ac.nz>

>
I once heard mention of a system of units in use at
one time with the odd feature that capacitance came
out in units of length.
>
Picture the scene: Hobbyist walks into Dick Smith
store and says "I'd like a 5cm capacitor, please."
>

This is correct - think of it as the number of electrons that
can dance on the surface of a sphere of radius r.

So your hobbyist will be handed a copper ball of 10cm
diameter...

Seriously, in electrostatic units, capacitance is measured
in length. (or it was when they were trying to teach me
Physics)

- Hendrik

[=?ISO-8859-15?Q?Andr=E9_Thieme?=]

Re: merits of Lisp vs Python

greg schrieb:

André Thieme wrote:

> (aif (timeConsumingC alculation)
> (use it))

>
I think the answer is that you just wouldn't do
that in Python at all. Having magic variables
spring into existence in your local namespace
as a side effect of calling something is just
not Pythonic. (It is very Perlish, on the other
hand.)
>
The closest you might come is using the new
"with" statement like this:
>
with aif(timeConsumi ngCalculation() ) as it:
use(it)
>
where the object returned by aif(x) has an
__enter__ method that raises an exception which
aborts the whole with statement if x is None,
thus avoiding executing the body. But that's
so horribly convoluted that any sane programmer
would just write it out the straightforward
way to begin with.

Sounds like "Blub" to me:

http://www.paulgraham.com/avg.html

I will quote some parts of it:

"You can see that machine language is very low level. But, at least as a
kind of social convention, high-level languages are often all treated as
equivalent. They're not. Technically the term "high-level language"
doesn't mean anything very definite. There's no dividing line with
machine languages on one side and all the high-level languages on the
other. Languages fall along a continuum [4] of abstractness, from the
most powerful all the way down to machine languages, which themselves
vary in power.

[...]

Programmers get very attached to their favorite languages, and I don't
want to hurt anyone's feelings, so to explain this point I'm going to
use a hypothetical language called Blub. Blub falls right in the middle
of the abstractness continuum. It is not the most powerful language, but
it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of
them. Of course he wouldn't program in machine language. That's what
compilers are for. And as for Cobol, he doesn't know how anyone can get
anything done with it. It doesn't even have x (Blub feature of your
choice).

As long as our hypothetical Blub programmer is looking down the power
continuum, he knows he's looking down. Languages less powerful than Blub
are obviously less powerful, because they're missing some feature he's
used to. But when our hypothetical Blub programmer looks in the other
direction, up the power continuum, he doesn't realize he's looking up.
What he sees are merely weird languages. He probably considers them
about equivalent in power to Blub, but with all this other hairy stuff
thrown in as well. Blub is good enough for him, because he thinks in
Blub.

When we switch to the point of view of a programmer using any of the
languages higher up the power continuum, however, we find that he in
turn looks down upon Blub. How can you get anything done in Blub? It
doesn't even have y.

By induction, the only programmers in a position to see all the
differences in power between the various languages are those who
understand the most powerful one. (This is probably what Eric Raymond
meant about Lisp making you a better programmer.) You can't trust the
opinions of the others, because of the Blub paradox: they're satisfied
with whatever language they happen to use, because it dictates the way
they think about programs."



André
--

[Paul Rubin]

Re: merits of Lisp vs Python

André Thieme <address.good.u ntil.2007.feb.0 5@justmail.dewr ites:

Sounds like "Blub" to me:
http://www.paulgraham.com/avg.html

It never occurs to Lisp programmers that Lisp, too, might be a Blub.

[=?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=]

Re: merits of Lisp vs Python

Paul Rubin schrieb:

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

>Personally, I've always preferred use the imperative to describe
>basic math rather than the passive. This would seem to map better to
>RPN than infix.

>
For writing down complicated, nested expressions too? That's very
unusual. E.g.
>
n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
>
vs. the same thing in Lisp notation, and that's not even so complicated.

As I said earlier: if there are three formulas in your code, then it
doesn't matter too much.
If you write more then use infix in Lisp. It even looks better than Python:

[7x₆ + 9π³ - 6ˣ]

or

(if [√2 ≈ 1,41]
(print "Yay"))

Or mathematical reasoning:
(proof [∃ x∈M ∀ y∈Q : x≤y])

So what?


André
--

[Slawomir Nowaczyk]

Re: merits of Lisp vs Python

On Sat, 16 Dec 2006 14:09:11 +0100
André Thieme <address.good.u ntil.2007.feb.0 5@justmail.dewr ote:

#Sounds like "Blub" to me:
#http://www.paulgraham.com/avg.html

Well, too bad for you...

#I will quote some parts of it:
#<snip>

#"By induction, the only programmers in a position to see all the
#differences in power between the various languages are those who
#understand the most powerful one."

This statement is, clearly, right.What I can not comprehend is how
Lispers tend to mis-read "comprehend " above as "think is the best". Some
of us *do* comprehend Lisp, understand that there are uses for macros,
just do not see the overwhelming need for them in everyday work (given
sufficiently rich language core).

I other words, people (in this sub-thread, at least) do not argue that
Python is *as powerful* as Lisp -- we understand there are things macros
can do easier/faster/more conveniently than functions or other features
Python has. Lisp *is* more powerful than Lisp. You win.

What we try to understand is why would you think Lisp is a better
programming language than Python :)

Sure, there are times I wish Python had macros. I would be able to save
a couple of keystrokes here and there. But at other times, I am glad it
does not have them, because when I read Bad Code (commonly used synonym
for "somebody else's code") I do not need to wonder what aif and 1000
others, similar things really do.

In my experience, *if* somebody really needs aif, it can be done without
macros. But without macros people will only introduce such thing if it
does save significantly more than 3 or 4 lines of code in the whole
project -- which is a good thing in my book. YMMV.

I by far prefer to have

it = timeConsumingCa lculations()
if it:
use(it)

five (or even ten) times in a medium sized project than to have to
figure out what "aif" means. If the idiom is used 100 times, then
something is wrong: either system should be redesigned or introducing
"aif" is a good idea (but then Python idiom works just as good as Lisp
one). YMMV.

--
Best wishes,
Slawomir Nowaczyk
( Slawomir.Nowacz yk@cs.lth.se )

There are 2 kinds of people in the world - those that divide
the people into 2 groups, and those who don't.

[Ken Tilton]

Re: merits of Lisp vs Python



Kay Schluehr wrote:

Ken Tilton schrieb:
>
>

>>Looks promising. How does a generic engine that sees only a solution (a
>>list of mathematical expressions and for each the transformations ,
>>results, and opnds logged by individual TF functions) build up this
>>environment such that it has named attributes such as signed-value?

>
>
Most likely it doesn't since there is no such engine. Instead local
rules and combinators are encoded in classes. Hence there is nothing
but an object tree and actions are threaded through recursive method
calls.

Most likely that is the engine of which I was speaking. :) Why does the
engine consisting of "internal" methods make it not an engine? I think
you saw the word "engine" and assumed I did not understand OO design. I
feel a Naggum coming on...

kt

ps. This won't make sense unless you know about my Cells project, but
the solution to a /problem/ which has attributes expr and instructions,
is a declarative attribute of a problem. But that attribute is coded
essentially like this:

(defclass problem ()
....
(solution :accessor solution
:initform (c-formula ()
(solve (expr self) (instructions self)))))

k

>
This implies that the generic reverse function is just the dual of a
method call:
>
def reverse(expr):
return expr.reverse()
>
What expr does depends on the internal representation encoded in the
class of expr. This also implies that not only the form of the
expression is significant but also its ( dynamic ) type.
>

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

[Raffael Cavallaro]

Re: merits of Lisp vs Python

On 2006-12-16 08:21:59 -0500, Paul Rubin <http://phr.cx@NOSPAM.i nvalidsaid:

It never occurs to Lisp programmers that Lisp, too, might be a Blub.

Of course it does - Thats why we try ocaml and haskell etc. It's just
that we don't see the useful features of these languages as being
sufficiently useful to compensate for their lack of the ability to
easily do syntactic abstractions over a uniform syntax. There's no
question that other languages have some features that common lisp does
not (and vice versa). Lispers just can't abide being locked into a
particular paradigm because a language doesn't have the basic features
(macros and uniform syntax) necessary to provide new paradigms for
ourselves when needed or wanted.

For example, a common lisp with optional static typing on demand would
be strictly more expressive than common lisp. But, take say, haskell;
haskell's static typing is not optional (you can work around it, but
you have to go out of your way to do so); haskell's pure functional
semantics are not optional (again, workarounds possible to a limited
extent). This requires you to conceive your problem solution (i.e.,
program) within the framework of a particular paradigm. This lock-in to
a particular paradigm, however powerful, is what makes any such
language strictly less expressive than one with syntactic abstraction
over a uniform syntax.

[Juan R.]

Re: merits of Lisp vs Python

Raffael Cavallaro ha escrito:

This lock-in to
a particular paradigm, however powerful, is what makes any such
language strictly less expressive than one with syntactic abstraction
over a uniform syntax.

Right, but it would be also remarked that there is not reason to
ignoring the development and implementation of specific syntaxes,
paradigms, etc. optimized to specialized (sub)fields of discourse.

If all you need is basic arithmetics and 'static' data structures,
optimization á la Python Y = a + b * c gets sense in most of cases.

If you are developing symbolic software where data structures as highly
'dinamic' and where you would wait something more than sums, divisions,
sines and cosines, and some numeric differentials then the parens
automatically gets sense.

Using LISP-like syntax for everything would be so stupid as using
quantum mechanics for billiards.

[Juan R.]

Re: merits of Lisp vs Python

Using LISP-like syntax for everything would be so stupid as using
quantum mechanics for billiards.

Claiming that LISP parens are Stupid, Superfluous, or Silly just
because you do not need them in your limited field of discourse, would
be so stupid as those people thinking that just because they use
classical mechanics at the macro scale and works for them, then
classical mechanics would also work at the atomic scale[*].
[*] Even today, after 100 years some people think that quantum
mechanics is Stupid, Superfluous, or Silly and some classical
formulation will replace.

[Kirk Sluder]

Re: merits of Lisp vs Python

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

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

Personally, I've always preferred use the imperative to describe
_basic_ math rather than the passive. This would seem to map better to
RPN than infix.

(emphasis added)

For writing down complicated, nested expressions too? That's very
unusual. E.g.
>
n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
>
vs. the same thing in Lisp notation, and that's not even so complicated.

I wasn't even talking about Polish notation vs. other standard
notations. I was talking about your claimed correspondence between
infix and natural Languages.

(1/12n) - "divide 1 by the product of" of 12 and n"
sqrt(2*pi*n) - "calculate the square root of the product of 2 pi and
n."

If computer languages were to mimic natural languages on this point,
they would support both forms of expression and be sensitive to mode
and mood.

[Jon Harrop]

Re: merits of Lisp vs Python

Raffael Cavallaro wrote:

Of course it does - Thats why we try ocaml and haskell etc. It's just
that we don't see the useful features of these languages as being
sufficiently useful to compensate for their lack of the ability to
easily do syntactic abstractions over a uniform syntax.

That applies to the Lispers who've tried other languages and stayed with
Lisp.

There's no
question that other languages have some features that common lisp does
not (and vice versa). Lispers just can't abide being locked into a
particular paradigm because a language doesn't have the basic features
(macros and uniform syntax) necessary to provide new paradigms for
ourselves when needed or wanted.

Why do you think that uniform syntax is necessary to provide new paradigms
when it is equivalent to infix syntax?

For example, a common lisp with optional static typing on demand would
be strictly more expressive than common lisp. But, take say, haskell;
haskell's static typing is not optional (you can work around it, but
you have to go out of your way to do so); haskell's pure functional
semantics are not optional (again, workarounds possible to a limited
extent).

In what way is Haskell's support for imperative programming limited?

This requires you to conceive your problem solution (i.e.,
program) within the framework of a particular paradigm. This lock-in to
a particular paradigm, however powerful, is what makes any such
language strictly less expressive than one with syntactic abstraction
over a uniform syntax.

Can you give an example of a Lisp macro that does something useful that you
can't do in these other languages?

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

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

[Kirk Sluder]

Re: merits of Lisp vs Python

In article
<kirk-1ECB42.13333516 122006@newsclst r03.news.prodig y.net>,
Kirk Sluder <kirk@nospam.jo bsluder.netwrot e:

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

n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...

>
If computer languages were to mimic natural languages on this point,
they would support both forms of expression and be sensitive to mode
and mood.

And ok, bringing this around to lisp, many complex expressions such
as polynomials can be viewed as lists of sub-expressions. So in this
case, the expression can be re-written as:

(* (subexp1) (subexp2) (subexp3) (subexp4))

Which is probably how I'd solve the expression if I was using paper
and pencil: simplify and combine.

And there is something that is missing here in arguing about
computer language notations in relationship to human language
readability, or correspondence to spoken language. I'm not writing
code for another human, I'm writing code for a machine. Often, the
optimum expression of an mathematical concept for a machine is
relatively baroque compared to the optimum expression for a human
being.

[xscottg@gmail.com]

Re: merits of Lisp vs Python

Ken Tilton wrote:

xscottg@gmail.c om wrote:

Code is data is code

>
I was hoping no one would make that mistake. :) macros are all about
code is data, but code is not data in Python* so the two words code and
data serve to differentiate them for Pythonistas.
>

I disagree. I frequently write data-driven algorithms in C and Python
(data is code). I occasionally write code-generators too (code is
data). Just because the representation is different between code and
data in those languages doesn't mean that you can't use data as code
(interpreter style) or generate code as data (compiler style). (I
won't bother boring you with the Python bytecode hacks or the parser
module, because I think those are not terribly practical.)

It's very elegant that Lisp makes the representations between code and
data so similar, but it looks like you know the mantra and not the
meaning if you can't apply that principle in other languages.

BTW... Even in Scheme, I have to use syntax-object->datum and it's
inverse to switch between the two. I suspect this has something to do
with the other context that must be associated with the data to turn it
into code. Probably at least the enclosing environment for lexical
scoping and the line numbers for debugging or exception handling. Does
Common Lisp maintain this information with it's macro expansions? If
so, you have a slight difference between code and data too. If not,
how do you get the line number when a problem happens in a nested
macro?

Moreover, if you really want to be pedantic about what "is" means in
"code is data", then you have to acknowledge that data is a superset of
code, since all code is obviously data, but there are plenty of types
of data that aren't used as code. Or are they? :-)

* Taking questions after a keynote to ILC200? where he reiterated that
Python was the same as Lisp for all intents and purposes:
>
Norvig: "Yes, John?"
McCarthy: "Is code also data in Python?"
Norvig: "No."
>
End of exchange. :)
>

Really? You're relying on an appeal to authority? Ok, I'm going to
start arguing by analogy then...

def reverse(cls, *args):
# I didn't understand what your code was doing

>
yeah, and god forbid you should ask. :) this is the crux of the matter!
>
Actually, it is kinda cool that you and Greg are semi-identifying the
crux by saying "this is the only bit I do not get, I'll skip this, move
on, nothing to see here".
>

Ok, I'll bite. What does it do? I read through it, and it looks the
code you're passing to the macro does some things like calculating the
number of decimal digits and generating a 2 + a random number of that
many digits to find a divisor or something. It also looks like you
have some "string interpolation" to substitute names in your text, but
as a whole, I really don't have any clue what it's all about.

It looks like the macro itself is building some names on the fly and
defining methods (new specializations for multimethods?) with those
names.

So I'm sure I'm missing something, but there is almost certainly a
readable equivalent in Python (and even C). If you really want to
generate dynamic names for functions, you can do that in Python by
modifying the class or globals hash or whatever. A more standard way
might be to be have members in the base class.

There is even a multi-methods module in Python, but I've never used it.
I'd guess you could add to that dynamically too.

That would be a reasonable place for a "pie decorator" on a class, but
I guess that's not allowed.

>
Hmmm. Actually, that is the whole point, all of Python is allowed.
decorators were used in PyCells, but I never got much of an idea what
they did. Is there a moral equivalent of a macroexpansion for decorators
so you can show the before and after?
>

It's Python that doesn't allow you to decorate classes. (You can
decorate functions, but not classes...) I made this comment as a
criticism of Python since it seems like a non-orthogonal corner... It
would have fit in this case.

Decorators are pretty simple:

@foo
def bar(): pass

is equivalent to:

def bar(): pass
bar = foo(bar)

The callable foo can use whatever it wants to inspect, modify, or wrap
the function bar.

but:

@foo
class bar: pass

is not currently allowed, so you have to do

class bar: pass
bar = foo(bar)

>
exactly what we are looking for in this cultural exchange: how would
Python handle what I am doing with macros in the reverse functions? Make
it as slick and programmer-friendly (cuz I may get to a hundred of these
before I am done with Algebra I) as possible. When all the Pythonistas
proclaim it optimal, then we compare and contrast.
>
This, btw, is the Tilton Test for language comparison: Not measurements
of programmer effort, rather examination of perfect equivalent code.
PyCells vs Cells would be an amazing case, because that is some hairy
functionality.
>

That seems like a fine strategy. I fall more on the programmer effort
side. I want to write as little code as possible in a readable way
such that it meets the requirements.

I'm not a particularly good ambassador for Python. I know Python much
better than Lisp (Scheme), but I already think Scheme is a better
language. Macros are part of that. I'm mostly playing devil's
advocate here because I don't think your example really brings it home.
I've got limited time that I'm willing to invest in learning your
algebra system, but I haven't seen (understood, if you insist) anything
yet that couldn't be done readably in Python. If you want Common Lisp
to win in your language battle against the Pythonistas, you're going to
need to break out with something stronger. Then again, you're probably
pissing into the wind anyway.


Cheers,
-Scott