merits of Lisp vs Python

[hit_the_lights]

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


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

I have a very interesting Python module. Look what it does:

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

Somehow the meaning of "import" changed between the first
and the second line. Doesn't it frighten you?
(BTW: Do you know how that works, or should a Lisper show
you?)

It seems that Phytonistas, including Guido, don't trust each
other. Guido always provides half assed restrictive solutions
instead of decent meta programming. Examples include "lambda",
the new "with" syntax and decorators.

 

[Steven D'Aprano]

On Sun, 10 Dec 2006 00:03:11 -0800, Wolfram Fenske wrote:

[snip]

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.

So you say. I've heard it be said that anytime you do anything more than
once, you should abstract it away into a function or macro.

Of course, that was the same person who told me that no function should
ever be more than five lines of code, so perhaps you might consider him
prone to over-stating his case.



[snip]

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

You still have to include SOME_STATUS in the Lisp example. Calling it
boilerplate for Python is unfair.

[snip]

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.

Yes, Python doesn't have a case/switch statement. It may get one in the
future. There are advantages to a case statement, but they aren't
overwhelming, and there are costs to implementing it.

Now you're being silly.

How am I being silly? Do you not believe that people write case blocks
with fifty tests? Okay, how about twenty? Ten? Eight?

One of the advantages of Lisp's ecase macro was specifically stated to be
that it gave you the error message for free, without the coder having to
add new terms to the message as they add new comparisons. Why is it
"silly" to question whether that feature is always useful?


[snip]

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: [snip]
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.acquire()
try:
connection = sqlite.connect(self.dbFile)
connection.row_factory = dictFactory
try:
return fun(connection)
finally:
connection.close()
finally:
self.lock.release()
--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.

Hang on -- why can't you just call the function again?

If you're talking about calling withConnection with different functions,
then of course you have to define a different function each time. How is
that different from the Lisp macro? You still have to write that.

And these functions -- shouldn't they be tested? If they were just
anonymous blocks, won't they be hard to test? These aren't rhetorical
questions.

 

[Juan R.]

Not without barreling through error messages about name conflicts.

By LISP do you mean CL?

In Scheme next

(+ 1 2)
--> -1

is possible. It would be possible in other dialects of LISP also

 

[Dmitry V. Gorbatovsky]

So which is it? If Lisp is so self-evidently better than every other
language, and if nobody has any fears or concerns with Lisp, why is Lisp a
fringe language?

Because shifting to lisp somewhere in the middle of
your project or carear is VERY EXPENSIVE STEP.
And its doubtable movement for absolute majority
of GUI's button makers.

 

[Ken Tilton]

That's your opinion, and as an experienced Lisp coder, it is an opinion
worth treating seriously. Nevertheless, a mere denial doesn't constitute
evidence, let alone proof.

Well, it does unless you think we are lying, or creating obfuscated code
and do not know it. This would be consistent with the theory that we
positively love parentheses only because we are mutants. To be honest, I
think it would be way cool if it turned out I was this mutant life form,
the only kind that can understand Lisp. And this would be consistent
with my theory that John McCarthy must be an alien. How else can he
wander over to his desk one day, misread Church, and create a language
that, as you say, is growing in popularity and whose essence can be
found in every popular language except C++, which only makes my point.

Have you read On Lisp by Paul Graham? It is on-line. Just the preface
will do, I think, maybe also Chapter One where he raves on macros. Do
you think he is mistaken? Confused? Lying? Mutant?

This exchange has not been a complete disaster, but it sure could have
covered a lot more ground if you had not had your hands over your ears.

Now I see you want Lispniks to explain its unpopularity. I like that, we
have to figure out what is wrong with you. Apparently that would be
fear of the unknown, xenophobia, and prejudice. Meanwhile, given that
Python and Ruby have copied so much from Lisp, and that languages seem
to be converging on Lisp, now we have to have an equally daft exchange
over the possibility that Lisp is the most popular language going. Even
Java has Groovy.

Lisp has all the cool qualities you like in your pets, plus native
compilation in most implementations, plus maturity and a standard, plus
a better OO, plus macros, plus a dozen more small wins. Including
automatic indentation.

It is just a matter of critical mass. At some very low threshold Lisp
becomes "OK". I get the feeling that has already begun, but it is not
quite there yet. Certainly it gets mentioned now when language names get
bandied about, if only to be dismissed. That is a step up for us.

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

 

[Paul Rubin]

Have you read On Lisp by Paul Graham? It is on-line. Just the preface
will do, I think, maybe also Chapter One where he raves on macros. Do
you think he is mistaken? Confused? Lying? Mutant?

I remember Paul Graham's piece about macros that made him sound like
someone who went nuts with them, as is certainly possible to do. In
my experience, good coders write for clarity and that includes in
their use of Lisp macros. All in all Lisp's macro system is something
like the C preprocessor. Yes, you can obfuscate things horribly with
it, but you can also use it to make things clearer, and that's what
good programmers do.

 

[Juan R.]

Ken Tilton ha escrito:

It is just a matter of critical mass. At some very low threshold Lisp
becomes "OK". I get the feeling that has already begun, but it is not
quite there yet.

Sometime in the past LISP got an increased 'popularity' (i suspect
because LISP natural fit into web services). However, i also noticed
that since some months ago, the TIOBE index for LISP decreases and
decreases and decreases... whereas Python, Ruby, and company increase.

Last December index, Ruby increases ranking by 9 positions to 11th,
Python 1 to 7th, whereas LISP decreases to 17th from 13th.

 

[mystilleef]

Lisp has all the cool qualities you like in your pets, plus native
compilation in most implementations, plus maturity and a standard, plus
a better OO, plus macros, plus a dozen more small wins. Including
automatic indentation.

Better OO? You mean the one that doesn't support basic encapsulation
and is retardedly cumbersome to use? There's a reason I said, I'd never
use Lisp for OO not even when I'm high. Gimme Python, Eiffel or
Smalltalk anyday, not the retarded add-on package bolted on CL.

It is just a matter of critical mass. At some very low threshold Lisp
becomes "OK". I get the feeling that has already begun, but it is not
quite there yet. Certainly it gets mentioned now when language names get
bandied about, if only to be dismissed. That is a step up for us.

Bahahahaha! You lispers and your fairy little macros world.

 

[Guest]

Better OO? You mean the one that doesn't support basic encapsulation
and is retardedly cumbersome to use?

Encapsulation isn't so much a property of the language as of your data
types.

There's a reason I said, I'd never use Lisp for OO not even when I'm
high. Gimme Python, Eiffel or Smalltalk anyday, not the retarded
add-on package bolted on CL.

Python also lacks encapsulation, in the sense you probably mean.

 

[Ken Tilton]

I remember Paul Graham's piece about macros that made him sound like
someone who went nuts with them, as is certainly possible to do.

But you could have just flipped thru the rest of the pages to see if he
/had/ gone nuts with them!

In
my experience, good coders write for clarity and that includes in
their use of Lisp macros. All in all Lisp's macro system is something
like the C preprocessor. Yes, you can obfuscate things horribly with
it, but you can also use it to make things clearer, and that's what
good programmers do.

One has to be from the US and of a certain age to remember this, but
this old line from a commercial for high-octane gasoline says it for me:
power to be used, not abused.

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]

