BIG successes of Lisp (was ...)

[mike420]

In the context of LATEX, some Pythonista asked what the big
successes of Lisp were. I think there were at least three *big*
successes.

a. orbitz.com web site uses Lisp for algorithms, etc.
b. Yahoo store was originally written in Lisp.
c. Emacs

The issues with these will probably come up, so I might as well
mention them myself (which will also make this a more balanced
post)

a. AFAIK Orbitz frequently has to be shut down for maintenance
(read "full garbage collection" - I'm just guessing: with
generational garbage collection, you still have to do full
garbage collection once in a while, and on a system like that
it can take a while)

b. AFAIK, Yahoo Store was eventually rewritten in a non-Lisp.
Why? I'd tell you, but then I'd have to kill you :)

c. Emacs has a reputation for being slow and bloated. But then
it's not written in Common Lisp.

Are ViaWeb and Orbitz bigger successes than LATEX? Do they
have more users? It depends. Does viewing a PDF file made
with LATEX make you a user of LATEX? Does visiting Yahoo
store make you a user of ViaWeb?

For the sake of being balanced: there were also some *big*
failures, such as Lisp Machines. They failed because
they could not compete with UNIX (SUN, SGI) in a time when
performance, multi-userism and uptime were of prime importance.
(Older LispM's just leaked memory until they were shut down,
newer versions overcame that problem but others remained)

Another big failure that is often _attributed_ to Lisp is AI,
of course. But I don't think one should blame a language
for AI not happening. Marvin Mins ky, for example,
blames Robotics and Neural Networks for that.

[Jon S. Anthony]

"Rainer Deyke" <ra*****@eldwoo d.com> writes:

I'm all for more elaborate gc schemes. In particular, I want one
that gives me guaranteed immediate destructors even in the presence
of reference cycles. And I want to language specification to
guarantee it.
It's difficult to even put a requirement for "gc" in a language
_specification_ let alone one that _guarantees_ this sort of thing.

Having to explicitly close files is something I'd expect in C or
assembly, but it has no place in high-level languages. And
"with-open-file" is too limiting. Let the computer do the work, not
the programmer.

What's limiting about it? Or are you saying you want the computer (or
I suppose the language spec) to somehow also open your files for you
as well? What would that even mean? If you don't require that, then
you have to explicitly ask for the file to be opened. Well, that's
what with-open-file is.

/Jon

[Frode Vatvedt Fjeld]

"Rainer Deyke" <ra*****@eldwoo d.com> writes:

I'm all for more elaborate gc schemes. In particular, I want one
that gives me guaranteed immediate destructors even in the presence
of reference cycles. And I want to language specification to
guarantee it.

Having to explicitly close files is something I'd expect in C or
assembly, but it has no place in high-level languages. And
"with-open-file" is too limiting. Let the computer do the work, not
the programmer.

This is the problem with languages that are part excellent and part
work in progress (read: crap). You learn to trust the language from
using the excellent parts (which tend to be the basic things you first
encounter), and when you eventually stumble upon the not-so-great
parts you trust those parts, too. It's extremely unfortunate, IMHO.

--
Frode Vatvedt Fjeld

[Anton Vredegoor]

Stephen Horne <st***@ninereed s.fsnet.co.uk> wrote:

Perception is not reality. It is only a (potentially flawed)
representati on of reality. But reality is still real. And perception
*is* tied to reality as well as it can be by the simple pragmatic
principle of evolution - if our ancestors had arbitrary perceptions
which were detached from reality, they could not have survived and had
children.

If we had the same perceptions about reality as our ancestors, we
wouldn't reproduce very successfully now, because the world has
changed as a result of their reproductive success.

Anton

[Rainer Deyke]

Jon S. Anthony wrote:

"Rainer Deyke" <ra*****@eldwoo d.com> writes:

I'm all for more elaborate gc schemes. In particular, I want one
that gives me guaranteed immediate destructors even in the presence
of reference cycles. And I want to language specification to
guarantee it.

It's difficult to even put a requirement for "gc" in a language
_specification_ let alone one that _guarantees_ this sort of thing.

Having to explicitly close files is something I'd expect in C or
assembly, but it has no place in high-level languages. And
"with-open-file" is too limiting. Let the computer do the work, not
the programmer.

