merits of Lisp vs Python

[Paddy]

Re: merits of Lisp vs Python


Paul Rubin wrote:

"mystilleef " <mystilleef@gma il.comwrites:

Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
sure.

>
>
Anyway it's pretty lousy advocacy for a language to say "well if the
language is too slow, don't use it, use another langauge like C instead".

Python can be used as a glue language. It is not solely a glue
language.
A lot of people find using Python to script libraries written in other
languages
a way to get things done. Ask the scipy guys or the biopython guys.
The Python community actively encourages groups writing useful
libraries
to maintain a Python port, or Python users might wrap libraries
themselves.

You don't always wrap a module in Python for reasons of speed of
execution.
Software testing may well be easier to do in Python than in the
native language of the wrapped library. The library itself may be
better
used in the dynamic environment of Pythons command line; or used
together
with other libraries already wrapped for/accessible from Python.

- Paddy.

[Larry Elmore]

Re: merits of Lisp vs Python

mystilleef wrote:

John Thingstad wrote:

>You are just being silly.
>Lisp's OO environment CLOS is vastly superior to Python classes.
>Both in terms of expressive power and flexibility.
>You might even find out if you ever learnt how to use it.
>>

>
Donkeys have wings.

And thus you think you can fly?

>In the windows world the best way to access system libraries are
>via .NET. Thus each language inventing it's own libraries is quickly
>becoming

>
You're only proving my point. Why do you think most windows developers
use .NET?

I didn't realize .NET is a *language*.

>Python is fine if you approach programming as Lego, simply gluing together
>libraries.

>
You mean it's fine for what 90% of programmers do?
>

>But if you want to do some serious algorithmic's you may find that it is
>just to slow.

>
Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
sure.
>

[John Thingstad]

Re: merits of Lisp vs Python

On Sun, 10 Dec 2006 01:29:43 +0100, Steven D'Aprano
<steve@REMOVE.T HIS.cybersource .com.auwrote:

>
>
Oh my god! Lisp can echo STRINGS to the interpreter???? Why didn't
somebody somebody tell me that!!!! That *completely* changes my mind
about
the language!
>
I'm especially impressed that it knew I wanted them printed in uppercase
without being told.
>
>
>

Except it is not a string. It is a list of symbols. Hence the upcase.
"This is how you write a string in Lisp"
and that does preserve case.
(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.)

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[jayessay]

Re: merits of Lisp vs Python

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

"Kaz Kylheku" <kkylheku@gmail .comwrites:

Lisp just seems hopelessly old-fashioned to me these days. A
modernized version would be cool, but I think the more serious
Lisp-like language designers have moved on to newer ideas.

What are some of their names, and what ideas are they working on?

>

http://caml.inria.fr

http://www.haskell.org

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



/Jon

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

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sat, 09 Dec 2006 21:55:19 +0000, Kirk Sluder wrote:

The question I have is why do critics
single out macros and not other forms of abstraction such as
objects, packages, libraries, and functions?

Who says they do? All forms of abstraction have been criticized. Sometimes
the criticism is valid. Sometimes it warns against abuses of the
abstraction. Just because a feature is useful sometimes doesn't
necessarily mean the benefit outweighs the cost.

just as an example:
from foolib import *
bar.bar("somefi le")
>
What does this program do? I have no idea. Its functionality is
hidden behind multiple layers of abstraction (function, object,
library.)

Sure.

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

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
problem of perception rather than a problem of fact, but you have to ask,
why do people perceive Lisp that way?

Could it be because of people like J Shrager who writes things like this?

"Can't you just expand the language via macros to create whatever facility
of this sort [major new features with new syntax] you need..."

(This thread, dated 8 Dec 2006 16:14:44 -0800)

Or Wolfram Fenske:

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

(This thread, dated 8 Dec 2006 23:38:02 -0800)

To someone outside of Lisp, that looks like "I can make Lisp look like any
language I like in just a few lines." And that implies that to read a Lisp
program, one might need to be able to read code that looks like Lisp, or
Smalltalk, or Prolog, or Fortran, or all of those, or whatever bizarre
syntax the developer wanted it to look like.

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?

