Questions about LISP and Python.

[Eduardo Costa]

I pose the questions below out of sheer curiosity, not to cause
outbursts of indignation. That said, here are my questions.

1 --- I noticed that many LISP programmers and universities are
switching to Python, even to teach AI. For instance, Norvig and the
people at MIT replaced Scheme with Python. My own experience with
Python was dismaying. The language is much slower than SBCL. There is
no tail call optimization. No macros. Then, my first question is ...
Why Python?

When I ask the why-Python question to Python programmers, they
complain about prefix notation. However, one can use Mark Kantrowitz's
infix.cl library to eliminate any inconvenience that prefix notation
could cause, and keep the advantages of prefix notation (for instance,
in genetic programming). I have even seen a couple of packages that
compile Python to Common Lisp, or Python to Scheme.

Many people express dissatisfaction about the size of SBCL core
files. However, Python interpreter is marginally larger than
sbcl.core. It is much larger than Clozure, Corman Lisp, etc. What MIT,
Norvig and many others gain in switching to Python? Am I missing
something?

2 --- Second question: I cannot see why Scheme cannot have
multidimensional arrays, like Common LISP. Of course, there is SFRI
25, but it is not as efficient as aref.

[Pascal J. Bourguignon]

Eduardo Costa <edu5...@gmail.com> writes:

> I pose the questions below out of sheer curiosity, not to cause
> outbursts of indignation. That said, here are my questions.
>
> 1 --- I noticed that many LISP programmers and universities are
> switching to Python, even to teach AI. For instance, Norvig and the
> people at MIT replaced Scheme with Python. My own experience with
> Python was dismaying. The language is much slower than SBCL. There is
> no tail call optimization. No macros. Then, my first question is ...

I doubt many lisp programmer are switching to python.

Norvig and university may, but they have their reasons (which are of no
concern to a lisp programmer).

> Why Python?

Popularity. You may choose your outfit browsing http://www.glamour.com,
or http://www.spacesuit.net/, but if you want to travel, the later might
be better even if the former is more popular.

> When I ask the why-Python question to Python programmers, they
> complain about prefix notation.

When you ask the why-English to English speaker, they complain about the
ideograms of Chinese.

> However, one can use Mark Kantrowitz's
> infix.cl library to eliminate any inconvenience that prefix notation
> could cause, and keep the advantages of prefix notation (for instance,
> in genetic programming). I have even seen a couple of packages that
> compile Python to Common Lisp, or Python to Scheme.
>
> Many people express dissatisfaction about the size of SBCL core
> files. However, Python interpreter is marginally larger than
> sbcl.core. It is much larger than Clozure, Corman Lisp, etc. What MIT,
> Norvig and many others gain in switching to Python?

More customers.


> Am I missing something?

Economics.

> 2 --- Second question: I cannot see why Scheme cannot have
> multidimensional arrays, like Common LISP. Of course, there is SFRI
> 25, but it is not as efficient as aref.

An implementation can implement directly and efficiently any SRFI.


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Tim Bradshaw]

Eduardo Costa <edu5...@gmail.com> wrote:

> What MIT,
> Norvig and many others gain in switching to Python? Am I missing
> something?

This question can perhaps be defused a bit by asking a related question:
why did many universities switch to teaching Java from <whatever> 10 years
ago or so, and in an overlapping timescale, why did they switch to teaching
C++ from <whatever>?

The answer isn't that Java is somehow much better than anything else as a
language – it's an OK language of its kind, but it's innovation was
managing to gain the traction it did (which is a significant feat, don't
get me wrong). The answer is that people want Java skills, and
universities are generally not brave enough to refuse to teach the skills
people think they want (though to at least some extent they should).

[Kaz Kylheku]

On 2011-12-04, Eduardo Costa <edu5...@gmail.com> wrote:
> sbcl.core. It is much larger than Clozure, Corman Lisp, etc. What MIT,
> Norvig and many others gain in switching to Python?

Python is adequate for teaching many concepts. Students who do coursework in
Python are far better served by their institution than if it required them to
work in, say, Java.

> Am I missing something?

Because Python is popular, it means that choosing Python for, say, teaching an
undergraduate CS program means that your decision is beyond reproach.

Whatever decision you make in that environment can be criticized from many
different angles by different people.

One way to make a decision is to optimize for least criticism by others,
whereby you enumerate all of the possible others, and given them some weight
based on their loudness, number, and influence on your career.

So, for instance, one possible criticism might be that students are walking
away with diplomas but not being able to quickly find jobs because they have
been doing coursework in an unpopular language.

Another criticism might be is that students are doing coursework in a toy
language, which holds back some areas of their development.

Between these two, which one will get more weight?

As an academic; you don't care. You just want to be left alone so you can lock
your office door and do your interesting research, and not think about
the undergrads or what they are working with.