Not without barreling through error messages about name conflicts.

Ah, nice to get a straight answer to a question for a change, and without
an insult or a misrepresentation in sight. Thank you.

 

[mystilleef]

Encapsulation isn't so much a property of the language as of your data
types.

"Modern" and well designed object oriented languages provide sane
mechanisms for encapsulation, at least when implementing new types.

Python also lacks encapsulation, in the sense you probably mean.

That's news to me. How so?

 

[Paul Boddie]

Rewriting the sun and moon, or needlessly reinvent the wheel
was popular in the 70s, but it's boring and expensive today. Today,
when a developer needs to solve a problem, the question they ask is,
"Is there a library for that?". If the answer is no, they a more likely
to switch to a language that provides a library that solves their
problem.

Indeed. Software development is not a purely technical discipline:
combinations of issues such as the ability to reuse components, the
availability of such components, economics, project organisation, the
skills of participants, and so on, all start to weigh against the
benefits of being able to roll one's own elegant solutions over and
over again.

The challenge for developers today is software architecture,
robustness and scalability, not language purity or semantics. The Lisp,
and to an extent Haskell, community will never ever ever grok this.

I'm not sure that you're correct about the Haskell community: there
appears to be a fair amount of relevant new work emerging from that
direction which may not only help Haskell developers to deal with the
harder problems of developing scalable and robust systems, but also
might affect the evolution of a number of other languages. However, I'd
agree that with the emergence of languages like Erlang, people want
solutions focused on particular systems engineering problems - it's all
very well arguably having the toolbox to create such solutions, but
most software developers just want to be handed the right tool.