And it isn't really that much comfort to be told that good Lisp
developers know not to do stupid things with macros. Sure. But in the real
world of programming, most developers aren't good developers, they are
merely average -- in fact fifty percent of them are below average. And
the bottom 30% can't be trusted with facilities like Lisp's macros,
because they WILL do stupid things with them and turn your code base into
a morass of shifting syntax, buggy DSLs and other maintenance nightmares.
The damage they can do with operator overloading is minor by comparison.

Even something simple like file I/O can be abused. Example: I've seen
*real* code where somebody needed a dict with ten million keys. (Well, he
thought he needed that dict, I never worked out exactly why. Maybe he
thought he was pre-allocating memory as an optimization.) So he started
off with something like this:

def make_dict():
mydict = {}
mydict[0] = 0
mydict[1] = 0
mydict[2] = 0

and realised that it would take him forever to write that much code. So
he wrote a C program to create the make_dict function for him! Translated
into Python:

def make_dict_facto ry():
code = open('makedict. py', 'w')
code.write("def make_dict():\n" )
code.write(" mydict = {}\n")
for i in range(10000000) :
code.write(" mydict[%d] = 0\n" % i)
code.write(" return mydict\n")
code.close()
from makedict import make_dict
return make_dict

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

Honest to god, the code really was like that! Maybe I've got the precise
details wrong, it was a long time ago, but if it wasn't just as I've got
it, the consequences were the same: he built a single function that was so
large that loading it caused his machine to thrash for twenty minutes
trying to free enough memory.

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

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.

When it comes to Lisp's macros, the perception is that the power is
correspondingly greater, and the risk of abuse even more so. The safe
examples of what macros can be used for don't seem to provide any
over-whelming advantage (that's not to say they provide NO advantage,
merely that if you use macros safely, the advantage seems small, but if
you use them to their full potential, the risk of abuse is too high).
That's the perspective of many people, and maybe it is wrong. Maybe you
really need to be immersed in Lisp for a while to see the advantages of
macros.

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.



--
Steven.

[Paul Rubin]

Re: merits of Lisp vs Python

"tac-tics" <tactics40@gmai l.comwrites:

I think the lesson here is that LISP is the language you use when you
want mathematical elegance and perfection and Python is the language
you use if you want to actually program stuff.

That's really a misperception. Lisp is extremely pragmatic in
addition to traditionally having more mathematically oriented
developers and users. There is a saying that Lisp is a ball of mud;
you can throw whatever you want into it and it's still Lisp. Python's
current implementations and the supposedly fancy Python applications
that I've heard of are toys compared to what's been done in Lisp even
on the much smaller machines of decades gone by.

What I'd say is that the most interesting period of Lisp development
was probably the 1970's and 1980's, trailing off into the beginning of
the 1990's. Since then Lisp has gotten kind of stultified, although
one of the cll posters claims there's now a revival going on (maybe
true). It seems to me that many Lisp users and developers moved on to
the ML family in the 1990's and maybe have been moving from ML to
Haskell in more recent times.

[Paddy]

Re: merits of Lisp vs Python

Mark Tarver wrote:

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?
>
Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.
>
Mark

NOBODY expects the Lispers Inquisition!
Our chief weapon is age... age and macros...
....macros and age.
Our two weapons are age and macros....
And mathematical rigour...
Our THREE weapons are age, macros, and mathematical rigour...
....And an almost fanatical belief in Lisps superiority.
Our *four* ...no.
AMONGST our weapons...
Amongst our weaponry...
....Are such elements as fear, surprise.... I'll come in again.



Python is fun to use.
Easy to read.
Simple and powerful.
Easy to test.
Easy to maintain.
Fast. Very fast!

- Paddy.
..

[Paul Rubin]

Re: merits of Lisp vs Python

"Paddy" <paddy3118@nets cape.netwrites:

Python can be used as a glue language. It is not solely a glue
language.
A lot of people find using Python to script libraries written in other
languages
a way to get things done. Ask the scipy guys or the biopython guys.