What's limiting about it?

Unless I've completely misunderstood the concept, "with-open-file" requires
me to structure my program such that the file is opened at the beginning and
closed at the end of a block of code. In the absence of coroutines or
threads (both of which would significantly complicate the structure of my
code), this implies that the lifetime of open files is strictly
hierarchical: if file 'a' is opened while file 'b' is open, then file 'b'
must be closed before file 'a' is closed. More generally, it implies that
the file is opened at the beginning of a natural code block (instead of, for
example, on first use) and is closed at the end of the same block (instead
of, for example, when it is no longer needed).
--
Rainer Deyke - ra*****@eldwood .com - http://eldwood.com

[Thomas F. Burdick]

Bjorn Pettersen <bj************ *@comcast.net> writes:

Raymond Wiker <Ra***********@ fast.no> wrote:

"Rainer Deyke" <ra*****@eldwoo d.com> writes:

Personally I'd prefer guaranteed immediate destructors over
with-open-file. More flexibility, less syntax, and it matches what
the CPython implementation already does.

Right... all along until CPython introduces a more elaborate
gc scheme.

... which is highly unlikely to happen without preservation of reference
counting semantics for files... google if you're _really_ interested :-/

I hope you put assertion in your code so that it won't run under
Jython, because that's the kind of insidious bug that would be
*aweful* to find the hard way.