[Pascal J. Bourguignon]

Kaz Kylheku <k...@kylheku.com> writes:

> On 2011-12-04, Eduardo Costa <edu5...@gmail.com> wrote:
>> sbcl.core. It is much larger than Clozure, Corman Lisp, etc. What MIT,
>> Norvig and many others gain in switching to Python?
>
> Python is adequate for teaching many concepts. Students who do coursework in
> Python are far better served by their institution than if it required them to
> work in, say, Java.

If you read the rational given by Sussman as to why MIT switched to
python for 6.001, I think the most striking point is that this course is
designed for a target audience of non-programmers.

For non-programmers, python is an OK programming language. Kind of the
BASIC of 2000.

But it is assumed that CS students will learn scheme (and sicp) after
that, and a lot of other programming languages, including assembler,
Common Lisp and Haskell.



So, asking that question in cll, is like going amongst the riders of the
Tour de France and asking what they think of training wheels.

[simplynitaai]

You can read here http://norvig.com/python-lisp.html why Peter Norvig
chose Python to teach AI.

Greetings, Matus

[Xah Lee]

On Dec 4, 11:01 am, Eduardo Costa <edu50...@gmail.com> wrote:
> I pose the questions below out of sheer curiosity, not to cause
> outbursts of indignation. That said, here are my questions.
>
> 1 --- I noticed that many LISP programmers and universities are
> switching to Python, even to teach AI. For instance, Norvig and the
> people at MIT replaced Scheme with Python. My own experience with
> Python was dismaying. The language is much slower than SBCL. There is
> no tail call optimization. No macros.  Then, my first question is ...
> Why Python?

because macros and tail call optimization is not really needed in
practice.

> When I ask the why-Python question to Python programmers, they
> complain about prefix notation. However, one can use Mark Kantrowitz's
> infix.cl library to eliminate any inconvenience that prefix notation
> could cause, and keep the advantages of prefix notation (for instance,
> in genetic programming).

don't call lisp syntax as “prefix”. Call it nested notation.

〈The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations〉
http://xahlee.org/UnixResource_dir/writ/notations.html

the lisp nested syntax has problems in so many ways. Alt package to
“fix” it only adds complication.

> I have even seen a couple of packages that
> compile Python to Common Lisp, or Python to Scheme.
>
> Many people express dissatisfaction  about the size of SBCL core
> files. However, Python interpreter is marginally larger than
> sbcl.core. It is much larger than Clozure, Corman Lisp, etc. What MIT,
> Norvig and many others gain in switching to Python? Am I missing
> something?

python has more readible syntax, more modern computer language
concepts, and more robust libraries. These qualities in turn made it
popular.

Xah

[Tim Bradshaw]

On 2011-12-05 11:51:11 +0000, Xah Lee said:

> python has more readible syntax, more modern computer language
> concepts, and more robust libraries. These qualities in turn made it
> popular.

Yet you still post here: why?

[Raymond Wiker]

Yikes. I've had Xah kill-filed for about 12-13 years, but every
now and then, I run across some quoted text from him.

3 statements, all of them wrong. This is about his usual batting
performance.

[fortunatus]

On Dec 5, 6:51 am, Xah Lee <xah...@gmail.com> wrote:
> because macros and tail call optimization is not really needed in
> practice.

I think you meant that they are not essential. None of the C code I
write has Lisp macros, proving they are not essential. But they sure
are nice. Languages should provide useful constructs. Macros of Lisp
capability are missing from Python and almost all other popular
languages. I consider it a shortcomming in the area of programming
languages. >>In practice<< I find a lot of use for Lisp macros.

I'll not register any formal complaints about missing tail recursion
optimization, though.

> don't call lisp syntax as “prefix”. Call it nested notation.

Of course it's prefix. It's fully parenthesised prefix. As we've
recently discussed, the parens help because it is not demanded in Lisp
that all functions be defined before referenced (question of operator
"arity"), and also there is the potential for variable length (and
variable structure) argument lists. Infix language structure needs
parens for the same reasons (the function calls are usually still
parenthesized prefix), plus to resolve order-of-evaluation questions
(precedence). The parens are a feature more than a burden if you have
a liking toward Lisp.

> the lisp nested syntax has problems in so many ways. Alt package to
> “fix” it only adds complication.

No argument there..

> python has more readible syntax, more modern computer language
> concepts, and more robust libraries. These qualities in turn made it
> popular.

Readable synax - matter of taste and care. I won't argue that point
either - all views end up valid in that discussion. Besides, I'm
quite willing to raise the point that Lisp's cost is verbosity.

Robust libraries - in terms of 90% of what's needed, I think that
there's a pile of CL libs that are easily available that are as robust
as Python libs. The last 10%, I'm not knowlegeable enough to comment
on. (For CL, you have to Google around, you need to look in more than
one place.)