Sure, connecting together programs and libraries that were written in other
languages is what a glue language is.

You don't always wrap a module in Python for reasons of speed of
execution.
>
Software testing may well be easier to do in Python than in the
native language of the wrapped library. ...

That's the thing, those modules are written in languages other than
Python because Python is not attractive for coding those functions
directly in Python. That is a real weakness of Python and glossing
over it by saying to write the functions in other languages and then
wrap them in the C API is not a very impressive answer. For example,
Lisp is routinely used for writing scientific and numerical code
directly with performance comparable to C or whatever. There is no
need to mess with wrapping modules written in other languages, an
operation which should not be trivialized.

[Paul Rubin]

Re: merits of Lisp vs Python

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.

[greg]

Re: merits of Lisp vs Python

Bill Atkins wrote:

And mistakes in nesting show up as mistakes in
indenting.

Er, hang on a moment... how do you *know* when you've
got a mistake in indending? You must be visually
verifying the indentation... rather like one does
with Python code...

--
Greg

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sat, 09 Dec 2006 14:40:07 -0800, webraviteja wrote:

Personally, I find it strange that we, who argued so many times for
dynamic typing, the need for expressiveness and that it is OK to trust
the programmer with power ("we are all adults here" argument) while
arguing against relatively restrictive languages like Java find macros,
a chaotic and disruptive concept.

Why? The benefit of expressiveness and power isn't monotonically
increasing. Look at us: we're all communicating in a common language,
English, and we all agree on syntax and grammar. Now, I could be a lot
more expressive, and language could be a lot more powerful, if I could
define my own language where "You are a poopy-head" was in fact a detailed
and devastatingly accurate and complete explanation for why Python was a
better language than Lisp. You, however, not being an expert in my far
greater expressive language, would see none of that, and would be under
the mistaken impression that I was insulting you.

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.

The same goes for programming languages. Extra expressiveness comes at the
cost of reduced communication between programmers -- the code becomes
harder to read for those who haven't already learnt how to read it. So
there is no contradiction in the positions that "we are all adults here"
and "macros give too much power". The first is a design decision, the
second is a trade-off, just like the lack of C-style pointers in Python is
a trade-off.



--
Steven.

[Ken Tilton]

Re: merits of Lisp vs Python



Steven D'Aprano wrote:

Rightly or wrongly, people fear...

So when people fear wrongly we burn whatever witches we must to reassure
them?

that Lisp's macros push Lisp closer to
that hypothetical anything-goes language than is healthy. Maybe that's a
problem of perception rather than a problem of fact, but you have to ask,
why do people perceive Lisp that way?
>
Could it be because of people like J Shrager who writes things like this?
>
"Can't you just expand the language via macros to create whatever facility
of this sort [major new features with new syntax] you need..."

The context was CLOS. Something that big needs new syntax. But what you
do not know is that the syntax is Lispy, so learning it is tantamount to
understanding new function names, as even Pythonistas must do (tho a few
of you seem to think Pythonistas are incapable of learning <g>).

>
(This thread, dated 8 Dec 2006 16:14:44 -0800)
>
Or Wolfram Fenske:
>
"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."

Right, something big like an OO.

>
(This thread, dated 8 Dec 2006 23:38:02 -0800)
>
To someone outside of Lisp, that looks like "I can make Lisp look like any
language I like in just a few lines."

On the contrary, on the rare case when it happens (CLOS, my Cells
package) one is obliged by exactly the hobgoblins you fear to remain
true to lisp patterns when extending Lisp. And there are patterns in
macro usage as well:

(my-macro <optional arguments to macro expansion>
<my-macro-forms>+)

Your hands must be getting sore from banging that drum so hard and so
long -- has it ever occurred to you that good programmers concerned with
power do not obfuscate code? And now you have read a dozen messages from
serious Lispniks trying to tell you that that is not the case, and you
persist.

We love the chance to preach to the unsaved, so we are indebted to you
for the many chances to clarify, but something tells me I should check
the c.l.p archives to make sure I am not chatting away happily with the
village idiot. :)

