BIG successes of Lisp (was ...)
mik...@ziplip.com
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.
Paul Rubin
> 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)
I'm skeptical that's the reason for the shutdowns, if they're using a
reasonable Lisp implementation.
> b. AFAIK, Yahoo Store was eventually rewritten in a non-Lisp.
> Why? I'd tell you, but then I'd have to kill you :)
The Yahoo Store software was written by some small company that sold
the business to some other company that didn't want to develop in
Lisp, I thought. I'd be interested to know more.
> c. Emacs has a reputation for being slow and bloated. But then
> it's not written in Common Lisp.
Actually, Hemlock is much more bloated. However, Emacs's reputation
for bloat came from the 1 mips VAX days, when it was bigger than less
capable editors such as vi. However, compared with the editors people
run all the time on PC's nowadays (viz. Microsoft Word), Emacs is tiny
and fast. In fact if I want to look in a big mail archive for (say)
mentions of Python, it's faster for me to read the file into Emacs and
search for "python" than it is for me to pipe the file through "more"
and use "more"'s search command.
> 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?
I missed the earlier messages in this thread but Latex wasn't written
in Lisp. There were some half-baked attempts to lispify TeX, but
afaik none went anywhere.
> 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.
Well, they were too bloody expensive too.
> 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.
Actually, there are many AI success stories, but the AI field doesn't
get credit for them, because as soon as some method developed by AI
researchers becomes useful or practical, it stops being AI. Examples
include neural networks, alpha-beta search, natural language
processing to the extent that it's practical so far, optical character
recognition, and so forth.
Daniel P. M. Silva
> There were some half-baked attempts to lispify TeX, but
> afaik none went anywhere.
Tex2page is pretty nice:
http://www.ccs.neu.edu/home/dorai/tex2page/tex2page-doc.html
Erann Gat
<http://phr...@NOSPAM.invalid> wrote:
> The Yahoo Store software was written by some small company
Viaweb
> that sold the business to some other company
Yahoo (obviously).
> that didn't want to develop in
> Lisp, I thought.
That's right. Yahoo ultimately reimplemented Yahoo Store in C++.
E.
David Steuber
> c. Emacs has a reputation for being slow and bloated. But then
> it's not written in Common Lisp.
I wonder if this reputation is still deserved. I am running a CVS
build of Emacs on a PowerBook G4 right now. It is MUCH smaller than
Safari.
Emacs:
VM Size: 90,496 Kb
RM Size: 14,567 Kb
Safari:
VM Size: 174,452 Kb
RM Size: 94,616 Kb
Granted, Emacs is #4 out of 43 processes in memory usage.
Emacs choked on me the other day when I tried to load all the XOVER
info for one of the news groups that I am subscribed to.
Because Emacs Lisp is a byte compiled language, a loaded file doesn't
take up much space. Once you have the runtime loaded, much of the
rest is nearly sorta free.
I think other programs that users frequently run have grown in size
faster than Emacs has. Microsoft Word is no lightweight. In spite
of that, Word is rather limited in its utility. It doesn't do much
more than create doc files. That's fine if you are publishing a
school news letter, but I doubt it has real world utility.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
Peter Seibel
Of course to do so, they had to--according to Paul Graham--implement a
Lisp interpreter in C++! And they had to leave out some features that
depended on closures. So folks who are running the old Lisp version
may never "upgrade" to the new version since it would mean a
functional regression. Graham's messages on the topic to the ll1 list
are at:
<http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02380.html>
<http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02367.html>
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Kenny Tilton
Peter Seibel wrote:
> g...@jpl.nasa.gov (Erann Gat) writes:
>
>
>>In article <7xvfqs6...@ruckus.brouhaha.com>, Paul Rubin
>><http://phr...@NOSPAM.invalid> wrote:
>>
>>
>>>The Yahoo Store software was written by some small company
>>
>>Viaweb
>>
>>
>>>that sold the business to some other company
>>
>>Yahoo (obviously).
>>
>>
>>>that didn't want to develop in Lisp, I thought.
>>
>>That's right. Yahoo ultimately reimplemented Yahoo Store in C++.
>
>
> Of course to do so, they had to--according to Paul Graham--implement a
> Lisp interpreter in C++!
I hope he made another $40m off them in consulting fees helping them
with the port. :)
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
prunes...@comcast.net
> 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)
You are misinformed. Orbitz runs a `server farm' of hundreds of
computers each running the ITA faring engine. Should any of these
machines need to GC, there are hundreds of others waiting to service
users.
Christian Lynbech
mike420> c. Emacs has a reputation for being slow and bloated.
People making that claim most often does not understand what Emacs
really is or how to use it effectively. Try to check out what other
popular software use up on such peoples machines, stuff like KDE or
gnome or mozilla or any Java based application.
This just isn't a very relevant issue on modern equipment.
mike420> For the sake of being balanced: there were also some *big*
mike420> failures, such as Lisp Machines. They failed because
mike420> they could not compete with UNIX (SUN, SGI) in a time when
mike420> performance, multi-userism and uptime were of prime importance.
It is still a question of heated debate what actually killed the lisp
machine industry.
I have so far not seen anybody dipsuting that they were a marvel of
technical excellence, sporting stuff like colour displays, graphical
user interfaces and laser printers way ahead of anybody else.
In fact the combined bundle of a Symbolics machine is so good that
there still is a viable market for those 20-30 years old machines
(been there, done that, still needs to get it to run :-) I challenge
you to get a good price for a Sun 2 with UNIX SYSIII or whatever they
were equipped with at the time.
As far as I know Symbolics was trying to address the price issues but
the new generation of the CPU was delayed which greatly contributed to
the original demise and subsequent success of what we now know as
stock hardware. Do not forget that when the Sun was introduced it was
by no means obvious who was going to win the war of the graphical
desktop server.
------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Paolo Amoroso
> In the context of LATEX, some Pythonista asked what the big
> successes of Lisp were. I think there were at least three *big*
See:
http://alu.cliki.net/Success%20Stories
> a. AFAIK Orbitz frequently has to be shut down for maintenance
> (read "full garbage collection" - I'm just guessing: with
They don't use garbage collection, they do explicit memory allocation
from pools. More details were given in the ILC 2002 talk "ITA Software
and Orbitz: Lisp in the Online Travel World" by Rodney Daughtrey:
http://www.international-lisp-conference.org/ILC2002/Speakers/People/Rodney-Daughtrey.html
The talk's slides are included in the ILC 2002 proceedings available
from Franz, Inc. As for shutdown for maintenance, the slides seem to
suggest that they use online patching.
Paolo
Edi Weitz
> a. AFAIK Orbitz frequently has to be shut down for maintenance
Where do you "know" that from? Have you any quotes or numbers to back
up your claims or are you just trying to spread FUD?
> (read "full garbage collection" -
Others have debunked this already.
> I'm just guessing:
Please leave the guessing to people who are better at it.
Edi.
Ivan Toshkov
Besides, when I read the description of orbiz, I was with the
impression, that they prealocated the memory for just that reason: to
remove the need for garbage collection.
--
Ivan Toshkov
email: first...@last-name.org
Joe Marshall
> It is still a question of heated debate what actually killed the lisp
> machine industry.
>
> I have so far not seen anybody disputing that they were a marvel of
> technical excellence, sporting stuff like colour displays, graphical
> user interfaces and laser printers way ahead of anybody else.
It's clear to me that LMI killed itself by an attempt to rush the
LMI-Lambda to market before it was reasonably debugged. A lot of LMI
machines were DOA. It's amazing how fast you can lose customers that
way.
As far as Symbolics goes... I *think* they just saturated the market.
mik...@ziplip.com
>
> Besides, when I read the description of orbiz, I was with the
> impression, that they prealocated the memory for just that reason: to
> remove the need for garbage collection.
An why would anyone do something this gross to optimize something
that is *not* a real bottleneck? Think when you read. The fact is,
they still had close their whole web site for maintenance every
once in a while (I never said if it was a supercomputer cluser or
a DOS machine) I added "AFAIK" qualifier because it *may*
be an old and already resolved issue.
Edi Weitz and Joe Marshall, you may stop kissing ass now. You
need brains to work for ITA, not lips.
Wade Humeniuk
Macsyma and Maxima http://maxima.sourceforge.net/
Powercase and Watson http://www.xanalys.com/solutions/powercase.html
AutoCAD http://www.autocad.com
Wade
Joe Marshall
I'm well aware of the necessary qualifications for working at ITA.
I worked there. Any shutdown at Orbitz was (and is) unrelated to
garbage collection.
John Thingstad
wrote:
You all seem to forget www.google.com
One of the most used distributed applications in the world.
Written in Common Lisp (xanalysis)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
mik...@ziplip.com
> mik...@ziplip.com writes:
>
>> Ivan Toshkov wrote:
>>
>>>
>>> Besides, when I read the description of orbiz, I was with the
>>> impression, that they prealocated the memory for just that reason: to
>>> remove the need for garbage collection.
>>
>> An why would anyone do something this gross to optimize something
>> that is not a real bottleneck? Think when you read. The fact is,
>> they still had close their whole web site for maintenance every
>> once in a while (I never said if it was a supercomputer cluser or
>> a DOS machine) I added "AFAIK" qualifier because it may
>> be an old and already resolved issue.
>>
>> Edi Weitz and Joe Marshall, you may stop kissing ass now. You
>> need brains to work for ITA, not lips.
>
> I'm well aware of the necessary qualifications for working at ITA.
Do the necessary qualifications have anything to do with
why you do not work there any more, while ITA is still
recruiting?
<insert random lie here, joe>
> I worked there.
Half-truth
> Any shutdown at Orbitz was (and is) unrelated to
> garbage collection.
Another
Anyway, I'm getting tired of your mindless content-free
pukes of posts. Someone said prunes...@comcast.net was
also you. Is that right?
If you strive for expressing balanced opinions, I might
let you stick around and have my left-overs.
Marc Battyani
"Paul Rubin" <http://phr...@NOSPAM.invalid>
> I missed the earlier messages in this thread but Latex wasn't written
> in Lisp. There were some half-baked attempts to lispify TeX, but
> afaik none went anywhere.
I'm currently working on a Common Lisp typesetting system based on cl-pdf.
One example of what it can already do is here:
http://www.fractalconcept.com/ex.pdf
For now I'm working on the layout and low level stuff. But it's a little bit
soon to think that it will go nowhere, as I hope a lot of people will add TeX
compatibility packages for it ;-)
BTW note that I'm not rewriting TeX. It's another design with other
priorities.
Marc
Raymond Wiker
> On Tue, 14 Oct 2003 16:16:52 GMT, Wade Humeniuk
> <whum...@nospamtelus.net> wrote:
>
>> As to Lisp Successes I would like to add just a few:
>>
>> Macsyma and Maxima http://maxima.sourceforge.net/
>>
>> Powercase and Watson http://www.xanalys.com/solutions/powercase.html
>>
>> AutoCAD http://www.autocad.com
>>
>> Wade
>>
>
> You all seem to forget www.google.com
> One of the most used distributed applications in the world.
> Written in Common Lisp (xanalysis)
I'm pretty sure that this is absolutely incorrect.
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Francis Avila
news:ofu16cm...@situla.ted.dk.eu.ericsson.se...
> >>>>> "mike420" == mike420 <mik...@ziplip.com> writes:
>
> It is still a question of heated debate what actually killed the lisp
> machine industry.
>
> I have so far not seen anybody dipsuting that they were a marvel of
> technical excellence, sporting stuff like colour displays, graphical
> user interfaces and laser printers way ahead of anybody else.
I think what helped kill the lisp machine was probably lisp: many people
just don't like lisp, because it is a very different way of thinking that
most are rather unaccustomed to. Procedural, imperative programming is
simply a paradigm that more closely matches the ordinary way of thinking
(ordinary = in non-programming, non-computing spheres of human endevor) than
functional programming. As such, lisp machines were an oddity and too
different for many to bother, and it was easy for them to come up with
excuses not to bother (so that the 'barrier of interest,' so to speak, was
higher.) Lisp, the language family (or whatever you want to call it), still
has this stigma: lambda calculus is not a natural way of thinking.
This isn't to make a value judgment, but I think it's an important thing
that the whole "functional/declarative v. procedural/OO" debate overlooks.
The same reason why programmers call lisp "mind-expanding" and "the latin of
programming languages" is the very same reason why they are reluctant to
learn it--its different, and for many also hard to get used to. Likewise,
Americans seem to have some repulsive hatred of learning latin--for people
who are used to english, it's just plain different and harder, even if it's
better. (Ok, that last bit was a value judgement. :)
Python doesn't try (too) hard to change the ordinary manner of thinking,
just to be as transparent as possible. I guess in that sense it encourages a
degree of mental sloth, but the objective is executable pseudocode. Lisp
counters that thinking the lisp way may be harder, but the power it grants
is out of all proportion to the relatively meager investment of mental
energy required--naturally, it's hard to convince someone of that if they
don't actually _use_ it first, and in the end some will probably still think
it isn't worth the trouble. It will take very significant and deep cultural
and intellectual changes before lisp is ever an overwhelmingly dominant
language paradigm. That is, when it becomes more natural to think of
cake-making as
UD: things
Gxyz: x is baked at y degrees for z minutes.
Hx: x is a cake.
Ix: x is batter.
For all x, ( (Ix & Gx(350)(45)) > Hx )
(i.e. "Everything that's a batter and put into a 350 degree oven for 45
minutes is a cake")
...instead of...
1. Heat the oven to 350 degrees.
2. Place batter in oven.
3. Bake 45 minutes
4. Remove cake from oven.
(i.e. "To make a cake, bake batter in a 350 degree oven for 45 minutes")
...then lisp will take over the universe. Never mind that the symbolic
logic version has more precision.
--
Francis Avila
Andreas Hinze
>
> You all seem to forget www.google.com
> One of the most used distributed applications in the world.
> Written in Common Lisp (xanalysis)
>
From where do you know that ?
Best
AHz
Terry Reedy
<mik...@ziplip.com> wrote in message
news:HSD5CGINNUHWOPIMEOD4...@ziplip.com...
As far as I can tell, this discussion of Orbiz has nothing to do with
Python.
Could you Lisp guys leave us out?
TJR
Joe Marshall
> Joe Marshall wrote:
>
>> mik...@ziplip.com writes:
>>
>>> Ivan Toshkov wrote:
>>>
>>>>
>>>> Besides, when I read the description of orbiz, I was with the
>>>> impression, that they prealocated the memory for just that reason: to
>>>> remove the need for garbage collection.
>>>
>>> An why would anyone do something this gross to optimize something
>>> that is not a real bottleneck? Think when you read. The fact is,
>>> they still had close their whole web site for maintenance every
>>> once in a while (I never said if it was a supercomputer cluser or
>>> a DOS machine) I added "AFAIK" qualifier because it may
>>> be an old and already resolved issue.
>>>
>>> Edi Weitz and Joe Marshall, you may stop kissing ass now. You
>>> need brains to work for ITA, not lips.
>>
>> I'm well aware of the necessary qualifications for working at ITA.
>
> Do the necessary qualifications have anything to do with
> why you do not work there any more, while ITA is still
> recruiting?
You're obviously more informed than I am, so you tell me.
> <insert random lie here, joe>
I did not inhale.
>> I worked there.
>
> Half-truth
Which half?
>> Any shutdown at Orbitz was (and is) unrelated to
>> garbage collection.
>
> Another
The expert speaks.
> Anyway, I'm getting tired of your mindless content-free
> pukes of posts.
I don't recall asking you.
> Someone said prunes...@comcast.net was
> also you. Is that right?
>
> If you strive for expressing balanced opinions, I might
> let you stick around and have my left-overs.
Why would I want those?
David Steuber
> I'm currently working on a Common Lisp typesetting system based on cl-pdf.
> One example of what it can already do is here:
> http://www.fractalconcept.com/ex.pdf
>
> For now I'm working on the layout and low level stuff. But it's a little bit
> soon to think that it will go nowhere, as I hope a lot of people will add TeX
> compatibility packages for it ;-)
This is interesting to me because I would like to have something
kinda similar in ELisp for generating PDF files by filling in forms
in an Emacs buffer.
I haven't done the basic research to see what prior art is out there
yet.
> BTW note that I'm not rewriting TeX. It's another design with other
> priorities.
That's just as well. TeX works pretty well as it is and is all over
the place. I'm not sure that there is a benefit to rewriting it.
No one has accused me of having an imagination either.
Terry Reedy
"Francis Avila" <franci...@yahoo.com> wrote in message
news:voobanm...@corp.supernews.com...
lisp
> > machine industry.
>
people
> just don't like lisp, because it is a very different way of thinking
that
> most are rather unaccustomed to.
My contemporaneous impression, correct or not, as formed from
miscellaneous mentions in the computer press and computer shows, was
that they were expensive, slow, and limited -- limited in the sense of
being specialized to running Lisp, rather than any language I might
want to use. I can understand that a dedicated Lisper would not
consider Lisp-only to be a real limitation, but for the rest of us...
If these impressions are wrong, then either the publicity effort was
inadequate or the computer press misleading. I also never heard of
any 'killer ap' like Visicalc was for the Apple II. Even if there had
been, I presume that it could have been ported to others workstations
and to PCs -- or imitated, just as spreadsheets were (which removed
Apple's temporary selling point).
Terry J. Reedy
Marc Battyani
> "Marc Battyani" <Marc.B...@fractalconcept.com> writes:
>
> > I'm currently working on a Common Lisp typesetting system based on
cl-pdf.
> > One example of what it can already do is here:
> > http://www.fractalconcept.com/ex.pdf
> >
> > For now I'm working on the layout and low level stuff. But it's a little
bit
> > soon to think that it will go nowhere, as I hope a lot of people will add
TeX
> > compatibility packages for it ;-)
>
> This is interesting to me because I would like to have something
> kinda similar in ELisp for generating PDF files by filling in forms
> in an Emacs buffer.
cl-pdf is here:
http://www.fractalconcept.com/asp/html/cl-pdf.html
This won't work at all with emacs lisp.
Version 2.0 will be out tomorrow.
> I haven't done the basic research to see what prior art is out there
> yet.
>
> > BTW note that I'm not rewriting TeX. It's another design with other
> > priorities.
>
> That's just as well. TeX works pretty well as it is and is all over
> the place. I'm not sure that there is a benefit to rewriting it.
>
> No one has accused me of having an imagination either.
Try harder... ;-)
Marc
Wade Humeniuk
> My contemporaneous impression, correct or not, as formed from
> miscellaneous mentions in the computer press and computer shows, was
> that they were expensive, slow, and limited -- limited in the sense of
> being specialized to running Lisp, rather than any language I might
> want to use. I can understand that a dedicated Lisper would not
> consider Lisp-only to be a real limitation, but for the rest of us...
>
Well its not true. Symbolics for one supported additional languages,
and I am sure others have pointed out that are C compilers for
the Lisp Machines.
See
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/symbolics-tech-summary.html
Section: Other Languages
It says that Prolog, Fortran and Pascal were available.
Wade
David Steuber
> Lisp, the language family (or whatever you want to call it), still
> has this stigma: lambda calculus is not a natural way of thinking.
My experience with other wannabe programmers is that any logical
thought for solving a problem is not a natural way of thinking. C++
is no better than Lisp for working out a problem. Python, Ruby,
Perl, et al, are not any better either.
I think the infix notation languages just seem more natural because
that is what more people are exposed to.
The HP calculators with RPN were never as popular either. But to
those who used them, RPN was far better than infix.
The PostScript language is also an RPN. If you have experience with
HP calculators, it is a drop dead simple language. However, the
postfix notation lacks the power of the prefix notation and
parenthesized grouping used in Lisp. ie
(+ 1 2 3 4 5)
vs
1 2 3 4 5 add add add add
Lisp has far simpler syntax than infix languages. The syntax is
almost, but not quite, as simple as assembler.
Try doing this in C++, Python, or whatever:
(do ((a 1 b) (b 1 (+ a b)))
(nil a)
(print a))
You will need to add a temp variable to do the sequence properly.
You very quickly run into bignums. That can be fixed by substituting
a simple predicate in place of the nil. In any case, I've never seen
a shorter version of that sequence generator.
I'm not saying Lisp is easy. The real truth is that no programming
language is easy. Programming is a difficult task regardless of the
language you use. If it wasn't, there wouldn't be so much effort
expended on trying to write bug free software because everyone would
be doing it. Rational would not exist. There would be no RUP or
extreme programming schools of thought.
Kaz Kylheku
> b. AFAIK, Yahoo Store was eventually rewritten in a non-Lisp.
> Why? I'd tell you, but then I'd have to kill you :)
From a new footnote in Paul Graham's ``Beating The Averages'' article:
In January 2003, Yahoo released a new version of the editor written
in C++ and Perl. It's hard to say whether the program is no longer
written in Lisp, though, because to translate this program into C++
they literally had to write a Lisp interpreter: the source files of
all the page-generating templates are still, as far as I know, Lisp
code. (See Greenspun's Tenth Rule.)
Rainer Joswig
Wade Humeniuk <whum...@nospamtelus.net> wrote:
ADA also.
Actually using an incremental C compiler and running C on type- and bounds-checking
hardware - like on the Lisp Machine - is not that a bad idea.
A whole set of problems disappears.
David Steuber
> cl-pdf is here:
> http://www.fractalconcept.com/asp/html/cl-pdf.html
> This won't work at all with emacs lisp.
Not even in an inferior Lisp process?
> Version 2.0 will be out tomorrow.
I'll get it tomorrow then.
It looks interesting. I had a quick look at the examples page. I
didn't see one about reading in an existing PDF file and altering
that. Can that be done? Does PDF support some sort of DOM for
manipulating a document?
I'm having cold sweats thinking about reading in a PDF file and
turning it into the Lisp code that would generate that same PDF
file.
> > No one has accused me of having an imagination either.
>
> Try harder... ;-)
I'm working on it.
Gareth McCaughan
> Try doing this in C++, Python, or whatever:
>
> (do ((a 1 b) (b 1 (+ a b)))
> (nil a)
> (print a))
>
> You will need to add a temp variable to do the sequence properly.
> You very quickly run into bignums. That can be fixed by substituting
> a simple predicate in place of the nil. In any case, I've never seen
> a shorter version of that sequence generator.
Not a great example.
a,b = 1,1
while 1:
print a
a,b = b,a+b
4 lines rather than 3, but they're shorter lines (having
substantially fewer characters in all) and I think
their intention is clearer.
On the other hand, in C++ it's an abomination :-).
--
Gareth McCaughan
.sig under construc
Fred Gilham
> You all seem to forget www.google.com
> One of the most used distributed applications in the world.
> Written in Common Lisp (xanalysis)
Nah, google runs on 10K (yes, ten thousand) computers and is written
in C++. Norvig in his talk at the last Lisp conference explained all
this. He said this gave them the ability to patch and upgrade without
taking the whole system down --- they'd just do it
machine-by-machine.
--
Fred Gilham gil...@csl.sri.com
The density of a textbook must be inversely proportional to the
density of the students using it. --- Dave Stringer-Calvert
David Steuber
> Not a great example.
>
> a,b = 1,1
> while 1:
> print a
> a,b = b,a+b
>
> 4 lines rather than 3, but they're shorter lines (having
> substantially fewer characters in all) and I think
> their intention is clearer.
Ok, you beat me there. Python does bignums? I'll have to look
harder at it.
> On the other hand, in C++ it's an abomination :-).
Yeah, this one you might actually want to do in assembler. Right up
until you hit those bignums. Good thing there is a carry flag.
I think we should go back to MIX. Oh. We were never there.
Open the pod bay door please, HAL.
Raffael Cavallaro
David Steuber <david....@verizon.net> wrote:
> Try doing this in C++, Python, or whatever:
>
> (do ((a 1 b) (b 1 (+ a b)))
> (nil a)
> (print a))
I'm no Pythonista, but this works:
a, b = 1, 1
while 1:
print a
a, b = b, (a + b)
because Python has parallel assignment (or the equivalent of psetq).
The python version is arguably clearer than do, which is a powerful
general iterative construct. For complex iteration, there's nothing like
having do and do*, but they are not obvious at first glance.
How about loop for greater clarity than either do or Python?
(loop
for a = 1 then b
and b = 1 then (+ a b)
do (print a))
Which neatly demonstrates the power of macros as well. If there's a
clearer way of expressing your intent (i.e., _what_ you want to do, not
_how_ you are doing it) you are free in lisp to create that language
construct. With Python, you're stuck with what Guido thinks is good for
you. And the lisp version is about 30 times faster than the equivalent
Python too.
Gareth McCaughan
Going further,
(defmacro recur (vars inits next termination result &body body)
`(do ,(loop for tail on vars
for init in inits
collect (list (first tail) init
(if (rest tail)
(second tail)
next)))
(,termination ,result)
. ,body))
after which
(recur (a b) (1 1) (+ a b) nil a (print a))
is the same Fibonacci thing,
(recur (a) (1) (* 2 a) nil a (print a))
is the powers of 2, and so on. It's not clear to me that
the gain in conciseness is worth the loss in clarity, though.
With a trivial modification to the macro you can make its
uses look instead like one of these
(recur (a 1 b 1) (+ a b) nil a (print a))
(recur ((a 1) (b 1)) (+ a b) nil a (print a))
but I don't think either is an improvement.
Ingvar Mattsson
> Gareth McCaughan <gareth.m...@pobox.com> writes:
>
> > Not a great example.
> >
> > a,b = 1,1
> > while 1:
> > print a
> > a,b = b,a+b
> >
> > 4 lines rather than 3, but they're shorter lines (having
> > substantially fewer characters in all) and I think
> > their intention is clearer.
>
> Ok, you beat me there. Python does bignums? I'll have to look
> harder at it.
1134903170
Traceback (most recent call last):
File "<stdin>", line 3, in ?
OverflowError: integer addition
At least it *notices* that it's suddely not in Kansas anymore. Big
step up from implicitly modular "integers".
//Ingvar
--
Ingvar Mattsson; ing...@hexapodia.net;
You can get further with a kind word and a 2x4
than you can with just a kind word. Among others, Marcus Cole
Luke Gorrie
> David Steuber <david....@verizon.net> writes:
>
> > Ok, you beat me there. Python does bignums? I'll have to look
> > harder at it.
>
> 1134903170
> Traceback (most recent call last):
> File "<stdin>", line 3, in ?
> OverflowError: integer addition
You must be using an old version of Python. With 2.2+ it promotes to
bignums and works as expected.
The older versions have bignums too, but you have to mark them
explicitly. At least in 2.1, this works:
a,b = 1L,1L
while 1:
print a
a,b = b,a+b
Cheers,
Luke
Ingvar Mattsson
> Ingvar Mattsson <ing...@cathouse.bofh.se> writes:
>
> > David Steuber <david....@verizon.net> writes:
> >
> > > Ok, you beat me there. Python does bignums? I'll have to look
> > > harder at it.
> >
> > 1134903170
> > Traceback (most recent call last):
> > File "<stdin>", line 3, in ?
> > OverflowError: integer addition
>
> You must be using an old version of Python. With 2.2+ it promotes to
> bignums and works as expected.
Indeed.
ingvar@gruk$ python
Python 2.1.3 (#1, Sep 7 2002, 15:29:56)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.
How annoying. At least my pet hate with the Python REPL is still there
in 2.2 and 2.3.
//Ingvar
--
Q: What do you call a Discworld admin?
A: Chelonius Monk
Björn Lindberg
> ingvar@gruk$ python
> Python 2.1.3 (#1, Sep 7 2002, 15:29:56)
> [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
> Type "copyright", "credits" or "license" for more information.
>
> How annoying. At least my pet hate with the Python REPL is still there
> in 2.2 and 2.3.
Which is?
Björn
Ivan Toshkov
> Ivan Toshkov wrote:
>
>
>>Besides, when I read the description of orbiz, I was with the
>>impression, that they prealocated the memory for just that reason: to
>>remove the need for garbage collection.
>
>
> An why would anyone do something this gross to optimize something
How do you know?
> Think when you read. The fact is,
I do.
> they still had close their whole web site for maintenance every
> once in a while (I never said if it was a supercomputer cluser or
> a DOS machine) I added "AFAIK" qualifier because it *may*
> be an old and already resolved issue.
Read again the article, if you need to:
http://www.paulgraham.com/carl.html . Especially points 4 and 9 for
memory usage desciption and point 5 for the infrastructure.
--
Ivan Toshkov
email: first...@last-name.org
Scott McKay
> successes of Lisp were. I think there were at least three *big*
> successes.
> 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)
>
Not true. The servers do get restarted a couple of times
a day to get new data loads, which are huge.
Ingvar Mattsson
It treats blank lines differently in an interactive REPL and when
reading from a file. This makes "type code in file editor and paste
function to REPL" much harder than it should be. I *can* see the
convenience value of the current behaviour, but... (and before anyone
says it ignores blank lines, try sticking the example below in a
file, import the file and run it and compare with what a paste gives
you).
--- test example ---
def foo ()
print "Hello"
print "World"
--- end of example ---
The example is chosen to be small enough to be easily typable, but
large enough to demonstrate the problem. I haven't tried convincing my
editor to give me "indented blank lines".
//Ingvar
--
((lambda (x) `(,x ',x)) '(lambda (x) `(,x ',x)))
Probably KMP
Joe Marshall
> John Thingstad <john.th...@chello.no> writes:
>> You all seem to forget www.google.com
>> One of the most used distributed applications in the world.
>> Written in Common Lisp (xanalysis)
>
> Nah, google runs on 10K (yes, ten thousand) computers and is written
> in C++. Norvig in his talk at the last Lisp conference explained all
> this. He said this gave them the ability to patch and upgrade without
> taking the whole system down --- they'd just do it
> machine-by-machine.
Except, of course, when all ten thousand machines simultaneously stop
for `garbage collection'.
Terry Reedy
"Scott McKay" <scott...@comcast.net> wrote in message
news:63bjb.774440$YN5.758743@sccrnsc01...
Does Orbitz have anything to do with Python?
If not, please leave c.l.py off further discussion thereof.
Paolo Amoroso
even too much exposure to Lisp in other threads, I have set the
followup of this article to comp.lang.lisp only. Please consider
moving this, and all other Lisp-related discussions, to
comp.lang.lisp.
Francis Avila writes:
> I think what helped kill the lisp machine was probably lisp: many people
> just don't like lisp, because it is a very different way of thinking that
Why did it take Lisp Machines users over a decade to realize they
didn't like Lisp after all? It looks like Lisp generates pretty strong
feelings pretty fast.
By the way, there were at least Ada, C, Fortran and Prolog compilers
available for Genera, the operating system of Symbolics Lisp
Machines. The C compiler was good enought to port X Window to Genera.
Paolo
--
Paolo Amoroso <amo...@mclink.it>
larry
point. Take the task of finding the sum of the square of a bunch of
numbers.
Do people really think to themselves when they do this task:
Umm first make a variable called sum
then set that variable sum to zero.
Then get the next number in the list,
square it,
add it to the old value of sum,
store the resulting value into sum,
then get the next variable,etc....
No they they think: sum up the square of a bunch of numbers.
This has an almost direct translation to the lisp style:
(apply '+ (mapcar #'(lambda(x)(* x x)) numlist)).
The reason why the imperative style of programming seems natural is
because that's what people are used to programming in. It isn't
necessarily the way they formulate the problem to themselves. There is
always a translation step.
"Francis Avila" <franci...@yahoo.com> wrote in message
>
> UD: things
> Gxyz: x is baked at y degrees for z minutes.
> Hx: x is a cake.
> Ix: x is batter.
>
> For all x, ( (Ix & Gx(350)(45)) > Hx )
>
> (i.e. "Everything that's a batter and put into a 350 degree oven for 45
> minutes is a cake")
>
> ...instead of...
>
> 1. Heat the oven to 350 degrees.
> 2. Place batter in oven.
> 3. Bake 45 minutes
> 4. Remove cake from oven.
>
> (i.e. "To make a cake, bake batter in a 350 degree oven for 45 minutes")
>
> ...then lisp will take over the universe. Never mind that the symbolic
> logic version has more precision.
E.N. Fan
> If not, please leave c.l.py off further discussion thereof.
Well, for a start Orbitz could never have been realistically coded
with Python.
The fact that it could be programmed in Lisp is a testament to the
greater power and flexibility of Lisp. No amount of arguing could
speak louder than a proof like that.
jeffrey
David Steuber
> > > How annoying. At least my pet hate with the Python REPL is still there
> > > in 2.2 and 2.3.
> >
> > Which is?
It must seem pretty silly for me to hate Python soley on its use of
white space to define block structure.
Then again, if you hate an interface, would you use it if another was
available?
David Steuber
> In article <m2n0c3r...@verizon.net>,
> David Steuber <david....@verizon.net> wrote:
>
> > Try doing this in C++, Python, or whatever:
> >
> > (do ((a 1 b) (b 1 (+ a b)))
> > (nil a)
> > (print a))
>
> I'm no Pythonista, but this works:
>
> a, b = 1, 1
> while 1:
> print a
> a, b = b, (a + b)
>
> because Python has parallel assignment (or the equivalent of psetq).
> The python version is arguably clearer than do, which is a powerful
> general iterative construct. For complex iteration, there's nothing like
> having do and do*, but they are not obvious at first glance.
>
> How about loop for greater clarity than either do or Python?
>
> (loop
> for a = 1 then b
> and b = 1 then (+ a b)
> do (print a))
Taking into account what Gareth posted, I would have to say that
clarity is in the eye of the beholder here. I find the do loop
clearer than the loop macro in this particular case. That loop
doesn't look like Lisp to me. After getting over the for(;;)
construct in C all those years ago, DO doesn't seem so bad at all.
It maps nicely in fact.
Now to go totally lambda, how do I get b to print after the infinite
loop has finished? I want the *entire* sequence :-P
Seriously though, it is surprising just how quickly this loop,
however it is expressed, goes into bignums. My machine and Lisp is
only 32bit but it still impresses me. The machine word size integer
gets over flowed before I can blink.
People should stop saying Lisp is slow. Even the byte compiled CLISP
is pretty bloody fast with bignums. I've heard rumors that CLISP is
even faster than CMUCL in that area.
Andrew Dalke
> Well, for a start Orbitz could never have been realistically coded
> with Python.
Is your word "realistically" based on hardware limitations or language
limitations? That is, is it a limitation of the language or of
the implementation? Suppose there was a type inferencing Python
implementation with the ability to generate native assembly -- would
it be then be realistic? Suppose we wait 5 years (so that hardware
is less of a concern). Would it be realistic then?
Or is it based on social aspects as well? For example, the backers
of the project needed some certainty that it could be done, giving
a good reason to use proven technology over relative newcomers.
> The fact that it could be programmed in Lisp is a testament to the
> greater power and flexibility of Lisp. No amount of arguing could
> speak louder than a proof like that.
What do Travelocity, Expedia, and the other on-line travel systems
use? If it's anything drastically different than a Lisp then your argument
also suggests that other languages (C++? COBOL?, or combinations
like PHP + an Oracle cartridge written in C?) have equal power and
flexibility.
Andrew
da...@dalkescientific.com
Alexander Schmolck
> d95...@nada.kth.se (Björn Lindberg) writes:
>
> > Ingvar Mattsson <ing...@cathouse.bofh.se> writes:
> >
> > > ingvar@gruk$ python
> > > Python 2.1.3 (#1, Sep 7 2002, 15:29:56)
> > > [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
> > > Type "copyright", "credits" or "license" for more information.
> > >
> > > How annoying. At least my pet hate with the Python REPL is still there
> > > in 2.2 and 2.3.
> >
> > Which is?
>
> It treats blank lines differently in an interactive REPL and when
> reading from a file. This makes "type code in file editor and paste
> function to REPL" much harder than it should be.
Try ipython (or C-|).
'as
mik...@ziplip.com
>> Does Orbitz have anything to do with Python?
>> If not, please leave c.l.py off further discussion thereof.
>
> Well, for a start Orbitz could never have been realistically coded
> with Python.
>
> The fact that it could be programmed in Lisp is a testament to the
> greater power and flexibility of Lisp. No amount of arguing could
> speak louder than a proof like that.
>
> jeffrey
Erik Naggum fan?
Where is he anyway? And since we are on the subject of
Lispers missing in action, where is Kent Pitman?
Guido, what did you do with them?
Joe Marshall
> E.N. Fan:
>
>> The fact that it could be programmed in Lisp is a testament to the
>> greater power and flexibility of Lisp. No amount of arguing could
>> speak louder than a proof like that.
>
> What do Travelocity, Expedia, and the other on-line travel systems
> use? If it's anything drastically different than a Lisp then your argument
> also suggests that other languages (C++? COBOL?, or combinations
> like PHP + an Oracle cartridge written in C?) have equal power and
> flexibility.
The ITA engine does a *vastly* more powerful search than either
Travelocity or Expedia.
Kaz Kylheku
> language paradigm. That is, when it becomes more natural to think of
> cake-making as
>
> UD: things
> Gxyz: x is baked at y degrees for z minutes.
> Hx: x is a cake.
> Ix: x is batter.
>
> For all x, ( (Ix & Gx(350)(45)) > Hx )
>
> (i.e. "Everything that's a batter and put into a 350 degree oven for 45
> minutes is a cake")
[ snip ]
>
> ...then lisp will take over the universe.
Lisp does not support that kind of programming out of the box, but
there do exist libraries of reasoning code for Lisp which extend the
language to do this type of thing, e.g. http://lisa.sourceforge.net
When you took that dreaded AI course decades ago in school, the
instructor must have given you a little Prolog-in-Lisp library in
which you did the work.
Hazy recollections of things and events long ago are no substitute for
up to date, accurate facts.
Lisp is not a purely functional language; in fact it has excellent
support for imperative as well as object-oriented programming. It
supports assignment to variables, and all kinds of objects that can be
destructively manipulated: arrays, structures, objects, streams, hash
tables, packages and so forth. Nested expressions in Lisp have a
well-defined order of evaluation, so it is easy to get the order right
when side effects are involved, whereas in purely functional
languages, the order is typically unspecified. Lisp has
short-circuiting logical operators, and many imperative statement-like
forms for conditional selection, iteration and the like. Yes, Lisp
also has a form of GOTO. Folks, it doesn't get much more imperative
than that.
Gareth McCaughan
> Seriously though, it is surprising just how quickly this loop,
> however it is expressed, goes into bignums. My machine and Lisp is
> only 32bit but it still impresses me. The machine word size integer
> gets over flowed before I can blink.
Um, that's not terribly surprising. It only has to do
45 iterations or thereabouts. Even in Python it doesn't
take long to do 45 single-word integer additions. :-)
> People should stop saying Lisp is slow.
> Even the byte compiled CLISP
> is pretty bloody fast with bignums. I've heard rumors that CLISP is
> even faster than CMUCL in that area.
CLISP's bignums are very good, because it incorporates
GMP, which is one of the best bignum libraries around.
Michael Walter
> Here's a more realistic example that illustrates exactly the opposite
> point. Take the task of finding the sum of the square of a bunch of
> numbers.
> Do people really think to themselves when they do this task:
> Umm first make a variable called sum
> then set that variable sum to zero.
> Then get the next number in the list,
> square it,
> add it to the old value of sum,
> store the resulting value into sum,
> then get the next variable,etc....
>
> No they they think: sum up the square of a bunch of numbers.
> This has an almost direct translation to the lisp style:
> (apply '+ (mapcar #'(lambda(x)(* x x)) numlist)).
sum (map (\x -> x ** 2) [1..10])
in Haskell, or
sum (map ((lambda x: x ** 2), range(1,11)))
in Python. But not really sure what point you're trying to make, oh well :)
David Steuber
> David Steuber wrote:
>
> > Seriously though, it is surprising just how quickly this loop,
> > however it is expressed, goes into bignums. My machine and Lisp is
> > only 32bit but it still impresses me. The machine word size integer
> > gets over flowed before I can blink.
>
> Um, that's not terribly surprising. It only has to do
> 45 iterations or thereabouts. Even in Python it doesn't
> take long to do 45 single-word integer additions. :-)
True enough. I never really bothered to count them.
OK, it also takes very little time for the numbers to be wrapping
over to multiple lines :-P
I just tried it on a PowerBook G4 867Mhz using CLISP and it was blink
and you missed it fast. Color me impressed.
Greg Ewing (using news.cis.dfn.de)
> 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)
I think it's more likely that the specialised hardware
they used couldn't keep up in performance with developments
in the widely-used CPUs from Motorola, Intel, etc. who,
because of their large markets, could afford to pour
lots of effort into making them fast. So there came
a time when it was faster to run a Lisp program on
an off-the-shelf CPU than on a Lisp machine.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Kenny Tilton
Scott McKay wrote:
Because the data chompers are C++ (IIRC). :)
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
frr
<Marc.B...@fractalconcept.com> wrote:
>I'm currently working on a Common Lisp typesetting system based on cl-pdf.
>One example of what it can already do is here:
>http://www.fractalconcept.com/ex.pdf
>
>For now I'm working on the layout and low level stuff. But it's a little bit
>soon to think that it will go nowhere, as I hope a lot of people will add TeX
>compatibility packages for it ;-)
>
>BTW note that I'm not rewriting TeX. It's another design with other
>priorities.
What are your priorities then? O:-) What kind of license re you using for it?
Adam Warner
> Here's a more realistic example that illustrates exactly the opposite
> point. Take the task of finding the sum of the square of a bunch of
> numbers.
> Do people really think to themselves when they do this task:
> Umm first make a variable called sum
> then set that variable sum to zero.
> Then get the next number in the list,
> square it,
> add it to the old value of sum,
> store the resulting value into sum,
> then get the next variable,etc....
>
> No they they think: sum up the square of a bunch of numbers.
> This has an almost direct translation to the lisp style:
> (apply '+ (mapcar #'(lambda(x)(* x x)) numlist)).
Here's my direct translation:
(loop for x in numlist sum (* x x))
Regards,
Adam
mik...@ziplip.com
>
>> <mik...@ziplip.com> wrote in message
>> news:BYIFD1LVHXB1ALLZLRH3...@ziplip.com...
>>
>>>In the context of LATEX, some Pythonista asked what the big
>>>successes.
>>
>>
>>>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)
>>>
>>
>>
>> Not true. The servers do get restarted a couple of times
>> a day to get new data loads, which are huge.
How pathetic. "Server farm" notwithstanding, the WHOLE WEB
SITE gets closed for prolonged periods of time. For comparison,
Travelocity and Expedia are up 24/7.
Robert Klemme
"Michael Walter" <c...@leetspeak.org> schrieb im Newsbeitrag
news:bmkl3j$o3spv$1...@ID-88904.news.uni-berlin.de...
> larry wrote:
> > Here's a more realistic example that illustrates exactly the opposite
> > point. Take the task of finding the sum of the square of a bunch of
> > numbers.
> > Do people really think to themselves when they do this task:
> > Umm first make a variable called sum
> > then set that variable sum to zero.
> > Then get the next number in the list,
> > square it,
> > add it to the old value of sum,
> > store the resulting value into sum,
> > then get the next variable,etc....
> >
> > No they they think: sum up the square of a bunch of numbers.
> > This has an almost direct translation to the lisp style:
> > (apply '+ (mapcar #'(lambda(x)(* x x)) numlist)).
> Well..
> sum (map (\x -> x ** 2) [1..10])
> in Haskell, or
> sum (map ((lambda x: x ** 2), range(1,11)))
> in Python. But not really sure what point you're trying to make, oh well
:)
Is this really a question of the language? In Ruby I'd do:
(0..10).inject(0){|sum,e| sum + e*e}
or
(0..10).map{|i|i*i}.inject(0){|sum,i| sum + i}
Not very intuitive, maybe. But if I extend a standard module slightly
module Enumerable
def sum(&b)
inject(0){|sum,i| sum + ( b ? b.call( i ) : i)}
end
end
I can do
(0..10).sum{|i|i*i}
or
(0..10).map{|i|i*i}.sum
That's better. Of course I could then do
module Kernel
def sum(e,&b)
e.sum(&b)
end
end
And thus write
sum(1..10){|i|i*i}
which is untypical for Ruby but similar to the Lisp form.
IMHO familiarity with a language determines how quickly one can come up
with a solution. It's not the similarity of the code and the problem
statement. So *if* people dislike Lisp, I think there must be another
reason.
Kind regards
robert
Ingvar Mattsson
> Ingvar Mattsson <ing...@cathouse.bofh.se> writes:
>
> > > > How annoying. At least my pet hate with the Python REPL is still there
> > > > in 2.2 and 2.3.
> > >
> > > Which is?
>
> It must seem pretty silly for me to hate Python soley on its use of
> white space to define block structure.
You have cut out some aqttributions there.
> Then again, if you hate an interface, would you use it if another was
> available?
I don't "hate python". I strongly dislike some things with it I
consider misfeatures. Blatant differences between the REPL and the
file-reader is one. Indentation-controls-scope is one I have a minor
dislike for (I prefer braces, but indentation doesn't bother me too
much, at least not when I use an editor with decent support for it).
The main reason I write Pyhthon is because for the code I need to
write for work (that may end up being maintained by someone else), I
have a choice between perl and Python and Python is (by far) the
alternative I prefer.
//Ingvar (doesn't mean I like it more than CL, though)
--
"I'm in 386 enchanted mode."
Marc Battyani
"frr" <frr...@telefonica.net> wrote
Easily programmable with a real programming language
Easily embeddable in other software like web servers
Easily extensible
Understandable internals
Good typographic quality
Marc
Bengt Richter
>larry wrote:
>> Here's a more realistic example that illustrates exactly the opposite
>> point. Take the task of finding the sum of the square of a bunch of
>> numbers.
>> Do people really think to themselves when they do this task:
>> Umm first make a variable called sum
>> then set that variable sum to zero.
>> Then get the next number in the list,
>> square it,
>> add it to the old value of sum,
>> store the resulting value into sum,
>> then get the next variable,etc....
>>
>> No they they think: sum up the square of a bunch of numbers.
>> This has an almost direct translation to the lisp style:
>> (apply '+ (mapcar #'(lambda(x)(* x x)) numlist)).
>Well..
> sum (map (\x -> x ** 2) [1..10])
>in Haskell, or
> sum (map ((lambda x: x ** 2), range(1,11)))
Too much line noise ;-)
sum([x*x for x in range(1,11)])
>in Python. But not really sure what point you're trying to make, oh well :)
Regards,
Bengt Richter
Jon S. Anthony
> > Scott McKay wrote:
> >
...
> >> Not true. The servers do get restarted a couple of times
> >> a day to get new data loads, which are huge.
>
> How pathetic. "Server farm" notwithstanding, the WHOLE WEB
> SITE gets closed for prolonged periods of time.
Sounds broken to me - irrespective of any language used.
> For comparison, Travelocity and Expedia are up 24/7.
The sad thing is this is about the only thing they have going for
them.
/Jon
Rmagere
Then I would say that a clearer way to express what a person think is:
(loop for number in numberlist sum (expt number power))
rmagere
--
I saw a better version of this signature type can any one give any
indication?
((lambda (a b)
(if (= (length a) (length b))
(loop with string for x across a and y across b do (format t "~a~a"
x y))
(progn (loop with string for x across a and y across b do (format t
"~a~a" x y))
(format t "~a" (char a (- (length a) 1))))))
"raeehtalcm" "mgr@omi.o")
Raymond Toy
Joe> "Andrew Dalke" <ada...@mindspring.com> writes:
>> E.N. Fan:
>>
>>> The fact that it could be programmed in Lisp is a testament to the
>>> greater power and flexibility of Lisp. No amount of arguing could
>>> speak louder than a proof like that.
>>
>> What do Travelocity, Expedia, and the other on-line travel systems
>> use? If it's anything drastically different than a Lisp then your argument
>> also suggests that other languages (C++? COBOL?, or combinations
>> like PHP + an Oracle cartridge written in C?) have equal power and
>> flexibility.
Joe> The ITA engine does a *vastly* more powerful search than either
Joe> Travelocity or Expedia.
That is my understanding too. But I must say, on a few rare
occasions, I have noticed travelocity listed better fares than
Orbitz. But maybe travelocity had a some special arrangement. Can't
really tell.
Ray
Frank A. Adrian
> No they they think: sum up the square of a bunch of numbers.
> This has an almost direct translation to the lisp style:
> (apply '+ (mapcar #'(lambda(x)(* x x)) numlist)).
Well, they do until they get an exception because the list is too long.
Then they think WTF!?! until a helpful Lisp person tells them to use reduce
instead of apply :-).
faa
Kenny Tilton
> who are used to english, it's just plain different and harder, even if it's
> better. (Ok, that last bit was a value judgement. :)
Fortunately, misinformation does not "stick" very well. ("Oh, it's
/not/ interpreted?" and then they are OK). The trick is getting folks
to the point where they are even looking in Lisp's direction. Which
you already said:
> ... it's hard to convince someone of that if they
> don't actually _use_ it first, and in the end some will probably still think
> it isn't worth the trouble.
Yep. Old habits die hard, tho for many just looking at a page of Lisp
is enough to get them excited. The same syntax that looks like just a
lot of parentheses is ...well, they do not even see the
parenthe-trees, they see in a flash the forest of the beautiful tree
structure. (How's that for fucked-up metaphor?)
I cannot say I have that ability (I saw the parentheses) but I always
suspend disbelief when trying something new just to give it a chance.
Parentheses disappeared /real/ fast.
>... It will take very significant and deep cultural
> and intellectual changes before lisp is ever an overwhelmingly dominant
> language paradigm. That is, when it becomes more natural to think of
> cake-making as....
Wrong. For two reasons. The first is social. Developers move in herds.
So Lisp just has to reach a certain very low threshhold, and then it
will catch fire and be used in Tall Buildings, and then developers
will dutifully march down to the bookstore and buy a new set of
O'Reilly books.
The second is that you are just plain wrong about paradigms. You (and
I!) have used the proedural paradigm so long that we think we think
that way.
Follow my URL to info on my Cells hack. It let's you build normal
applications with a spredsheet paradigm. I just gave a talk on it at
ILC 2003. Sitting in the audience was they guy who gave a talk on
something similar at LUGM 99, when I was sitting in the audience.
Afterwards two people came up to me to tell me about their similar
hacks. They are the future presenters. The original prior art on all
this was Sketchpad in 1962. Now my point:
It is a great paradigm. An order of magnitude better than the
imperative. I kid you not. Nothing brain-bending about it. But we (as
in "almost all of you") still program as if we were writing machine
language.
Why? Because we think that way? Nope. Look at VisiCalc, Lotus 1-2-3
and other real spreadsheet applications used by non-programmers to
build sophisticated models. They are non-programmers and they are
having a ball and it all makes perfect sense to them. So much for
people cannot think functionally / declaratively.
The developer community is not ignoring Cells or COSI or KR or LISA or
Kaleidoscope or Screamer because they do not think that way, but
simply out of habit. Let's not dress up habit as innate-way-we-think.
kenny
Joe Marshall
Travelocity is owned by Sabre and often gets special fares. If you
are travelling between major cities, you can often get one of these
special rates.
Where ITA really rules is in the scope of the search. To give an
example, suppose I want to go from Boston to Los Angeles for
Christmas. I want to leave Boston in the morning of Dec. 20 or 21, I
want to arrive back Dec. 27 or 28 before it gets too late, and, being
a cheapskate, I don't mind stopovers. Oh, yeah, I have a car, so
I could leave from T.F. Green in Providence or from Manchester, NH
if that is cheaper, but I'm meeting someone at LAX.
At ITA, http://www.itasoftware.com/ I enter the above conditions
and get these sorts of results:
US Airways, leave the 21st at 6:30 am., stopover in Pittsburg going
out, arrive noon, leave LAX the 27th at 6:30am, stopover in Philadelphia,
arrive about 4:30 pm.
US Airways, as above, but leave LAX at 10:20am on the 28th and arrive
at 8:45pm.
American, nonstop, leave the 20th at 7:40am, come back the 27th
arriving at 3:45pm
America West, nonstop outbound, leave 8:30 am on the 21st,
come back on either the 27th at 4:15, 5:00, 7:30 or 8:00
or the 28th at 4:15, 5:00, or 7:30 with a stopover in Phoenix.
Prices seem to be around $375 (although there is a true bargain at
$315). Since I had `check availability', I know that I could actually
purchase one of these tickets.
Now let's try Travelocity.
There's a button to `Search all dates for best fares', but then
I can't select a date at all. So I use `I need these specific dates'.
I can only select a single starting airport (so the search is narrower
by about a factor of 3).
I can only select a single departure day and a single return day (a
factor of 4 narrower), so I pick the 20th outbound and the 27th
on return. Since I want to leave in the morning, I pick 7:00 am
for the outbound time, 5:00 pm for the return time. I leave
the maximum connections box unspecified, and I hit search.
Now I get a page asking me to select my outbound flight. Wait a
sec... it didn't check for a matching return flight. There could be a
outbound flight that *would* be a candidate for a round-trip ticket,
but there may not be a matching inbound. By not checking for
a matchup, the search is reduced by the square root.
Lots of flights to choose from, though... but wait... I specified 7:00
am outbound, but I'm seeing 3:00pm, 5:35pm, and 8:30pm flights listed?
It ignored the departure time. Let's see... one of
American Flight 25 nonstop at 7:35am
US Airways flights 491 and 17, one stop, departs 5:30am
US Airways flights 908 and 47, one stop, departs 5:30am
America West flight 405 at 8:30 am
Delta flights 343 and 671, one stop, departs 5:45am
Delta 931/1019, one stop 9:00am
Delta 1725/242, one stop 9:00am
United 165, nonstop 8:30 am
American 2427, one stop, 7:40am
Delta 1035/1564, one stop, 10:30am
the remaining ones have ticket prices `starting at $1900' which is
a bit steep.
Let's say I choose American Flight 25 outbound. At this point,
Travelocity checks for a return flight on American only. ITA checks
other airlines, this isn't absurd: there is a $350 ticket I can
get if I'm willing to combine an `open-jaw' trip from BOS->LAX->PHL
on US Airways with a `one-way' from PHL->BOS on AirTran.
Again, I get a pile of flights outside my arrival window, but
American flight 222 arrives at 3:44 and American 1364/1940 at 8:42.
I don't recall seeing that second one in the ITA results....
oh, here it is, the 225th option on page 8. There's a lot
of flights with Northwest than Travelocity didn't find at all.
By making the user choose the flights in stages, Travelocity severely
restricts the search space. Even so, the search speed is comparable.
For this itinerary I can't tell whether Travelocity is checking the
seat availability. It used to be the case that you could go all the
way through the dialog only to find that you couldn't actually
purchase the ticket.
Let's try something a bit more complicated:
Leave Boston or nearby on Dec 20th, LA for XMAS, and either
Snowbird, or Banff for a week long ski trip on the way back. Better
disallow airport changes so it won't have me land in Utah but depart
from Calgary (yeah, it can generate those if you *want* it to...)
Hard choice! About 590 for SLC, but 660 for Banff...
The Banff one takes me on United from BOS->LAX,
United LAX->YYC, then Air Canada YYC->BOS
Let's try Banff on Travelocity:
One option outbound, Continental to LAX
Two options from LAX to Calgary, Air Canada or Alaska Air
I'll pick Air Canada...
Two options from Calgary to Boston, Air Canada or Delta,
final cost: $1217.
ouch! how about SLC?
Well, it's at least 674, but I can only fly on Delta.
It's kinda fun playing with the advanced queries, and the size of the
search space is mind-boggling. But the grody details of the airline
travel industry are absolutely horrid.
Kenny Tilton
David Steuber wrote:
> "Francis Avila" <franci...@yahoo.com> writes:
>
>
>>Lisp, the language family (or whatever you want to call it), still
>>has this stigma: lambda calculus is not a natural way of thinking.
>
>
> My experience with other wannabe programmers is that any logical
> thought for solving a problem is not a natural way of thinking.
Good point. Hell, look at cooking. You have parallel processing and
subroutines ("While the slaughtered calf bleeds out, prepare
Choco-Jalapena Sauce, p. 254.")[1]
But they get written out in steps, so you get The Divergence Problem.
The fact is, translating from processes we understand independently of
the programming process into machine instructions is Just Plain Hard, no
matter what language one uses.
Imperative languages are cool because one takes a big nested problem and
let us decompose it into a bunch of small steps we can puzzle over one
at a time. But then we end up setting flags and modifying global state
if the process we want to model is more functional or parallel or
whatever in nature. But the alternative is to expand our times to
encompass the greater complexity and confront it all at once. That's
hard, too.
The good news is that these struggles are so much fucking fun.
kenny
[1] No animals were harmed in this disgusting example
Don Geddis
[...about Orbitz.com...]
> How pathetic. "Server farm" notwithstanding, the WHOLE WEB
> SITE gets closed for prolonged periods of time. For comparison,
> Travelocity and Expedia are up 24/7.
Evidence? It's always been up when I've tried to use it. How do you know
the real availability numbers for Orbitz vs. the others? Surely you understand
that we're not just going to take your word for it.
I'd be shocked if a web-based real business like Orbitz wasn't up 24/7.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
People ask me what folly is. I'll tell you what folly is. Is it a kind of
candy?
-- Deep Thoughts, by Jack Handey [1999]
David Steuber
> You have cut out some aqttributions there.
Sorry. There is a balance between over trimming and under trimming.
It is usually no problem to retrieve a previous post from
References. So there really ought not be any confusion.
Christian Lynbech
mike420> You need brains to work for ITA, not lips.
That not is not entirely true, you do need to know some lisp.
:-)
------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Pascal Costanza
> "Christian Lynbech" <christia...@ericsson.com> wrote in message
> news:ofu16cm...@situla.ted.dk.eu.ericsson.se...
>
>>>>>>>"mike420" == mike420 <mik...@ziplip.com> writes:
>>
>>It is still a question of heated debate what actually killed the lisp
>>machine industry.
>>
>>I have so far not seen anybody dipsuting that they were a marvel of
>>technical excellence, sporting stuff like colour displays, graphical
>>user interfaces and laser printers way ahead of anybody else.
>
>
> I think what helped kill the lisp machine was probably lisp: many people
> just don't like lisp, because it is a very different way of thinking that
> most are rather unaccustomed to. Procedural, imperative programming is
> simply a paradigm that more closely matches the ordinary way of thinking
> (ordinary = in non-programming, non-computing spheres of human endevor) than
> functional programming.
Wrong in two ways:
1) Lisp is not a functional programming language.
2) Imperative programming does not match "ordinary" thinking. When you
visit a dentist, do you explain to her each single step she should do,
or do you just say "I would like to have my teeth checked"?
Pascal
Terry Reedy
> >>It is still a question of heated debate what actually killed the
lisp
> >>machine industry.
The premise of this question is that there actually was a lisp-machine
industry (LMI) to be killed. My memory is that is was stillborn and
that the promoters never presented a *convincing* value proposition to
enough potentional customers to really get it off the ground.
and continued:
> >>I have so far not seen anybody dipsuting that they were a marvel
of
> >>technical excellence,
Never having seen one, or read an independent description, I cannot
confirm or 'dipsute' this. But taking this as given, there is the
overlooked matter of price. How many people, Lispers included, are
going to buy, for instance, an advanced, technically excellent,
hydrogen fuel cell car, complete with in-garage hydrogen generator
unit, for, say $200,000.
> >>sporting stuff like colour displays, graphical
> >>user interfaces and laser printers way ahead of anybody else.
I believe these are disputable. The American broadcast industry
switched to color displays in the 50s-60s. Around 1980 there were
game consoles (specialized computers) and small 'general purpose'
computers that piggybacked on color televisions. TV game consoles
thrive today while general PC color computing switched (mid80s) to
computer monitors with the higher resolution needed for text. It was
their use with PCs that brought the price down to where anyone could
buy one.
Did lisp machines really have guis before Xerox and Apple?
Did lisp machine companies make laser printers before other companies
like HP made them for anyone to use? If so, what did they price them
at?
> Francis Avila wrote:
>
> > I think what helped kill the lisp machine was probably lisp: many
people
> > just don't like lisp, because it is a very different way of
thinking that
> > most are rather unaccustomed to.
"Pascal Costanza" <cost...@web.de> responded
> Wrong in two ways:
In relation to the question about the would-be Lisp machine industry,
this answer, even if correct, is besides the point. People buy on the
basis of what they think. One answer may to be that the LMI failed to
enlighten enough people as to the error or their thoughts.
I wonder about another technical issue: intercompatibility. I
strongly believe that media incompatibility helped kill the once
thriving 8080/Z80/CPM industry. (In spite of binary compatibility,
there were perhaps 30 different formats for 5 1/2 floppies.) I
believe the same about the nascent Motorola 68000 desktop Unix
industry of the early 80s. (My work unit has some, and I loved them.)
So I can't help wondering if the LMI made the same blunder.
Did all the LMI companies adopt the same version of Lisp so an outside
Lisper could write one program and sell it to run on all? Or did they
each adopt proprietary versions so they could monopolize what turned
out to be dried-up ponds? Again, did they all adopt uniform formats
for distribution media, such as floppy disks, so that developers could
easily distribute to all? Or did they differentiate to monopolize?
Terry J. Reedy
Joe Marshall
[some opinions and questions about Lisp Machines]
I'm going to take the questions out of order. I'm also leaving the
crosspost in because this is an immediate response to a Pythonista.
> I wonder about another technical issue: intercompatibility. Did all
> the LMI companies adopt the same version of Lisp so an outside
> Lisper could write one program and sell it to run on all?
As a first-order approximation, there really was only one Lisp machine
company: Symbolics. Xerox, Lisp Machine Inc. and TI were minor players
in the market.
Nevertheless, the effort to create a common Lisp specification that
would be portable across all lisp implementations produced ....
Common Lisp. This was in the early 80's while the industry was still
growing.
> The premise of this question is that there actually was a lisp-machine
> industry (LMI) to be killed. My memory is that is was stillborn and
> that the promoters never presented a *convincing* value proposition to
> enough potentional customers to really get it off the ground.
The first principle of marketing is this: the minimum number of
customers needed is one. The Lisp machine customers were typically
large, wealthy companies with a significant investment in research
like petrochemical companies and defense contractors. The Lisp
machine was originally developed as an alternative to the `heavy
metal' of a mainframe, and thus was quite attractive to these
companies. They were quite convinced of the value. The problem was
that they didn't *stay* convinced.
> How many people, Lispers included, are going to buy, for instance,
> an advanced, technically excellent, hydrogen fuel cell car, complete
> with in-garage hydrogen generator unit, for, say $200,000.
Very few. But consider the Ford Motor Company. They have spent
millions of dollars to `buy' exactly that. There are successful
companies whose entire customer base is Ford.
The Lisp industry was small, no doubt about it, but there was (for
a while) enough of an industry to support a company.
mik...@ziplip.com
> mik...@ziplip.com writes:
> [...about Orbitz.com...]
>> How pathetic. "Server farm" notwithstanding, the WHOLE WEB
>> SITE gets closed for prolonged periods of time. For comparison,
>> Travelocity and Expedia are up 24/7.
>
> Evidence?
What evidence would you find acceptable? A court decision? A UN resolution?
> It's always been up when I've tried to use it. How do you know
> the real availability numbers for Orbitz vs. the others? Surely you
> understand that we're not just going to take your word for it.
Ask someone else or write a tiny script to monitor the availability.
Surely you understand that we do not care for your whining like a
helpless little bitch.
Kenny Tilton
Paolo Amoroso
Terry Reedy writes:
> The premise of this question is that there actually was a lisp-machine
> industry (LMI) to be killed. My memory is that is was stillborn and
LMI may be a confusing acronym for that. LMI (Lisp Machines, Inc.) was
just one of the vendors, together with Symbolics, Texas Instruments,
Xerox and a few minor ones (e.g. Siemens).
As for your point, you may check the book:
"The Brain Makers - Genius, Ego, and Greed in the Quest for Machines
that Think"
H.P. Newquist
SAMS Publishing, 1994
ISBN 0-672-30412-0
> that the promoters never presented a *convincing* value proposition to
> enough potentional customers to really get it off the ground.
From page 2 of the above mentioned book:
[...] Symbolics [...] had been able to accomplish in those four
years what billion-dollar computer behemoths like IBM, Hewlett
Packard, and Digital Equipment could not: It had brought an
intelligent machine to market.
>> >>I have so far not seen anybody dipsuting that they were a marvel
> of
>> >>technical excellence,
>
> Never having seen one, or read an independent description, I cannot
> confirm or 'dipsute' this. But taking this as given, there is the
Here are a few relevant Google queries (I am offline and I don't have
the URLs handy):
lisp machines symbolics ralf moeller museum
minicomputer orphanage [see theese PDF documentation sections: mit,
symbolics, ti, xerox]
You may also search for "lisp machine video" at this weblog:
> Did lisp machines really have guis before Xerox and Apple?
Xerox was also a Lisp Machine vendor. If I recall correctly, the first
Lisp Machine was developed at MIT in the mid 1970s, and it had a GUI.
> Did all the LMI companies adopt the same version of Lisp so an outside
> Lisper could write one program and sell it to run on all? Or did they
At least early products of major Lisp Machines vendors were
descendants of the CADR machine developed at MIT.
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Rainer Joswig
> Someone wrote:
> > >>It is still a question of heated debate what actually killed the
> lisp
> > >>machine industry.
>
> The premise of this question is that there actually was a lisp-machine
> industry (LMI) to be killed. My memory is that is was stillborn and
> that the promoters never presented a *convincing* value proposition to
> enough potentional customers to really get it off the ground.
Revenues of Symbolics in 1986 were in the range of about 100 million
dollars. This was probably the peak time.
> Never having seen one, or read an independent description, I cannot
> confirm or 'dipsute' this. But taking this as given, there is the
> overlooked matter of price. How many people, Lispers included, are
> going to buy, for instance, an advanced, technically excellent,
> hydrogen fuel cell car, complete with in-garage hydrogen generator
> unit, for, say $200,000.
Customers were defence industries, research labs, animation companies,
etc.
A machine usable for 3d animation from Symbolics was well in the
$100,000 range. Each 3d software module might have been around
$25,000 - remember that was in years 1985 - 1990.
From then prices went down. The mainstream workstation business model
switched rapidly (to Unix workstations) and Symbolics could not
adopt (and successful) fast enough. They tried by:
- selling a half-assed PC-based solution
- selling VME cards for SUNs
- selling NuBUS cards for Mac II
- and finally selling an emulator for their OS running on DEC Alphas
> I believe these are disputable. The American broadcast industry
> switched to color displays in the 50s-60s. Around 1980 there were
> game consoles (specialized computers) and small 'general purpose'
> computers that piggybacked on color televisions. TV game consoles
> thrive today while general PC color computing switched (mid80s) to
> computer monitors with the higher resolution needed for text. It was
> their use with PCs that brought the price down to where anyone could
> buy one.
Sure, but Symbolics could do 3d animations in full HDTV qualitiy
in 1987 (or earlier?). I've seen animations by Sony or Smarties
done on Lisp machines. Several TV stations did their broadcast
quality logo animations on Lisp machines. The animations
for the ground breaking TRON movie were done on Lisp machines.
Etc.
> Did lisp machines really have guis before Xerox and Apple?
Xerox was producing Lisp machines, too. Of course they
had graphical user interfaces - they were developed at
about the same time as the Smalltalk machines of Xerox.
So, they did not have it before Xerox - they were Xerox. ;-)
MIT Lisp machines had megabit b&w displays with
mouse driven GUIs before the 80s, IIRC. In mid 1980
they switched to a new revolutionary object-oriented graphics
system (Dynamic Windows).
> Did lisp machine companies make laser printers before other companies
> like HP made them for anyone to use? If so, what did they price them
> at?
Symbolics was just reselling Laser printers. The Symbolics OS
could output to Postscript somewhen in mid 1980s - the Concordia
system was a software for book/manual production and could
produce large scale hypertext documents (the Symbolics manual set
had almost 10000 pages) - printing to postscript.
Xerox had of course connected their Lisp machines to their
laser printers.
More stuff on: http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/symbolics.html
Remember, most of that is HISTORY.
Kenny Tilton
> ... The Lisp machine customers were typically
> large, wealthy companies with a significant investment in research
> like petrochemical companies and defense contractors. The Lisp
> machine was originally developed as an alternative to the `heavy
> metal' of a mainframe, and thus was quite attractive to these
> companies. They were quite convinced of the value. The problem was
> that they didn't *stay* convinced.
>
> > How many people, Lispers included, are going to buy, for instance,
> > an advanced, technically excellent, hydrogen fuel cell car, complete
> > with in-garage hydrogen generator unit, for, say $200,000.
Maybe that was part of the problem: all of the Lisp installed base lived
on an expensive platform (unless compared with big iron). When the AI
projects did not deliver, there waa no grass roots safety net to fall
back on and Lisp disappeared from radar in a wink.
This time Lisp is growing slowly, with an early adopter here and an
early adopter there. And this time Lisp requires /no/ special hardware.
And there is a standard so there is no fragmentation. Except of course
that the first thing anyone does after learning Lisp is start a project
to create a new version of Lisp. :)
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
A. Lloyd Flanagan
I believe people don't like Lisp because the Lisp community keeps
writing long, whiny, threads about why people don't like Lisp -- and
posting them in groups that concern entirely different languages.
Rainer Joswig
"Terry Reedy" <tjr...@udel.edu> wrote:
> Did all the LMI companies adopt the same version of Lisp so an outside
> Lisper could write one program and sell it to run on all? Or did they
> each adopt proprietary versions so they could monopolize what turned
> out to be dried-up ponds? Again, did they all adopt uniform formats
> for distribution media, such as floppy disks, so that developers could
> easily distribute to all? Or did they differentiate to monopolize?
(LMI is a name of a Lisp machine company)
Well, all did adopt Common Lisp. The reason for Common Lisp
was to come up with a common Lisp and work against the
fragmentation of the Lisp language. Some very large
software packages (like KEE) were able to run on all
of those. But much of the software has been developed
before Common Lisp (mid 80) in the 70s.
Btw., floppies were not used in the early times - the
machines had tape drives instead.
Pascal Costanza
To recap: Someone asked whether it would make sense to add macros to
Python. He specifically cross-posted this to c.l.l in order to get an
opinion from users of a language that has a long history of supporting
macros.
Some strong claims were made why macros might have been the reason that
Lisp has failed. Lispers dispute that macros are bad in this way and
that Lisp has already failed. That's just a natural progression of such
a discussion.
Pascal
Lars Brinkhoff
> The animations for the ground breaking TRON movie were done on Lisp
> machines.
Many sources say TRON were made using the one and only Foonly F1,
which was a PDP-10 clone.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Kenny Tilton
A. Lloyd Flanagan wrote:
Whoa, that is a rather unpleasant addition to the archives.
What part of the subject line do you not understand? Just ignore us.
Python shares a lot of DNA with Lisp; maybe some Pythonistas would be
interested in knowing their Roots.
Especially if they really like Python and want to enjoy many of its
qualities while undertaking something requiring a full-blown
general-purpose language, they might benefit from knowing that the AI
winter and Lisp's loss of mindshare were accidents of history, not signs
of some flaw in the language.
People don't like Lisp because of misconceptions, and threads like that
help dispel those. That has to be a Good Thing, because NGs like this
are where Early Adopters like Pythonistas learn new things to explore,
even when those things were first conceived in 1956.
kenny
Paolo Amoroso
> From then prices went down. The mainstream workstation business model
> switched rapidly (to Unix workstations) and Symbolics could not
> adopt (and successful) fast enough. They tried by:
> - selling a half-assed PC-based solution
> - selling VME cards for SUNs
What were the names of these products?
Raymond Wiker
> Rainer Joswig writes:
>
>> From then prices went down. The mainstream workstation business model
>> switched rapidly (to Unix workstations) and Symbolics could not
>> adopt (and successful) fast enough. They tried by:
>> - selling a half-assed PC-based solution
>> - selling VME cards for SUNs
>
> What were the names of these products?
The VME thingies were the UX400 and the UX1200; these
correspond to the XL400 and the XL1200 respectively.
The PC-based solution was (I think) more or less just a
run-time environment for applications developed and built on Lisp
machines.
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Rainer Joswig
Raymond Wiker <Raymon...@fast.no> wrote:
> Paolo Amoroso <amo...@mclink.it> writes:
>
> > Rainer Joswig writes:
> >
> >> From then prices went down. The mainstream workstation business model
> >> switched rapidly (to Unix workstations) and Symbolics could not
> >> adopt (and successful) fast enough. They tried by:
> >> - selling a half-assed PC-based solution
> >> - selling VME cards for SUNs
> >
> > What were the names of these products?
>
> The VME thingies were the UX400 and the UX1200; these
> correspond to the XL400 and the XL1200 respectively.
>
> The PC-based solution was (I think) more or less just a
> run-time environment for applications developed and built on Lisp
> machines.
It was called Common Lisp Operating Environment (CLOE).
dan
Lisp failed (yes, it did) because of the parentheses. Normal people
can't parse 13 close-parens easily. Functional notation is
non-intuitive and hard to read.
The world is moving in the direction of languages like Python, that
fit naturally with how we speak and write.
"Francis Avila" <franci...@yahoo.com> wrote in message news:<voobanm...@corp.supernews.com>...
> "Christian Lynbech" <christia...@ericsson.com> wrote in message
> news:ofu16cm...@situla.ted.dk.eu.ericsson.se...
> > >>>>> "mike420" == mike420 <mik...@ziplip.com> writes:
> >
> > It is still a question of heated debate what actually killed the lisp
> > machine industry.
> >
> > I have so far not seen anybody dipsuting that they were a marvel of
> > technical excellence, sporting stuff like colour displays, graphical
> > user interfaces and laser printers way ahead of anybody else.
>
> I think what helped kill the lisp machine was probably lisp: many people
> just don't like lisp, because it is a very different way of thinking that
> most are rather unaccustomed to. Procedural, imperative programming is
> simply a paradigm that more closely matches the ordinary way of thinking
> (ordinary = in non-programming, non-computing spheres of human endevor) than
> functional programming. As such, lisp machines were an oddity and too
> different for many to bother, and it was easy for them to come up with
> excuses not to bother (so that the 'barrier of interest,' so to speak, was
> higher.) Lisp, the language family (or whatever you want to call it), still
> has this stigma: lambda calculus is not a natural way of thinking.
>
> This isn't to make a value judgment, but I think it's an important thing
> that the whole "functional/declarative v. procedural/OO" debate overlooks.
> The same reason why programmers call lisp "mind-expanding" and "the latin of
> programming languages" is the very same reason why they are reluctant to
> learn it--its different, and for many also hard to get used to. Likewise,
> Americans seem to have some repulsive hatred of learning latin--for people
> who are used to english, it's just plain different and harder, even if it's
> better. (Ok, that last bit was a value judgement. :)
>
> Python doesn't try (too) hard to change the ordinary manner of thinking,
> just to be as transparent as possible. I guess in that sense it encourages a
> degree of mental sloth, but the objective is executable pseudocode. Lisp
> counters that thinking the lisp way may be harder, but the power it grants
> is out of all proportion to the relatively meager investment of mental
> energy required--naturally, it's hard to convince someone of that if they
> don't actually _use_ it first, and in the end some will probably still think
> it isn't worth the trouble. It will take very significant and deep cultural
> and intellectual changes before lisp is ever an overwhelmingly dominant
> language paradigm. That is, when it becomes more natural to think of
> cake-making as
>
> UD: things
> Gxyz: x is baked at y degrees for z minutes.
> Hx: x is a cake.
> Ix: x is batter.
>
> For all x, ( (Ix & Gx(350)(45)) > Hx )
>
> (i.e. "Everything that's a batter and put into a 350 degree oven for 45
> minutes is a cake")
>
> ...instead of...
>
> 1. Heat the oven to 350 degrees.
> 2. Place batter in oven.
> 3. Bake 45 minutes
> 4. Remove cake from oven.
>
> (i.e. "To make a cake, bake batter in a 350 degree oven for 45 minutes")
>
> ...then lisp will take over the universe. Never mind that the symbolic
> logic version has more precision.
dan
Kenny Tilton
dan wrote:
> Google ate my long post, so I'll make it simple.
>
> Lisp failed (yes, it did) because of the parentheses. Normal people
> can't parse 13 close-parens easily.
Aaaaannnnnndddd they're off! (for another four hundred messages)
Nobody looks at or counts parentheses, except in languages other than
Lisp. We have editors that not only help keep them straight, but also
let us move chunks of code in the meaningful semantic chunks defined by
parentheses. So editing with parentheses is actually the best possible
way to edit code.
> Functional notation
I do not think you know much about Lisp. Lisp does imperative as well as
functional. It is a multi-paradigm language. I prefer functional,
because it exposes the structure of my algorithm. YMMD.
> is non-intuitive and hard to read.
All code is non-intuitive and hard to read.
> The world is moving in the direction of languages like Python,
And Python is moving in the direction of Lisp, tho I do not know if
Python has abandoned its original modest intentions and now wants to go
all the way and be a full-blown HLL. Already seems perty close, just not
sure if the Mission Statement has been changed.
> fit naturally with how we speak and write.
You only /think/ you speak and write that way because you have written
step-wise code for so long. If you are a real old fart this started with
Fortran and Basic, maybe Assembler.
From the above it is clear you know nothing about Lisp, so of course it
seems strange to you. But don't you think a language an order of
magnitude better than anything else will have to be different enough to
seem strange?
The good news is how fast you will adjust and your old language seems
strange.
Lulu of the Lotus-Eaters
|People don't like Lisp because of misconceptions, and threads like that
|help dispel those.
In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).
As soon as I try to learn more by reading discussions, I am bombarded
with weirdly fanatical (and very long) posts that are overwrought with
many misrepresentations (e.g. Python has "Lisp DNA", when pointedly it
does not by GvR's indication). Not that different Lispers even bother
with the same misrepresentations--just so long as they are clear that
programmers of all other languages are ignorant and stupid.
Or tortured threads about things that are only possible in Lisp... but
as soon as any example is presented, it is obvious that the same thing
is not only possible, but much easier and more direct, in (some) other
languages. Then special pleading accompanies the weaknesses of doing
something in Lisp: you have to use some other distribution (maybe a
really expensive commercial one); if only you wrote these difficult and
huge macros it would be easy; you don't -have- to use the syntax since
the semantics is abstract; you shouldn't want to do -that-, but rather
this other thing; etc.
Yours, Lulu...
--
_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
_/_/ ~~~~~~~~~~~~~~~~~~~~[me...@gnosis.cx]~~~~~~~~~~~~~~~~~~~~~ _/_/
_/_/ The opinions expressed here must be those of my employer... _/_/
_/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them! _/_/
Simon András
> Google ate my long post, so I'll make it simple.
Thank you.
>
> Lisp failed (yes, it did) because of the parentheses. Normal people
> can't parse 13 close-parens easily. Functional notation is
> non-intuitive and hard to read.
Yes, you're right, lisp failed, it's dead, and has been for about two
decades now. (Search google for posts like yours from the last century
to confirm this.) But somehow this doesn't stop it thriving, so it's
probably one of the the healthiest dead languages in the history of
IT.
And of course the culprit is the parantheses. (Thank you for telling
us about it! Dylan people will be especially delighted about the
news.) Although ten years ago it was GC, and before that it was that
it needed special hardware to run at acceptable speed.
It's also true that normal people can't parse 13 close parens. Most
Lispers probably can't either, and they definitely don't. Do
pythonistas count whitespace?
I'm grateful for your concise critique of "functional notation". I
assume you mean prefix notation, and considering that algoloid
languages also use this for functions, you should probably switch to
Forth (too bad you probably think it's dead, too). Silly me, I thought
that the charm of infix notation disappears at functions of arity 3 or
more.
>
> The world is moving in the direction of languages like Python, that
> fit naturally with how we speak and write.
This is _so_ true, I wonder why it reminds me of the following:
"A French politician once wrote that it was a peculiarity of the
French language that in it words occur in the order in which one
thinks them."
Wittgenstein, PI 336
Bye,
Andras
Pascal Costanza
> Kenny Tilton <kti...@nyc.rr.com> wrote previously:
> |People don't like Lisp because of misconceptions, and threads like that
> |help dispel those.
>
> In my own mind, the biggest impediment to really liking Lisp is not the
> annoying parentheses and awful syntax... it's many Lispers (especially
> those like Tilton).
You don't like Lisp because you don't like some other guy who is using it?!?
> As soon as I try to learn more by reading discussions, I am bombarded
> with weirdly fanatical (and very long) posts that are overwrought with
> many misrepresentations (e.g. Python has "Lisp DNA", when pointedly it
> does not by GvR's indication). Not that different Lispers even bother
> with the same misrepresentations--just so long as they are clear that
> programmers of all other languages are ignorant and stupid.
That's just your interpretation of what they say. I think both "sides"
have their fair share of beliefs that they cannot back by argument
and/or empirical assessments. Every language has features that people
have learned to appreciate because of hands-on experience. It's in fact
an esoteric experience in the truest sense of the word: one that cannot
be described in words.
I haven't actually ever used Python in practice, so I can't really tell
whether the syntax or some other features of Python will make me go
eureka when I use them. And I don't care because I already have made
that experience wrt s-expressions and macros, and I hope that I will
never have to go back to a language without macros. All the counter
arguments I have heard so far seem to be made on the basis that people
haven't made that experience yet that I am talking about. Yes, every
language feature has its dangers. What matters is whether the advantages
outweigh the dangers or not. In the case of macros, IMHO you shouldn't
guess, you should just try.
If you are really interested to find out whether macros work in practice
or not, it is extremely easy to do so. Pick one of the free commercial
or non-commercial implementations of Common Lisp, download the free book
"On Lisp" by Paul Graham from his website, try to understand what he is
saying about macros, try to write your own. Maybe you will get it, maybe
not.
These are just my opinions, they are not proven facts. Actually, I don't
really care whether you try it or not. I have made up my mind, and if
someone asks whether macros are useful or not - and this was the start
of this thread - I am going to try to share my experience.
For every discussion, you can concentrate on what are seemingly the most
extreme statements and counter them on the basis that they are too
extreme, or you can try to find out by yourself what actually hides
beneath those statements. (Or you can just ignore a topic if you're not
interested.)
Pascal