They'll continue to wonder why an "inferior" language like Python keeps
getting popular. It will always escape them that it might be because
Python is actually easier to use for most people to write "real world"
applications. It has good usability.

And with regard to the remark about having access to libraries, it's
worth remembering that there's a lot of envy about things like CPAN -
an extensive collection of libraries for an even more "inferior"
language. When it is said that "CPAN is the language, Perl 6 is the
syntax", the remark should not be a surprise - it's a trend that was
observed at least twenty or thirty years ago, if not before.

Paul

 

[Ken Tilton]

Better OO? You mean the one that doesn't support basic encapsulation
and is retardedly cumbersome to use? There's a reason I said, I'd never
use Lisp for OO not even when I'm high. Gimme Python, Eiffel or
Smalltalk anyday, not the retarded add-on package bolted on CL.




Bahahahaha! You lispers and your fairy little macros world.

I admire your knack for self-refuting discourse.

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

 

[=?ISO-8859-15?Q?Jes=FAs_Carrete_Monta=F1a?=]

Fast. Very fast!

- Paddy.

Well, Python certainly is faster than most people doing floating-point
arithmetic by hand, but I don't think this is the correct argument to use
against Lisp .

 

[Paul Boddie]

[import side-effects]

Somehow the meaning of "import" changed between the first
and the second line. Doesn't it frighten you?
(BTW: Do you know how that works, or should a Lisper show
you?)

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

It seems that Phytonistas, including Guido, don't trust each
other. Guido always provides half assed restrictive solutions
instead of decent meta programming. Examples include "lambda",
the new "with" syntax and decorators.

Actually there are people in the Python community who don't really
approve of stuff like "with", the removal of "lambda" and the lack of
macros, "programmable syntax", and so on. But that's probably not
apparent to those who paint every picture with broad strokes.

Paul

 

[Steven D'Aprano]

Uh, you don't talk often to non-programmers, do you?

Oh, if you only knew!

Talk a bit to
non-programmers about your programming habits, why you prefer which
programming language and so on. Everything in english. How much do
they understand?

That depends on how much jargon I use. Jargon, I should point out, is not
necessarily a pejorative term. It can just mean vocabulary used
only in a specialist field, and as such, jargon is very, very important.

Ever talked to skateboarders? Other people of different scenes? They
are creating new, specialized languages every day.

Yes, that's right. And if they insist on using their specialist language
where "that's bad" means "that is best quality", and I insist on using
my language where "that's bad" means "that is worst quality", how much
successful communication are we going to have?

Here in Germany a
study was published a little time ago, how few people understand
commercials and their slogans.

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

Do you know how many jokes work? Yes, by misunderstandings.

http://en.wikipedia.org/wiki/Humour

 

[philip.armitage]

And that is why I will never write Lisp. I loathe Emacs.

Me too. So if that's what's stopping you then you might be interested
to hear that when I moved my free time programming from Python to Lisp
it took only a weekend to learn enough of the language to code up a
little Lisp editor. It's funny that I was able to do this given what
I've now learned from this thread:

- Lisp is only used for research (but I'm not an academic)
- Lisp is hard to learn (because of all those parenthesis)
- There's no practical libraries available (so how did I do it so
fast?)

Phil

 

[Steven D'Aprano]

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

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

I don't expect that there are concepts that can't be expressed in English
(although some linguists disagree -- see the Sapir-Whorf hypothesis). But
there are many restrictions on *how* we express things. That means that
some concepts can't be expressed as briefly and succinctly in English as
in other languages (and, naturally, vice versa).

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

If we both agree that the rules of languages are social, then we
should both agree that in the case of programming language,
communities of language users help to constrain how the language is
used by rejecting extensions that are not lispy/pythonic, and
accepting extensions that converge with accepted style.

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

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

 

[Ken Tilton]

Me too. So if that's what's stopping you then you might be interested
to hear that when I moved my free time programming from Python to Lisp
it took only a weekend to learn enough of the language to code up a
little Lisp editor. It's funny that I was able to do this given what
I've now learned from this thread:

- Lisp is only used for research (but I'm not an academic)
- Lisp is hard to learn (because of all those parenthesis)
- There's no practical libraries available (so how did I do it so
fast?)

Our working hypothesis is "mutant strain". We'll need some DNA.

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