More modern concepts - WHA??? Oh, parsing the source code? It is
true that Python's parser is more sophisticated - as are other
languages's parsers - I guess just to do away with parens where they
are not essential. Replace 'em with precedence. And indentation,
dots, semicolons, curly braces, stuff like that. After all, Lisp has
colons, backquotes, pound signs, etc. that the reader uses. But
there's another cost in those non-parenthesized languages besides
complexity in the parser - loss of the macro!! Loss of the reader!!
Loss of the REPL!! High costs indeed.

[fortunatus]

On Dec 5, 10:21 pm, fortunatus <daniel.elia...@excite.com> wrote:
> there's a pile of CL libs that are easily available that are as robust
> as Python libs.  The last 10%, I'm not knowlegeable enough to comment
> on.  (For CL, you have to Google around, you need to look in more than
> one place.)

Well, look. The whole GUI situation is an issue in CL. We all have
chosen some solution and made it work. With Python there're solutions
chosen for you pretty much. Open a book and it shows you how to make
a window. I'll deduct that from my "90% of what you want" figure.

That's not universal across Lisps. There are the commercial CL's with
windowing libs up & running. And there are other Lisp environments
like Racket. If you want text oriented windows there's Emacs Lisp.

[Xah Lee]

i don't like python, and i prefer emacs lisp. The primary reason is
that python is not functional, especially with python 3. The python
community is full of fanatics with their drivels. In that respect,
it's not unlike Common Lisp community and Scheme lisp community.

see also:

〈Python Documentation Problems〉
http://xahlee.org/perl-python/python_doc_index.html

〈Computer Language Design: What's List Comprehension and Why is It
Harmful?〉
http://xahlee.org/comp/list_comprehension.html

〈Lambda in Python 3000〉
http://xahlee.org/perl-python/python_3000.html

〈What Languages to Hate〉
http://xahlee.org/UnixResource_dir/writ/language_to_hate.html

〈Xah on Programing Languages〉
http://xahlee.org/Periodic_dosage_dir/comp_lang.html

Xah

[alex23]

On Dec 6, 2:36 pm, Xah Lee <xah...@gmail.com> wrote:
> The python community is full of fanatics with their drivels.

You do know that you could just fuck right off and leave us to it,
yes?

In general, it's the person who is shrilly imposing their minority
opinion on a disinterested audience that deserves the title 'fanatic'.

[Alex Mizrahi]

> i don't like python, and i prefer emacs lisp. The primary reason is
> that python is not functional, especially with python 3. The python
> community is full of fanatics with their drivels. In that respect,
> it's not unlike Common Lisp community and Scheme lisp community.

What functional programming features do you use, Xah? Last time I've
checked, you didn't care about closures. In this respect, Python is
better at functional programming than Emacs Lisp.

Do you just like writing arbitrarily long expression? Or you think that
eval is functional?

[Eduardo Costa]

> Tour de France and asking what they think
> of training wheels.

The training wheels make the point that Python lacks the speed
necessary for serious applications. On the other hand, Java and C#
demand huge downloads. As a user, I often give up an application when
I see the size of the downloads (dotNet framework plus the
application). I cannot understand why Python is so slow, and Java/
dotNet based software distributions require such huge downloads. SBCL
has a nice REPL with the looks and feel of interpreted code;
nevertheless it is fast. Why Python cannot be at least as fast as SBCL
or Clozure? I don't think that it has anything to do with syntax,
since I use an extended version of Katrowitz' infix.cl without
noticeable loss of speed.

I wonder whether clpython could be compiled in such a fashion as to
approach the speed of SBCL. It would be nice if its author could tell
us why is so difficult to bring clpython code closer to SBCL, in order
to obtain a net gain in speed. I performed a few tests, and clpython
is roughly as fast as CPython (or as slow, depending of the point of
view).

[Pascal J. Bourguignon]

What about losing the training wheels, and buying a race bicycle
instead?

Use Common Lisp!

[Alex Mizrahi]

> The training wheels make the point that Python lacks the speed
> necessary for serious applications. On the other hand, Java and C#
> demand huge downloads. As a user, I often give up an application when
> I see the size of the downloads (dotNet framework plus the
> application).

They do not demand huge downloads -- user can have .net or Java runtime
already installed. It is a matter of bundling your software.

I think it is typical for Java runtime to be installed separately, not
being bundled with software.

> I cannot understand why Python is so slow,

There are two reasons:

* it isn't designed for speed, unlike Common Lisp which took into
account decades of research (Python's author disregarded them for
simplicity)
* CPython is a slow interpreter, again built for simplicity

There are clever Python JIT compilers which make it much faster. E.g.
Psyco and PyPy.

