merits of Lisp vs Python

[josephoswaldgg@hotmail.com]

Re: merits of Lisp vs Python


Anders J. Munch wrote:

jayessay wrote:

Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.

>
Really? So how do you write a portable program in CL, that is to run
for unbounded lengths of time?
>
- Anders

Write it, and depend on the implementation to do its job well, and
complain to the implementors if it doesn't.

How do you write a portable program in C that is to run for unbounded
lengths of time? Even if you religiously call free() on every
malloc()'d block, you could eventually fragment memory enough that the
allocator might eventually fail. You can exceed the VM capacity. The OS
could decide to crash periodically. The power supply could fail, the
sun could progress to the red giant phase...

The real answer is that these are not issues for the language
definition, but for the implementor.

[Pascal Bourguignon]

Re: merits of Lisp vs Python

"Rob Thorpe" <rthorpe@realwo rldtech.comwrit es:

Anders J. Munch wrote:

>jayessay wrote:

> Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.

>>
>Really? So how do you write a portable program in CL, that is to run
>for unbounded lengths of time?

>
You can't.

You can. Just use reversible operations.

Or use pre-allocated objects. Yes, that means that you implement your
own memory management or garbage collector, but this would be portable.

--
__Pascal Bourguignon__ http://www.informatimago.com/

"Do not adjust your mind, there is a fault in reality"
-- on a wall many years ago in Oxford.

[Rob Thorpe]

Re: merits of Lisp vs Python

Pascal Bourguignon wrote:

"Rob Thorpe" <rthorpe@realwo rldtech.comwrit es:

Anders J. Munch wrote:

jayessay wrote:
Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.
>
Really? So how do you write a portable program in CL, that is to run
for unbounded lengths of time?

You can't.

>
You can. Just use reversible operations.
>
Or use pre-allocated objects. Yes, that means that you implement your
own memory management or garbage collector, but this would be portable.

I don't think there is any gaurantee in the spec that says that even
doing nothing at all doesn't allocate more memory. AFAIK a conforming
implementation could leak a fixed amount of memory per second.

[Anders J. Munch]

Re: merits of Lisp vs Python

Rob Thorpe wrote:

Anders J. Munch wrote:

>Really? So how do you write a portable program in CL, that is to
>run for unbounded lengths of time?

>
You can't.
>
The thing about the spec not defining GC is almost a bit of humour.
No-one would use an implementation with no GC.
>
The issue with specifying it is: How would you do it? The memory
used by a program is an aspect of the language implementation and
the system the program is running on, so how can it be defined in a
useful way?

Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.

Require that u(t) is a member of O(t -max{t'<=t: r(t')})

There. That wasn't so hard, was it?

- Anders

[Rob Thorpe]

Re: merits of Lisp vs Python

Anders J. Munch wrote:

Rob Thorpe wrote:

Anders J. Munch wrote:

>Really? So how do you write a portable program in CL, that is to
>run for unbounded lengths of time?

>
You can't.
>
The thing about the spec not defining GC is almost a bit of humour.
No-one would use an implementation with no GC.
>
The issue with specifying it is: How would you do it? The memory
used by a program is an aspect of the language implementation and
the system the program is running on, so how can it be defined in a
useful way?

>
Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.
>
Require that u(t) is a member of O(t -max{t'<=t: r(t')})
>
There. That wasn't so hard, was it?

That's quite a clever definition actually.
But, let's say I have a lisp machine. It has an unusual architecture,
it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
used as storage, sometimes their contents represent logic circuits and
the routing between them is configured to form them into a processor.
Please tell me what reachable memory is ;). (The above processor is
not science fiction, it could easily be done with FPGAs)

I suppose a solution would be:-

If the lisp implementation runs on a fixed processor that has separate
storage then ...

Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.
....

[jayessay]

Re: merits of Lisp vs Python

"Anders J. Munch" <2006@jmunch.dk writes:

jayessay wrote:

Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.

>
Really?

Really.

So how do you write a portable program in CL, that is to run
for unbounded lengths of time?

Make it non-consing (like for any such program in any language). Of
course, this won't guarantee success as the implementation or OS or
.... may leak or other wise cons memory even if your program doesn't.


I'm surprised there are people out there that find this interesting
let alone surprising.


/Jon

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

[Ken Tilton]

Re: merits of Lisp vs Python



JShrager@gmail. com wrote:

Come on; you guys can't just leave this at 999 posts!
>

Funny you should whine, i was just getting ready to sign off with:

I noticed while singing the praises of auto-indentation that there was a
shortcoming in The Greatest Feature Known to Editing source code, which
is the ability to copy an arbitrary block of code (say, a case statement
in the else branch of an if statement in a loop) with a single
control-click of the mouse, viz, that I still had to reindent if it was
a multiline statement. The first line of course landed exactly where I
clicked so that was fine, but other lines in the block were retaining
the indentation extant at the time of the click.

A few glasses of...<cougha few hours ago I dashed off an RFE to Franz
tech support apologizing for a trivial matter but wondering if it might
not be just a line or two, and lawdy-it-must-be-xmas a glass later back
came a patch I am just wallowing in.

interestingly, the techie happens not to have been a user of
control-click, probably a hardcore keyboard guy who never touches the
mouse. I started programming GUIs on a Mac 512, didn't /have/ a keyboard.***

And now the punch line: spare me the "oh gosh reindentation is so easy"
dodge. So is a manual control-shift-p to auto-reindent after an ungainly
paste, but this is definitely one of those deals where we don't notice
until we stop hitting ourselves with that hammer.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

BLISS programs Just Work.
Never revisited, they
Never get refined.
- Warnock's Explanation of Large Programs

[Anders J. Munch]

Re: merits of Lisp vs Python