And that implies that to read a Lisp
program, one might need to be able to read code that looks like Lisp, or
Smalltalk, or Prolog, or Fortran, or all of those, or whatever bizarre
syntax the developer wanted it to look like.

"I don't want to think, I just want to bang on de drum all day.
I don't want to learn, just want to bang on de drum all day."

>
My point isn't whether or not their claims are correct (a "couple" of
macros? really?) but that things like this feed the perception...

Ah, well at least you are copping to witch-burning. Thx.

And it isn't really that much comfort to be told that good Lisp
developers know not to do stupid things with macros.

Hmm, didn't we see that as a comforter for some powerful Python
mechanism earlier in this thread?

Sure. But in the real
world of programming, most developers aren't good developers, they are
merely average

Two questions: do you really voluntarily use libraries from crappy
developers? Second, you think a language can stop people from writing
bad code? Java tried, and look where that got the language. Elsewhere a
Pythonista (Mr. Rubin?) bemoaned this thread's appearance of Pythonistas
shrinking from power... could you two get together? :)


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 14:55:13 -0800, Paul Rubin wrote:

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

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

>
Macros let you write what amounts to functions that don't evaluate
their arguments. Think of the endless clpy wars over the ternary
conditional operator.

[snip]

That is trivial to do with a macro

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.

but can't be done with a function.

*shrug*

You can't get to Sydney from Melbourne via Hobart by bicycle either. You
either change the requirements (why does it have to be by bicycle?) or the
path (why go through Hobart?) or change the infrastructure (build a long,
long bridge connecting Hobart to the mainland). That's three tactics for
solving the problem of "go from Sydney to Melbourne". It is just not true
that the only "correct" solution is to build the bridge.

In the case of the ternary operator, changing the language is like
building the bridge. It's *a* solution. Maybe it is even the best
solution. But it is ludicrous to say that "change the language" is the
only solution.

(I know you didn't say that -- but so many people seem to think that
adding new syntactic support for their pet feature is the only solution to
their problem, no matter what the problem. Those people would, I imagine,
wet themselves in excitement if Python ever got macros. "Now at last I can
make Python look just like the bastard love-child of Perl and Java!" *wink*)


--
Steven.

[Ken Tilton]

Re: merits of Lisp vs Python



greg wrote:

Bill Atkins wrote:
>

>And mistakes in nesting show up as mistakes in
>indenting.

>
>
Er, hang on a moment... how do you *know* when you've
got a mistake in indending? You must be visually
verifying the indentation... rather like one does
with Python code...

Absolutely, and you are not disagreeing with Mr. Atkins, tho you seem to
think you are.

But with Lisp one does not have to clean up the indentation manually
after thrashing away at ones code. As I type each right parens I eyeball
its partner as the editor highlights it to make sure I have not missed
anything, then give the re-indent command and eyeball the result. It
/is/ still possible to screw up because I work fast and loose, but only
very rarely do I end up with a parens in the wrong place, and then the
compiler finds something to whine about.

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 17:01:15 -0500, Ken Tilton wrote:

>How's this a good thing? I don't need a Python environment to grok
>Python code.

>
How would that be a bad thing? Do you do a lot of programming without a
Python environment. But I love the wall of flak you are throwing up. :)

Actually, yes, sometimes it is useful to print code out and read it on the
train, or in the bath, without the advantage of syntax highlighting,
pretty-printing, parenthesis-balancing or code folding. Not necessarily as
pleasant as having all those things, but it is nice that working Python
code is, by definition, already formatted correctly for pretty printing.
Even if you're stuck on some god-forsaken Windows PC with just Notepad,
you can still read Python code.

Now, *writing* Python code with Notepad isn't as easy, but it is still
doable. How about Lisp code?

That's not a criticism of Lisp exactly, but a reminder to think about not
just what problem you're trying to solve, but what resources you will have
to solve it. If you *know* that you're going to need to edit code by
ssh-ing across an high-latency connection to a machine without Emacs, then
Lisp will probably not be the best solution.

The day has not yet arrived that nobody ever needs to edit code in a
plain, vanilla text editor.



--
Steven.