> and Java/
> dotNet based software distributions require such huge downloads.

Again, it's not required.

> SBCL has a nice REPL with the looks and feel of interpreted code;
> nevertheless it is fast.

SBCL is slow at compiling and fastloading. Check CCL.

> Why Python cannot be at least as fast as SBCL
> or Clozure?

There is a number of reasons.

For example, Python name resolution requires hash table lookup at
runtime, e.g. when you call foo.bar it is a lookup in hash table foo for
symbol bar. In CL symbols are resolved at read time and further lookups
are just pointer dereferences.

Common Lisp has optional type annotations which enable type inferences.

There is a number of other things which are thought-out in CL but are
simplest in Python.

CL was made by top professionals when computers were slow. They simply
couldn't afford making it slow.

Python was made by one guy for purpose of teaching programming or
something. He simply wasn't giving a fuck.

But there are some black magic techniques to make Python faster.

> I don't think that it has anything to do with syntax,

Syntax too. CL has no syntax for namespace lookups in runtime.

But it's about semantics. CL has very straightforward execution model:

read -> macroexpand -> compile -> execute

Each step is separated. Spec describes with a great care what
implementation can and cannot do and it tries to leave absolute minimum
of work during execution.

> since I use an extended version of Katrowitz' infix.cl without
> noticeable loss of speed.

Sure, it has nothing to do with having prefix notation. I guess the main
reason lies in history: Lisp implementations were made in top
universities by top CS students, and hardware limitations made them want
to make them fast.

> I wonder whether clpython could be compiled in such a fashion as to
> approach the speed of SBCL.

I don't see how type annotations could fit into Python language so it
won't be as fast as SBCL. But probably still faster than CPython just
because certain things can be inlined and optimized out.

[Nomen Nescio]

> > I cannot understand why Python is so slow,

Then you're not ready to be a real programmer.

> SBCL is slow at compiling and fastloading. Check CCL.

Stalin is even slower at compiling but compiled code will execute faster.

> > Why Python cannot be at least as fast as SBCL
> > or Clozure?

Who said it can't? "Isn't" is not equal "can't"

> CL was made by top professionals when computers were slow. They simply
> couldn't afford making it slow.

Professionals?

[fortunatus]

On Dec 7, 9:27 am, Nomen Nescio <nob...@dizum.com> wrote:
> > CL was made by top professionals when computers were slow. They simply
> > couldn't afford making it slow.
>
> Professionals?

Not Professionals? Wasn't it professionals?

[Robert Brown]

Eduardo Costa <edu5...@gmail.com> writes:
> For instance, Norvig and the people at MIT replaced Scheme with
> Python.

Peter has not completely given up on Lisp. Some of the people he
manages are writing Common Lisp code.

bob

[Manlio Perillo]

Il Tue, 06 Dec 2011 18:40:03 -0800, Eduardo Costa ha scritto:

> [...]

> I cannot
> understand why Python is so slow,

Python is "slow" but that usually does not matter.
See SciPy as an example.

> and Java/ dotNet based software
> distributions require such huge downloads. SBCL has a nice REPL with the
> looks and feel of interpreted code; nevertheless it is fast. Why Python
> cannot be at least as fast as SBCL or Clozure?

Because Python is much more "dynamic" then Lisp.

> [...]

> I wonder whether clpython could be compiled in such a fashion as to
> approach the speed of SBCL. It would be nice if its author could tell us
> why is so difficult to bring clpython code closer to SBCL, in order to
> obtain a net gain in speed. I performed a few tests, and clpython is
> roughly as fast as CPython (or as slow, depending of the point of view).

See PyPy.


Regards Manlio

[Tim Bradshaw]

On 2011-12-08 21:48:33 +0000, Manlio Perillo said:

>
> Python is "slow" but that usually does not matter.
> See SciPy as an example.

> [...]

>
> Because Python is much more "dynamic" then Lisp.

With a little sed (are Lisp people allowed to admit to using sed?) one
could change this to be about another pair of languages, at another
time, but in the same newsgroup. The king is gone, but he's not
forgotten.

[Raymond Wiker]

Manlio Perillo <manlio_p...@SPAMlibero.it> writes:

> Il Tue, 06 Dec 2011 18:40:03 -0800, Eduardo Costa ha scritto:
>
>> [...]
>> I cannot
>> understand why Python is so slow,
>
> Python is "slow" but that usually does not matter.
> See SciPy as an example.
>
>> and Java/ dotNet based software
>> distributions require such huge downloads. SBCL has a nice REPL with the
>> looks and feel of interpreted code; nevertheless it is fast. Why Python
>> cannot be at least as fast as SBCL or Clozure?
>
> Because Python is much more "dynamic" then Lisp.

Bzzzt. Wrong.