merits of Lisp vs Python

[tim.peters]

[Bill Atkins]
[Kaz Kylheku]

Because that's what they are often called outside of the various
literate fields.

For example, the English are "outside of the various literate fields"?

FWIW, Python documentation consistently uses the jargon:

() parentheses
{} braces
[] brackets

That matches North American conventions, but occasionally confuses an
international audience (for example, the English call parentheses
"brackets" or "round brackets").

There's also a long tradition in both mathematics and computer science
of using "bracket" as a generic term for any syntactic device used in
pairs. For example, the "Revised Report on the Algorithmic Language
Algol 60" way back in 1963 even called "begin" and "end" brackets. If
it's tempting to call the authors of that illiterate too, keep in mind
that John McCarthy was one of them -- although I'm sure Peter Naur
would be willing to take the blame for dumbing it down for Europeans ;-)

 

[Timofei Shatrov]

There are a lot of people that use Wikipedia. I think some of them
might want to learn to program.

I think you misunderstood the goal of Wikipedia. It is not to teach people
programming.

I make it easier for them to find
Python by helping to maintain Python within Wikipedia.

If someone wants to find Python, he types "Python" in the search bar and works
from there. He certainly wouldn't end up in "doctest" article.

Some people dislike Wikipedia which is fine. Some people dislike
Wikipedia and deliberately sabotage it, which is vandalism.

Writing vanity articles about non-notable things is not much better.

 

[Juan R.]

greg ha escrito:

There's nothing static about it:

q = raw_input()
if q == "A":
a = 1
b = 2
else:
a = "x"
b = "y"
c = a + b

There is no way that the compiler can statically
determine what the + operator needs to do here.

Before or after the input? :]

No, it is not that i did mean. Of course, the operation for c is
dinamic, but just statically overloading the +. The definition for c
could be adapted to the cases and introduced on the if.

I would call dinamic code, for instance, if the if, the different cases
and the def for c could be modified on the fly _á la_ LISP macro style.

 

[Christophe]

Robert Uhl a écrit :

The argument from popularity is invalid. French units have overtaken
standard units,

Never heard of that French unit thing. Unless you talk about that
archaic unit system that was in use before the metric system was created.

 

[Jan Dries]

Robert Uhl a écrit :
Never heard of that French unit thing. Unless you talk about that
archaic unit system that was in use before the metric system was created.

And who do you think created the metric system?

Regards,
Jan

 

[Rob Warnock]

Raffael Cavallaro <raffaelcavallaro@pas-d'espam-s'il-vous-plait-mac.com>:
+---------------
| "George Sakkis" <[email protected]> said:
| > If you mistakenly select an extra parenthesis or omit one, it's
| > the same thing.
|
| Because you can't mistakenly select an extra paren or omit one in a
| lisp-aware editor. Whether its a commercial lisp IDE or emacs, you
| don't manually select s-expressions. You put your cursor/point at one
| paren and you tell the editor - with a keystroke or a mouse click - to
| find the matching paren and select everything contained between the two.
+---------------

And for any of you who are rejecting this because you don't want to
learn or use Emacs, Raffael's point is even true in the Vi family of
editors ("nvi" & "vim", at least). The "y%" command yanks (copies)
everything through the matching paren into the anonymous buffer;
"d%" deletes likewise [and saves in the anonymous buffer]; "p" (or "P")
pastes after (or before) the current location. All can be prefixed
with a buffer ("Q-register") name for more flexibility.

Lisp's parens really *do* make editing ever so much easier!


-Rob

 

[Paddy]

I think you misunderstood the goal of Wikipedia. It is not to teach people
programming.

You think wrong. Wikipedia articles get searched and links get
followed. Its good
for some of those to link to articles on Python.

If someone wants to find Python, he types "Python" in the search bar and works
from there. He certainly wouldn't end up in "doctest" article.

If someone is looking up comments or testing, then they might well end
up reading
the doctest article. And why not!

Does Lisp have similar?
Is the Lisp community as welcoming?
Do you have to think yourself a genius to join the club?
Is Lisp approachable?

Writing vanity articles about non-notable things is not much better.

Should I have asked you first ;-)
- Paddy.

 

[Slawomir Nowaczyk]

On Wed, 13 Dec 2006 02:41:29 -0500

#> On 2006-12-12 19:18:10 -0500, "George Sakkis" <[email protected]> said:
#>
#> > If you mistakenly select an extra parenthesis or omit one, it's
#> > the same thing.
#>
#> Because you can't mistakenly select an extra paren or omit one in a
#> lisp-aware editor.

Sure I can! I think you misunderstood what George said.

(unless (eq 1 2) (if (eql 2 3) (x)) (y))

How is the editor supposed to know whether I want to cut/paste the
s-expression starting with "if" or the one with "eql"?

#> Whether its a commercial lisp IDE or emacs, you don't manually select
#> s-expressions. You put your cursor/point at one paren and you tell
#> the editor - with a keystroke or a mouse click - to find the matching
#> paren and select everything contained between the two.

