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