merits of Lisp vs Python

[Paul Rubin]

Re: merits of Lisp vs Python

"Alex Mizrahi" <udodenko@users .sourceforge.ne twrites:

PRI don't see how to implement coroutines with CL macros. Maybe I'm
PRmissing something.
>
read the book.

Which book?

but once you convert it to CPS, you just operate with closures. stack is
just a lexical variables caught into closure.
do you know what does CPS mean at all??

I once understood the basic notion but confess to have never been
clear on the fine points. However, I don't see how you can do it with
CL closures since CL semantics do not guarantee tail recursion
optimization. If you code a loop with closures and CPS, you will blow
the stack.

[Kaz Kylheku]

Re: merits of Lisp vs Python

rurpy@yahoo.com wrote:

Well, having read a lot of this thread, I can see one of the
reasons why the software profession might want to avoid
lispies. With advocacy like this, who needs detractors?

And thus your plan for breaking into the software profession is ... to
develop Usenet advocacy skills.

``That guy we just interviewed, I don't know. Perfect score on the C++
test, lots of good architectural knowledge, but he seems to care more
about being correct than convincing people. He'd be fine for now, but
what does that say about his ability when the crunch comes, and he's
called upon to ... advocate?''

[Kaz Kylheku]

Re: merits of Lisp vs Python

Paul Rubin wrote:

"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

Right. What these have in common with Lisp is that they use manifest
typing, whereas Lisp uses latent typing. But after that, they mostly
diverge.

[Paddy]

Re: merits of Lisp vs Python


JShrager@gmail. com wrote:

Python has to rely more on using the right algorithm...

>
This sound familiar: "Macros are dangerous!"

Yes. I changed my opinion on advocating Python having macros in one
of our long threads on the subject. Maintainance counts.

"Compilers make you lazy."

This is new to me. In fact, for the compiled languages available to me.
Using them *first* would be the difficult choice.

"Worse is better!"

Yep, I think I read that one. To (over), summarise what I read: the
author
states that waiting for perfect will often give the advantage to a
competitor who ships with 'good enough'. The author gives examples.
The skill to me resides in knowing what is good enough ;-)

(I have a Russian friend -- a mathematician -- who
jokes that the reason the Soviets were great mathematicians because
their computers sucked, so they had to use extensive formal
manipulation to get things to run fast enough to get anything done. He
was joking (I think); you don't appear to be.)

I can't vouch for your Russian friend, but yes I do think that the
gumph on
exponential time algorithms versus linear time algorithms makes sense.
I started using my first scripting language AWK whilst using C and went
through only using it for small tasks to using it for more and more
because it was fast enough. In my case I'd be finishing some task in
a much shoter time giving my customers solutions that might take 10
minutes to run instead of ten seconds, but they were using it in a flow
that took maybe overnight to run.
Unlike Lisp, Python does not have a ubiquitous compiler. It is
therefore
made to interface nicely with compiled languages. Other compiled
language users see the need for dynamic interpreted languages like
Python and maintain links Python such as the Boost Python C++
wrapper. IronPython for .NET, Jython for Java.
Lisp is its own interpreter and compiler, which should be a great
advantage, but only if you don't make the mistake of ignoring the
wealth of code out there that is written in other languages.

>

Talk to these guys:
http://en.wikipedia.org/wiki/PyPy they have an interesting take on

>
No, actually maybe you should talk to them since you seem to think that
making Python run fast is dangerous, or at least unnecessary.
>

Python has this unsung module called doctest that neatly shows some of
the strengths of python: http://en.wikipedia.org/wiki/Doctest

>
Now I'm *certain* that you're just pulling my leg: You guys document
all your random ten-line hacks in Wikipedia?!?! What a brilliant idea!

Python is newbie-friendly. Part of that is being accessible.
Doctest is about a novel way of using a feature shared by Lisp, that is
docstrings. Testing is important, usually not done enough, and doctests
are a way to get people to write more tests by making it easier. Does
Lisp have similar?

Hey, you even have dead vaporware projects like uuu documented in
Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in
Python, but it'd be about ten lines of Lisp, if that, so I'm just
guessing here.)

Does Lisp have a doctest-like module as part of its standard
distribution?
Or are you saying that If you ever needed it, then it would be trivial
to
implement in Lisp, and you would 'roll your own'? There are advantages
to
doctest being one of Pythons standard modules.

- Paddy.

[Kay Schluehr]

Re: merits of Lisp vs Python

dixkey@gmail.co m schrieb:

I find it amusing that most of the arguments that python-people are
making in this thread are actually the arguments that C++ and Java make
against Python. "Who needs dynamic typing?", "Who needs closures?",
"The idea of using whitespace for syntax is beyond stupid"... Now the
python guys obviouly see that that those arguments are bogus, but they
keep the same reasoning against lisp.