Oh, you mean you have never seen a Python environment which could mark
the current block of code?

--
Best wishes,
Slawomir Nowaczyk
( (e-mail address removed) )

Truth is stranger than fiction, because fiction has to make sense.

 

[Juan R.]

(e-mail address removed) ha escrito:

FWIW, Python documentation consistently uses the jargon:

() parentheses
{} braces
[] brackets

That matches North American conventions, but occasionally confuses an
international audience (for example, the English call parentheses
"brackets" or "round brackets").

There's also a long tradition in both mathematics and computer science
of using "bracket" as a generic term for any syntactic device used in
pairs.

Brackets are unequal paired syntatic delimiters used for packaging.
Quotations marks "string" or exclamation marks ¡Esto es español! are
used in pairs but not are brackets.

A natural convention is brackets = ( ), [ ], { }, < >

( ) parentheses or round brackets
{ } braces or curly brackets
[ ] box or square brackets
< > chevrons or angle brackets

A English calling "brackets" or "round brackets" to the parentheses is
doing nothing wrong, but brackets are not parentheses.

In mathematics the braces are also often called brackets and again that
is not wrong.

 

[Kay Schluehr]

Not familiarized with you terminology. I think that i would call that a
universal language composer.

I mean if there exists some theoretical limitation to composionality of
two directly collapsing languages (G1, T1) and (G2, T2) via a
unambiguous modification (e.g. 'renaming') to a third one (G2', T2'),
unknown to me. I mean some theoretical limitation in the sense of known
theoretical limitations to proving theorems in closed formal systems.
After all proving a formal theorem is not very different from
enhacement of a language.

But proving the theorem might be trivial and the implementation
useless. It's like saying you want "universal composition" of two
geometric objects e.g. two manifolds M1, M2 and I write down M3 = M1 x
M2. This is always feasible but this is just not the right kind of
thing in many occasions.

I want to give a practical example. The Python grammar defines a
compound_stmt rule by:

compound_stmt: for_stmt | while_stmt | if_stmt | ...

Now you might add a switch_stmt to G1 and a repeat_stmt to G2

G1: compound_stmt: for_stmt | while_stmt | if_stmt | switch_stmt |...
G2: compound_stmt: for_stmt | while_stmt | if_stmt | repeat_stmt |...

What you actually want in G3 is

G3: compound_stmt: for_stmt | while_stmt | if_stmt | switch_stmt |
repeat_stmt |...

You don't want to rename each statement and mangle each terminal of G2
although this might always be possible. Renaming also negatively
affects the transformer of G2 which precedes composition and is encoded
as Python source. It has to be refactored too when you rename a rule.

So one requirement on a system of composition rules is to drop alpha
conversion which is just a last resort. I guess in any *reasonable*
system of composition rules the question whether G1 and G2 are
composable is decidable and this can also be proofed at least for
certain classes of grammars that are not Turing complete languages by
themselves.

I would consider redefined-L0 to be L0'. I think that a concept of
namespaces could be also used for versioning-like conflicts:
L0v24:foo(), L0v25:foo(). The problem is that both versions may be
stored and managed during initial period of time. But in the long run
old libraries, extensions... would be updated to the new version.

Sure, but it's preferable to see how far one gets without name mangling
and other crutches.

 

[Rob Warnock]

+---------------
| CLTL2 is a model of precision and thoroughness compared
| with any document that's ever been written about Python.
+---------------

It's a great book, but one needs to be clear that CLtL2 is *not*
the same as the ANSI Common Lisp standard, but was the author's
best guess at the time as to where the standardization effort was
going after CLtL1. You may find the following useful in marking up
your copy of CLtL2 to be closer to the final standard:

http://cbbrowne.com/info/commonlisp.html#AEN10499
http://bc.tech.coop/cltl2-ansi.htm

But note the caveat therein:

A doctored CLTL2 is NOT the ANSI standard. In fact,
this FAQ has many known but minor omissions that are
too awkward to add with pencil to CLTL2.

The Common Lisp HyperSpec (CLHS), while also not the official
ANSI standard per se, was created from "the same" TeX input as
the ANSI standard (with permission from ANSI & X3), and is the
reference most CL programmers use:

http://www.lisp.org/HyperSpec/FrontMatter/index.html
http://www.lispworks.com/documentation/HyperSpec/Front/index.htm

For a downloadable tarball of the whole thing, there's a link near
the bottom of this page:

http://www.lispworks.com/documentation/HyperSpec/index.html


-Rob

 

[Pascal Bourguignon]

Robert Uhl a écrit :
Never heard of that French unit thing. Unless you talk about that
archaic unit system that was in use before the metric system was
created.

Who invented the metric system?

 

[Christophe]

(e-mail address removed) a écrit :

Try reading again. In Lisp, you use () and *your editor* automatically
indents according to the universal standard, or you leave it sloppy
until other folks reading your code convince you to get a proper
programming editor. Indentation does not get out of sync with semantics
because the editor virtually never misses parentheses that the Lisp
compiler sees. Expressions keep the same meaning even if you have to
start breaking them across lines, etc.