(I really don't understand why you wouldn't just want at least real
closures, so you can just use call_with_open_ file, and not have to
worry about what GC you're using when *opening* *files*)

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

[Peter Seibel]

"Rainer Deyke" <ra*****@eldwoo d.com> writes:

Jon S. Anthony wrote:

"Rainer Deyke" <ra*****@eldwoo d.com> writes:

I'm all for more elaborate gc schemes. In particular, I want one
that gives me guaranteed immediate destructors even in the presence
of reference cycles. And I want to language specification to
guarantee it.

It's difficult to even put a requirement for "gc" in a language
_specification_ let alone one that _guarantees_ this sort of thing.

Having to explicitly close files is something I'd expect in C or
assembly, but it has no place in high-level languages. And
"with-open-file" is too limiting. Let the computer do the work, not
the programmer.

What's limiting about it?

Unless I've completely misunderstood the concept, "with-open-file"
requires me to structure my program such that the file is opened at
the beginning and closed at the end of a block of code.

I don't know about "completely " but you've certainly misunderstood an
important point. Yes, WITH-OPEN-FILE attempts to open a file, executes
a block of code with the open stream bound to a variable, and then
closes the stream when the block is exited, even if something goes
wrong such as a condition being signaled.

But--and this is the bit I think you may have missed--if that's *not*
what you want you don't use WITH-OPEN-FILE. Lisp also provides OPEN
and CLOSE, that act as you'd expect and allow you to explicitly
control the lifetime of the file stream.

Which gets us back to Pascal's original point--WITH-OPEN-FILE is a
macro that abstracts a set of operations in a concise way. (In
addition to ensuring that the file is closed, it also allows us to
easily express what to do in certain situations while trying to open
the file--what to do if the file already exists or doesn't exist,
etc.)

-Peter

--
Peter Seibel pe***@javamonke y.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

[Jon S. Anthony]

"Rainer Deyke" <ra*****@eldwoo d.com> writes:

Jon S. Anthony wrote:

"Rainer Deyke" <ra*****@eldwoo d.com> writes:

I'm all for more elaborate gc schemes. In particular, I want one
that gives me guaranteed immediate destructors even in the presence
of reference cycles. And I want to language specification to
guarantee it.
It's difficult to even put a requirement for "gc" in a language
_specification_ let alone one that _guarantees_ this sort of thing.

Having to explicitly close files is something I'd expect in C or
assembly, but it has no place in high-level languages. And
"with-open-file" is too limiting. Let the computer do the work, not
the programmer.

What's limiting about it?

Unless I've completely misunderstood the concept, "with-open-file" requires
me to structure my program such that the file is opened at the beginning and
closed at the end of a block of code.

No it does not require this - it is what you use when this is the
natural expression for what you would want.
In the absence of coroutines or threads (both of which would
significantly complicate the structure of my code), this implies
that the lifetime of open files is strictly hierarchical: if file
'a' is opened while file 'b' is open, then file 'b' must be closed
before file 'a' is closed.
No, even within the with-open-file of b you could close a whenever or
wherever you wanted. The with-open-file for a just guarantees certain
things when you leave the scope.
More generally, it implies that the file is opened at the beginning
of a natural code block
Well, the block that it itself opens.

and is closed at the end of the same block .
Is guaranteed to be closed. You could close it before this if that
made sense.

(instead of, for example, on first use) ... (instead of, for
example, when it is no longer needed)

OK. If your code needs to be more flexible in this, you would use
OPEN and/or CLOSE. If you had a particular open/close paradigm in
mind you could then write an abstraction (macro) akin to
with-open-file which provides behavior like what you say here and it
would generate the calls to open and close. I'm sure there are
scenarios where this might not be "reasonably doable".

/Jon

[Robin Becker]

In article <rd************ *************** *****@4ax.com>, Stephen Horne
<st***@ninereed s.fsnet.co.uk> writes

On Fri, 24 Oct 2003 16:00:12 +0200, an***@vredegoor .doge.nl (Anton
Vredegoor) wrote:
.......Perception is not reality. It is only a (potentially flawed)
representati on of reality. But reality is still real. And perception
*is* tied to reality as well as it can be by the simple pragmatic
principle of evolution - if our ancestors had arbitrary perceptions
which were detached from reality, they could not have survived and had
children.

......
It is a commonplace of developmental psychology that the persistence of
objects is learned by children at some relatively young age (normally 3
months as I recall). I assume that children learn the persistence of
hidden objects by some statistical mechanism ie if it happens often
enough it must be true (setting up enough neural connections etc).

Would the reality of children subjected to a world where hidden objects
were somehow randomly 'disappeared' be more or less objective then that
of normal children.

Unlucky experimental cats brought up in vertical stripe worlds were
completely unable to perceive horizontals so their later reality was
apparently filled with invisible and mysterious objects. I can't
remember if they could do better by rotating their heads, but even that
would be quite weird.

I think it unwise to make strong statements about reality when we know
so little about it. Apparently now the universe is 90-95% stuff we don't
know anything about and we only found that out in the last 10 years.
--
Robin Becker

[Rainer Deyke]

Peter Seibel wrote:

But--and this is the bit I think you may have missed--if that's *not*
what you want you don't use WITH-OPEN-FILE. Lisp also provides OPEN
and CLOSE, that act as you'd expect and allow you to explicitly
control the lifetime of the file stream.

Which leads us back to having to manually close files.

I DON'T want to manually close files. I DON'T want to deal with the
limitations of with-open-file. And, here's the important bit, I DON'T WANT
TO COMBINE OR CHOOSE BETWEEN THESE TWO METHODS, BOTH OF WHICH ARE FLAWED.

What I want to open a file and have it close automatically when I am done
with it. I can do that in C++. Why can't I do it in Python?
--
Rainer Deyke - ra*****@eldwood .com - http://eldwood.com

[Matthew Danish]

On Fri, Oct 24, 2003 at 06:09:55PM +0000, Rainer Deyke wrote:

[...] and is closed at the end of the same block (instead of, for
example, when it is no longer needed).

The reasoning behind WITH-OPEN-FILE is that file streams are resources
that should be allocated with dynamic extent, not indefinite. To make
that more concrete, it means that file streams should be closed
immediately after they are no longer being used (much like local
variables in C are immediately destroyed when the function returns).

I have seen debates before that argue that memory should be the only
resource managed by GC, and the opposite view that every resource should
be managable by GC (I don't think this is quite as feasible, but you can
look up the discussions on google, a year ago on c.l.l or so).

But WITH-OPEN-FILE doesn't prevent you from, say, having a file open the
entire time your program is running. Some people pointed out that you
can use OPEN and CLOSE, but also this would work fine:

(defvar *log-stream*) ;; an unbound special variable

(defun log (fmt-control &rest args)
(apply 'format *log-stream* fmt-control args))

(defun start (&key (log-file "log"))
(with-open-file (*log-stream* log-file
:direction :output
:if-exists :append)
;; *log-stream* is bound until this body exits
(call-other-functions)))
--
; Matthew Danish <md*****@andrew .cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian. org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."