Yes, this structure of argument is the same in *any* discussion about
language design and feature integration. The solution could be laissez
faire but then you have to counteract creating standards for a minimal
contract social. In either way you cut down language feature diversity
and feature implementation redundancy, something macros strongly
encourage. So Lisp is always the right language to start with but what
is the right language to end with? The answer is BASIC and although the
reference to the historical BASIC language is not accidental, I
actually mean all kind of general purpose languages that aim to
facilitate programming in the first place. That's why Python = BASIC or
more accurately Python = ABC. Of course you can start with BASIC too,
instead of Lisp, or Ruby and quote Yukihiro Matsumoto who just wants
happy users - from the very beginning and not just after one month,
when one starts looking through the jungle of parens ( Ken Tilton ) or
perform any other cognitive transformation to ease the pain.

While Pythonistas might defend their language with all kind of typical
nerdish idiocy, Lispers try to convince Pythonistas to be unhappy,
because they lack X, Y and Z and recommend Lisp as the cure. But just
like a beautifull woman, Pythonistas stay unimpressed and do respond:
no, I don't lack anything, I am complete; stay away from me with your
weirdness!

[Kaz Kylheku]

Re: merits of Lisp vs Python

Paddy wrote:

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

I pity the hoplelessly anti-intellectual douche-bag who inflicted this
undergraduate misfeature upon the programming language.

This must be some unofficial patch that still has a hope of being shot
down in flames, right?

[Ravi Teja]

Re: merits of Lisp vs Python


Kaz Kylheku wrote:

Paddy wrote:

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

>
I pity the hoplelessly anti-intellectual douche-bag who inflicted this
undergraduate misfeature upon the programming language.
>
This must be some unofficial patch that still has a hope of being shot
down in flames, right?

Sour grapes. Eh :-)
Or were you going to follow up with some intellectual argument to
support your adjectives?

1. pity
2. hopelessly
3. anti-intellectual
4. douche-bag
5. inflicted
6. undergraduate
7. misfeature
8. unofficial patch
9. shot down in flames

That's a lot of hate in 2 sentences for judging a novel feature you
barely came across.

[Juan R.]

Re: merits of Lisp vs Python


philip.armitage @gmail.com ha escrito:

- Lisp is hard to learn (because of all those parenthesis)

I cannot understand why. It is like if you claim that packaging things
in boxes is difficult to learn.

HTML and XML have more brackets than LISP (usually double) for
structuring data and everyone has learned HTML.

[Kaz Kylheku]

Re: merits of Lisp vs Python

Paddy wrote:

Does Lisp have a doctest-like module as part of its standard
distribution?

No, and it never will.

The wording you are using betrays cluelessness. Lisp is an ANSI
standard language. Its distribution is a stack of paper.

There isn't a ``standard distribution'' of Lisp any more than there is
such a thing of C++.

There are advantages to
doctest being one of Pythons standard modules.

There are also advantages in being able to tell idiots who have
terrible language extension ideas that they can simply roll their own
crap---and kindly keep it from spreading.

This is generally what happens in intelligent, mature programming
language communities. For instance, whenever someone comes along who
thinks he has a great idea for the C programming language, the standar
answer is: Wonderful! Implement the feature into a major compiler like
GCC, to show that it's feasible. Gain some experience with it in some
community of users, work out any wrinkles, and then come back.

In the Lisp community, we can do one better than that by saying: Your
feature can be easily implemented in Lisp and loaded by whoever wants
to use it. So, i.e. don't bother.

Lisp disarms the nutjobs who want to inflict harm on the world by
fancying themselves as programming language designers. They are reduced
to the same humble level as other software developers, because the best
they can do is write something which is just optionally loaded like any
other module, and easily altered beyond their original design or
rejected entirely. Those who are not happy with the lack of worship run
off an invent shitty little languages for hordes of newbies, being
careful that in the designs of those languages, they don't introduce
anything from Lisp which would land them in the same predicament from
which they escaped.

[Tim Peters]

Re: merits of Lisp vs Python

[Paddy]

> http://en.wikipedia.org/wiki/Doctest

[Kaz Kylheku]

I pity the hoplelessly anti-intellectual douche-bag who inflicted this
undergraduate misfeature upon the programming language.

As a blind misshapen dwarf, I get far too much pity as it is, but I
appreciate your willingness to share yours. If you like, feel free to
give this precious gift to another. I get the impression that pity is
something you don't feel often, and it would be a shame to waste it.

This must be some unofficial patch that still has a hope of being shot
down in flames, right?

Alas, no. It was secretly snuck into Python's standard library in the
2.1 release (2001), and although we've done our best to hide it, it's
widely used now. Strangely enough, it's especially popular among
intellectuals ;-)