In Python, you group in your mind, and press indentation keys to make
it happen in your editor. The editor cannot help that much, because it
cannot read your mind. White space screwups in copy-paste cannot be
fixed by the editor automatically, because it cannot read the original
programmer's mind, and you have to fix it manually, and risk screwing
it up.

Call us when you have an editor that reads your mind and writes the ()
for you.

 

[hit_the_lights]

No, it's not as ubiquitious as in Python. I guess that has many
different reasons, probably many historical. IIRC Peter Seibel
writes in Practical Common Lisp that CLOS (and thus "defgeneric")
was introduced late in the CL standardization process. That my be
one reason why it is not used extensively by the rest of the
standardized language.

It's a little more complicated than that, the classes involved have to
have special interfaces to tell setf/getf what to do, sort of a
compile time equivalent of __setattr__/__getattr__ if I remember right.

The code I've posted is all you need. You can specialize it for any
class (including numbers, functions, symbols etc.) you like.

In case of the lookup "($ a 0)" there is nothing done at compile
time, it's just a call of the generic function "$".

"(setf ($ a 0) 1)" is translated at compile time (setf is a macro)
to something like "(funcall #'(setf $) 1 a 0)".

 

[John Thingstad]

Not even close.

In my example above:
for a in y:
dosomethingwith(a)
y could be a lot of built-in types such as an array, list, tuple, dict,
file, or set.
- Paddy.

I was refering to the recursive Lisp example.
Did you even read the post?

 

[John Thingstad]

I think you misunderstood the goal of Wikipedia. It is not to teach
people
programming.


If someone wants to find Python, he types "Python" in the search bar and
works
from there. He certainly wouldn't end up in "doctest" article.


Writing vanity articles about non-notable things is not much better.

You are being silly. Wikipedia has for instance the best coverage of math
of any encyclopedia (if you can call it that). This is how I came in touch
with it. If you want trivia you get trivia. If you want Phd. level math it
has that as well. It is as diverse as the people that use it.

 

[Christophe]

Pascal Bourguignon a écrit :

Who invented the metric system?

That system is called the metric system, not French units. French units
refer to the archaic system used before the metric system was invented (
at least according to google )

So, let's admit that French Units refer to the metric system. I suppose
then that the so called "standard" units refer to the imperial system.

Saying that the French units are technically worse than standard units
is a troll of very poor quality and a very weak argument.

 

[Rob Warnock]

+---------------
| > I have the code here (probably not the latest bcs I left the company
| > when it was acquired), let's do a little experiment, for what it's
| > worth: 89727 lines of Lisp code in 131 modules (lisp code files), 3306
| > "(defun" (by grep|wc), and 261 "(defmacro". [We did NOT use macros as
| > functions!] [Note that lines of code doesn't really matter in Lisp.]
|
| Wow--my emacs install has 1,152,598 lines of code in 1,570 files,
| 29,244 defuns and 1,393 defmacros.
+---------------

Wow, indeed! The entire CMUCL-19c distribution is "only" 592081 lines
of source code in 1192 files, with 10699 DEFUNs and 1839 DEFMACROs.
I didn't realize CMUCL was so "small" compared to Emacs. ;-}

[Of course, that doesn't include the number of DEFUNs & DEFMACROs
which are defined *by* macros, or the total of 2809 DEFINE-VOPs
in the various flavors of the compiler...]


-Rob

 

[greg]

Are you aware that you hardly know any Lisp yet make such bold and unfounded
claims? Unless interning a string somehow gives it a property list, slot value
and function value it doesn't give you the same capabilities.

I'm talking about the capability of comparing symbols
efficiently by address, which Robert seemed to think
that Python couldn't do. I was pointing out that it
can, despite not having a distinct symbol type.

I know about property lists. The Pythonic way to do
the equivalent thing is using a dictionary.

I also know about the dual function/other value of
a symbol, which has alway seemed like an idiotic
feature to me. All it seems to do is make it more
awkward than necessary to deal with functions as
first class objects, which is supposedly meant to
be one of Lisp's strengths. So I regard it as a
feature that Python *doesn't* have this.

 

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

Don't expect to learn Prolog properly in so little time. To your
previous question whether the ~180 lines of Lisp code in some online
book constitute an "industrial strength" Prolog: only if the following
~180 lines of Prolog code implement an "industrial strength" Lisp.

Hallo, you are of course right. There are some prolog implementations
for Lisp that implement some parts of Prolog. To get the full thing one
would of course need a big lot more of work.
The idea is to get the basic constructs of Prolog available for Lisp.
And with 2k LOC there are already some nice things that one can do.
Those who know the paradigm of logical programming can recognize that
a problem falls into this domain and then use inside of Lisp some tools
that allow to express the problem in this domain specific language.

If one really wants/needs Prolog then one should use it
The Prolog implementations are much more efficient and very stable.
But often even 60% of Prolog are so expressive, that it can be a real
productivity booster.


André
--