Rob Thorpe wrote:

Anders J. Munch wrote:

>Let u(t) be the actual memory used by the program at time t.
>Let r(t) be the size of reachable memory at time t.
>>
>Require that u(t) is a member of O(t -max{t'<=t: r(t')})
>>
>There. That wasn't so hard, was it?

>
That's quite a clever definition actually.
But, let's say I have a lisp machine. It has an unusual architecture,
it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
used as storage, sometimes their contents represent logic circuits and
the routing between them is configured to form them into a processor.
Please tell me what reachable memory is ;). (The above processor is
not science fiction, it could easily be done with FPGAs)

Reachable memory is the set of interpreter objects (conses, closures, scopes,
atoms and what have you) reachable from from some appropriately defined root
set. It can be unambiguously defined with respect to a virtual machine, with no
regard to how actual implementations represent these things.

For actual memory use, a simple byte count would do fine. If code and data are
intermingled, just use the combined size of both of them.

If you're worried about comparing incompatible units, don't be: apples and
oranges compare just fine under big-Oh.

- Anders

[Rob Thorpe]

Re: merits of Lisp vs Python

Anders J. Munch wrote:

Rob Thorpe wrote:

Anders J. Munch wrote:

Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.
>
Require that u(t) is a member of O(t -max{t'<=t: r(t')})
>
There. That wasn't so hard, was it?

That's quite a clever definition actually.
But, let's say I have a lisp machine. It has an unusual architecture,
it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
used as storage, sometimes their contents represent logic circuits and
the routing between them is configured to form them into a processor.
Please tell me what reachable memory is ;). (The above processor is
not science fiction, it could easily be done with FPGAs)

>
Reachable memory is the set of interpreter objects (conses, closures, scopes,
atoms and what have you) reachable from from some appropriately defined root
set. It can be unambiguously defined with respect to a virtual machine, with no
regard to how actual implementations represent these things.

Yes.

For actual memory use, a simple byte count would do fine. If code and data are
intermingled, just use the combined size of both of them.

Well, in my example the code, the data and the processor are
intermingled. Still you could do it this way. But, what would happen
for example if on a normal machine someone wrote a program that
generated lots of functions that it never used, would it have to be
detected by the GC. This is hard to do. The solution is probably to
define the root set only in terms of data.

If you're worried about comparing incompatible units, don't be: apples and
oranges compare just fine under big-Oh.

Yes. Thank you for comprehensively out-arguing me.

I'll give one last reason why it may not be a good thing to define:
reference counting. Some people want to use refcounts, and believe
that under certain circumstances they provide better performance than
GC. I don't know if they're right, I suspect they are for some limited
circumstances. A normal ref-count system can't be gauranteed to have
no memory holes introduced by loops in the data. But, if the
programmer causes no loops to come into being then he/she is safe. An
implementation that used refcounting might not be of much general use,
but for specific purposes, embedded programming for example, it might
be useful.

[=?iso-8859-1?q?Lars_Rune_N=F8stdal?=]

Re: merits of Lisp vs Python

On Fri, 08 Dec 2006 03:07:09 -0800, 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

Kill this frakkin thread; Lisp rules -- while Python is boring (but better
than many other alternatives). E.O.F.

--
Lars Rune Nøstdal

http://nostdal.org/

[Fuzzyman]

Re: merits of Lisp vs Python


Lars Rune Nøstdal wrote:

On Fri, 08 Dec 2006 03:07:09 -0800, 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

>
Kill this frakkin thread; Lisp rules -- while Python is boring (but better
than many other alternatives). E.O.F.
>

Perhaps only with the addendum that although 'Lisp roolz', no-one uses
for anything of relevance anymore and it is continuing it's geriatric
decline into obscurity. ;-)

Python is dull, except to the ever increasing group of programmers who
use it for practical purposes.

Hmm... a fitting. EOF.

Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml

--
Lars Rune Nøstdal
http://nostdal.org/

[defcon8]

Re: merits of Lisp vs Python

All of you are nazis!

[Fuzzyman]

Re: merits of Lisp vs Python


defcon8 wrote:

All of you are nazis!

Hmmm... that might work. :-)

Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml

[Juan R.]

Re: merits of Lisp vs Python

Fuzzyman ha escrito:

Perhaps only with the addendum that although 'Lisp roolz', no-one uses
for anything of relevance anymore and it is continuing it's geriatric
decline into obscurity. ;-)

I do not think that i cannot agree with the contrary of this but i do
not think the contrary neither.

I am being said that LISP is being actively pursued by a number of
joung hackers as Graham and Tilton. Do not believe?

Ken Tilton has noticed that Dalai Lama has becomed interested in LISP
also.

[=?iso-8859-1?q?Lars_Rune_N=F8stdal?=]

Re: merits of Lisp vs Python

On Sat, 23 Dec 2006 12:38:30 -0800, Fuzzyman wrote:

>
Lars Rune Nøstdal wrote:

>On Fri, 08 Dec 2006 03:07:09 -0800, 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

>>
>Kill this frakkin thread; Lisp rules -- while Python is boring (but better
>than many other alternatives). E.O.F.
>>

>
Perhaps only with the addendum that although 'Lisp roolz', no-one uses
for anything of relevance anymore and it is continuing it's geriatric
decline into obscurity. ;-)

Screw it; I'll die a "non-professional" programmer if I have to. Meanwhile
ridiculing and scorning all the fools using inferior languages. *hah!*

If I can't do what I love when it comes to programming I'd rather have a
shitty non-programming job that enables me to instantly forget what I've
been doing while at work as soon as I'm done for the day.

My trade -- my tools. :}

--
Lars Rune Nøstdal

http://nostdal.org/