[Timofei Shatrov]

Re: merits of Lisp vs Python

On 11 Dec 2006 00:27:28 -0800, "Ravi Teja" <webraviteja@gm ail.comtried to
confuse everyone with this message:

>
>That's a lot of hate in 2 sentences for judging a novel feature you
>barely came across.
>

But, you have to admit that it looks horrible (at least at the first glance). If
there's some programming style that I absolutely can't stand, it would be the
one where programmer writes a huge block of commentary describing what a
function does, followed by one-liner of code, which contains the same amount of
information in itself. With doctest it is even worse, because examples also
contain superfluous information. Everyone can just copy-paste the code in REPL
and see what happens when you execute it. Besides that, there are many reasons
why tests should be stored in a separate file, or at least not in the same
function that they are testing.

Also Wikipedia article contains some "Cons of doctest" that look pretty nasty:

* Large numbers of tests in a docstring can become unwieldy. docstrings
should be pruned and excised tests put in external file(s).
* Tests producing large amounts of output make for large docstrings.
* Debugging integration is far from perfect
* 'print' (or 'trace') debugging is not possible (because it intervenes with
the test result)
* Test setup has to be either copied or hidden away from the test, making
the overall environment harder to understand.
* Many of the complex assertions of existing unit tests frameworks do not
exist, (e.g. assertRaises, assertEquals, assertAlmostEqu al, ...), although some
are not necessary.
* Failing assertions are very hard to debug (Especially in Web applications
if the expected result is a web page with a lot of HTML)

It's not surprising that no one uses this stuff for serious work.

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________ |

[Michele Simionato]

Re: merits of Lisp vs Python

Timofei Shatrov wrote:

It's not surprising that no one uses this stuff for serious work.

Well, I replaced all my unittests with doctests long ago, and I am not
the only one following this way
(see the Zope 3 project for instance).

Michele Simionato

[greg]

Re: merits of Lisp vs Python

JShrager@gmail. com wrote:

compilers are GREATLY facilitated by having a
macro facility because (at first blush) all you need to do is to
macro-expand down to something you know how to turn into code.

There's no way you could compile Python to efficient
machine code just by macro expansion. You'd also need
some very heavy-duty type inferencing.

Python is extremely dynamic, even more so than Lisp.
That's why compiling Python is hard, not because it
doesn't have macros.

--
Greg

[greg]

Re: merits of Lisp vs Python

Ken Tilton wrote:

But with Lisp one does not have to clean up the indentation manually
after thrashing away at ones code.

That's not how I would describe the experience
I have when I'm editing Python code.

When moving a set of statements in Python, you
are usually selecting a set of complete lines,
cutting them out and then pasting them in
between two other lines somewhere else.

Having done that, the lines you've just pasted
in are selected. Now it's just a matter of
using using your editor's block-shifting commands
to move them left or right until they're in
the correct horizontal position.

I find this to be quite a smooth and natural
process -- no "thrashing" involved at all.

Having edited both Lisp and Python code fairly
extensively, I can't say that I find editing
Python code to be any more difficult or error
prone.

On the plus side, Python makes less demands on the
capabilities of the editor. All you really need
is block-shifting commands. Bracket matching is
handy for expressions but not vital, and you
certainly don't need bracket-based auto-indenting.

--
Greg

[Ravi Teja]

Re: merits of Lisp vs Python


Timofei Shatrov wrote:

But, you have to admit that it looks horrible (at least at the first glance). If
there's some programming style that I absolutely can't stand, it would be the
one where programmer writes a huge block of commentary describing what a
function does, followed by one-liner of code

You Sir, are no fan of Literate Programming :-).

information in itself. With doctest it is even worse, because examples also
contain superfluous information. Everyone can just copy-paste the code in REPL
and see what happens when you execute it.

And doctest automates such REPL tests. Like macros, don't knock it till
you try it.

Besides that, there are many reasons
why tests should be stored in a separate file, or at least not in the same
function that they are testing.

You need not have doctest as a part of source code. You can also create
a separate documentation file that contains prose as well as tests
intervening.

http://www.python.org/doc/lib/doctest-simple-testfile.html

Combine it with ReStructured Text and you have a wonderful
documentation and testing solution in one place. Personally, I like
this a lot better than Javadoc style documentation where usage examples
are often absent.

Also Wikipedia article contains some "Cons of doctest" that look pretty nasty:

Of course, doctest is hardly the ultimate testing solution. But it does
an admirable job for many cases where you don't need to setup elaborate
tests.

It's not surprising that no one uses this stuff for serious work.

I have seen enough libraries that use doctest. Zope, Twisted and Paste
are some of the popular Python projects in that use it. Epydoc supports
it as well.