In the context of LATEX, some Pythonista asked what the big
successes of Lisp were. I think there were at least three *big*
successes.
a. orbitz.com web site uses Lisp for algorithms, etc.
b. Yahoo store was originally written in Lisp.
c. Emacs
The issues with these will probably come up, so I might as well
mention them myself (which will also make this a more balanced
post)
a. AFAIK Orbitz frequently has to be shut down for maintenance
(read "full garbage collection" - I'm just guessing: with
generational garbage collection, you still have to do full
garbage collection once in a while, and on a system like that
it can take a while)
b. AFAIK, Yahoo Store was eventually rewritten in a non-Lisp.
Why? I'd tell you, but then I'd have to kill you :)
c. Emacs has a reputation for being slow and bloated. But then
it's not written in Common Lisp.
Are ViaWeb and Orbitz bigger successes than LATEX? Do they
have more users? It depends. Does viewing a PDF file made
with LATEX make you a user of LATEX? Does visiting Yahoo
store make you a user of ViaWeb?
For the sake of being balanced: there were also some *big*
failures, such as Lisp Machines. They failed because
they could not compete with UNIX (SUN, SGI) in a time when
performance, multi-userism and uptime were of prime importance.
(Older LispM's just leaked memory until they were shut down,
newer versions overcame that problem but others remained)
Another big failure that is often _attributed_ to Lisp is AI,
of course. But I don't think one should blame a language
for AI not happening. Marvin Mins ky, for example,
blames Robotics and Neural Networks for that.
·······@ziplip.com writes:
> 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.
In article <··············@ruckus.brouhaha.com>, Paul Rubin
<·············@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.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@ruckus.brouhaha.com>, Paul Rubin
> <·············@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++! 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 ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
>
>>In article <··············@ruckus.brouhaha.com>, Paul Rubin
>><·············@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
Paul Rubin wrote:
> 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
"Paul Rubin" <·············@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
"Marc Battyani" <·············@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.
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.
--
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.
"David Steuber" <·············@verizon.net> wrote
> "Marc Battyani" <·············@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
"Marc Battyani" <·············@fractalconcept.com> writes:
> 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.
--
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.
On Tue, 14 Oct 2003 18:59:00 +0200, "Marc Battyani"
<·············@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?
[I've set the Followup-to to comp.lang.lisp only]
"frr" <······@telefonica.net> wrote
> On Tue, 14 Oct 2003 18:59:00 +0200, "Marc Battyani"
> <·············@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?
Easily programmable with a real programming language
Easily embeddable in other software like web servers
Easily extensible
Understandable internals
Good typographic quality
Marc
mike420 wrote in message news:<········································@ziplip.com>...
> 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
·······@ziplip.com writes:
> 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.
From: ·············@comcast.net
Subject: Re: BIG successes of Lisp
Date:
Message-ID: <4qyc1dmp.fsf@comcast.net>
·······@ziplip.com writes:
> 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.
·············@comcast.net wrote:
> ·······@ziplip.com writes:
>
>
>>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.
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: ··········@last-name.org
>>>>> "mike420" == mike420 <·······@ziplip.com> writes:
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.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <·················@ericsson.com> writes:
> 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.
"Christian Lynbech" <·················@ericsson.com> wrote in message
···················@situla.ted.dk.eu.ericsson.se...
> >>>>> "mike420" == mike420 <·······@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
"Francis Avila" <·············@yahoo.com> wrote in message
···················@corp.supernews.com...
> "Christian Lynbech" <·················@ericsson.com> wrote in
message
> > It is still a question of heated debate what actually killed the
lisp
> > machine industry.
>
> 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.
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
Terry Reedy wrote:
> 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
In article <················@news1.telusplanet.net>,
Wade Humeniuk <········@nospamtelus.net> wrote:
> Terry Reedy wrote:
>
> > 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
>
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.
"Francis Avila" <·············@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. 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.
--
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.
David Steuber wrote:
> 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
Gareth McCaughan <················@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.
> 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.
--
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.
David Steuber <·············@verizon.net> writes:
> Gareth McCaughan <················@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; ······@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
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> David Steuber <·············@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
Luke Gorrie <····@bluetail.com> writes:
> Ingvar Mattsson <······@cathouse.bofh.se> writes:
>
> > David Steuber <·············@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.
······@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
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> ······@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
·······@nada.kth.se (Bj�rn Lindberg) writes:
> Ingvar Mattsson <······@cathouse.bofh.se> writes:
>
> > ······@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. 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
Ingvar Mattsson <······@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.
Then again, if you hate an interface, would you use it if another was
available?
--
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.
David Steuber <·············@verizon.net> writes:
> Ingvar Mattsson <······@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."
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> 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.
--
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.
On Wed, 15 Oct 2003 19:20:31 GMT, David Steuber
<·············@verizon.net> wrote:
>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?
I don't think it's silly. Fact is that if the people I know are close
to a representative sample, Python will never be *the language*
simply because of the great number of programmers that refuse
to adopt it precisely because of the whitespace issue.
On 2003-10-31 14:24:31, TLOlczyk wrote:
> I don't think it's silly. Fact is that if the people I know are close
> to a representative sample, Python will never be *the language*
> simply because of the great number of programmers that refuse
> to adopt it precisely because of the whitespace issue.
That's right.
Some people don't like some languages because ...
... of the whitespaces.
.. of the parentheses.
... it looks too much like Pascal.
... it looks too much like C.
... it was designed by a hacker.
... it was designed by a committee.
... it was designed in USA.
... it was designed in Europe.
... it is free (as in RMS).
... it is unfree.
That's one of the reasons there are so many languages. It's not the
"use the right tool" thing alone.
And Choice is good. Many programming languages, many editors, ...
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> ·······@nada.kth.se (Bj�rn Lindberg) writes:
>
> > Ingvar Mattsson <······@cathouse.bofh.se> writes:
> >
> > > ······@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
In article <··············@verizon.net>,
David Steuber <·············@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.
Raffael Cavallaro wrote:
> In article <··············@verizon.net>,
> David Steuber <·············@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.
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.
--
Gareth McCaughan
.sig under construc
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> In article <··············@verizon.net>,
> David Steuber <·············@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.
--
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.
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. :-)
> 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.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> 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.
--
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.
"Gareth McCaughan" <················@pobox.com> ha scritto nel messaggio ···················@g.mccaughan.ntlworld.com...
> CLISP's bignums are very good, because it incorporates
> GMP, which is one of the best bignum libraries around.
This is not correct. Clisp uses its own bignum library.
Ciao
P.
"Pierpaolo BERNARDI" <··················@hotmail.com> writes:
> "Gareth McCaughan" <················@pobox.com> ha scritto nel messaggio ···················@g.mccaughan.ntlworld.com...
>
>> CLISP's bignums are very good, because it incorporates
>> GMP, which is one of the best bignum libraries around.
>
> This is not correct. Clisp uses its own bignum library.
So it does! Thanks for correcting a long-standing bug
in my brain. Is it known how CLISP's performance compares
with GMP's?
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <·····@g.local> writes:
> "Pierpaolo BERNARDI" <··················@hotmail.com> writes:
>
> > "Gareth McCaughan" <················@pobox.com> ha scritto nel messaggio ···················@g.mccaughan.ntlworld.com...
> >
> >> CLISP's bignums are very good, because it incorporates
> >> GMP, which is one of the best bignum libraries around.
> >
> > This is not correct. Clisp uses its own bignum library.
>
> So it does! Thanks for correcting a long-standing bug
> in my brain. Is it known how CLISP's performance compares
> with GMP's?
Perhaps if you write the Fibonacci sequence generator using CLISP and
the GMP library you could come up with a case for addition. It is
also important to be able to convert bignums into strings for
printing.
Because of the shear speed of CLISP, you probably want to do a
million iterations to get reliable timings. Then just publish the
code so that people can test it on their machines.
A good bignum library becomes the root for fixed radix arithmetic and
perhaps also arbitrary precession floating point as well. I plan on
using rationals which use bignums in place of reals for complex (as
in (a + bi)) arithmetic.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber wrote:
[I said:]
> > So it does! Thanks for correcting a long-standing bug
> > in my brain. Is it known how CLISP's performance compares
> > with GMP's?
>
> Perhaps if you write the Fibonacci sequence generator using CLISP and
> the GMP library you could come up with a case for addition. It is
> also important to be able to convert bignums into strings for
> printing.
Yes. Multiplication is probably more exciting, since
there's more that can be done to make it dramatically
faster (at least for large numbers). Toom-Cook and
such things.
Of course, you can do Fibonacci in a way that uses
lots of multiplication too, e.g. by raising the matrix
(1 1 ; 1 0) to the n'th power by repeated squaring.
--
Gareth McCaughan
.sig under construc
"Gareth McCaughan" <·····@g.local> ha scritto nel messaggio ···················@g.mccaughan.ntlworld.com...
> "Pierpaolo BERNARDI" <··················@hotmail.com> writes:
> > Clisp uses its own bignum library.
And its own bigfloat library, I forgot to add.
> So it does! Thanks for correcting a long-standing bug
> in my brain. Is it known how CLISP's performance compares
> with GMP's?
When I tested this, several years ago, Clisp was way faster than gmp,
and about equally fast as the INRIA/DEC rational/bignum library
used by ocaml (perhaps it was still caml special, or caml light, at the time).
I understand that gmp since then has been revamped and brought
to the state of the art. I haven't benchmarked the new gmp,
but I expect its performance to be very similar to clisp.
Ciao
P.
David Steuber wrote:
> "Francis Avila" <·············@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
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Francis Avila wrote:
> "Christian Lynbech" <·················@ericsson.com> wrote in message
> ···················@situla.ted.dk.eu.ericsson.se...
>
>>>>>>>"mike420" == mike420 <·······@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
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.
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" <········@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
From: Joe Marshall
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <65ing4n8.fsf@ccs.neu.edu>
"Terry Reedy" <·······@udel.edu> writes:
[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.
Joe Marshall wrote:
> ... 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
"Terry Reedy" <·······@udel.edu> wrote in message news:<······················@comcast.com>...
> 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.
······@corporate-world.lisp.de (Rainer Joswig) writes:
> 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/
Lars Brinkhoff <·········@nocrew.org> writes:
> ······@corporate-world.lisp.de (Rainer Joswig) writes:
> > 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.
I recomend either purchasing or renting the Tron 25th Anniversary
edition so you can see the truth for yourself. Everything you could
possibly want to know about the making of TRON is on that DVD set.
--
Knuth's Tex for the Math-kings of sigma, and pi,
Unix vim for the Server-lords with their O'Reilly tomes,
Word for Mortal Men doomed to die,
Emacs from the Bearded One on his Gnu throne,
In the land of Stallman where free software lies.
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
In the land of Stallman, where free software lies.
--- Raffael Cavallaro
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?
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@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.
--
Raymond Wiker Mail: ·············@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/
In article <··············@raw.grenland.fast.no>,
Raymond Wiker <·············@fast.no> wrote:
> Paolo Amoroso <·······@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).
[followup set to comp.lang.lisp only]
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:
http://lemonodor.com
> 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 <·······@mclink.it>
In article <······················@comcast.com>,
"Terry Reedy" <·······@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.
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)).
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" <·············@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.
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 :)
>
>
> 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" <·············@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.
"Michael Walter" <··@leetspeak.org> schrieb im Newsbeitrag
···················@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
On Thu, 16 Oct 2003 01:25:33 +0200, Michael Walter <··@leetspeak.org> wrote:
>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
Bengt Richter wrote:
> On Thu, 16 Oct 2003 01:25:33 +0200, Michael Walter <··@leetspeak.org>
> wrote:
>
>> 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)])
>
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" ····@omi.o")
Michael Walter wrote:
> 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 :)
I think the point was not 'lisp is better than python', but that
(apply '+ (mapcar #'(lambda(x)(* x x)) numlist))
corresponds more closely to our mental picture of the algorithm 'sum
squares' than an imperative equivalent,
such as
public double sum-squares(double[] array){
double sum = 0;
for (int i = 0; i < array.length; ++i){
sum += array[i] * array[i];
}
return sum;
}
Your haskell and python examples are similarly 'close' to the algorithm.
The first time I wrote a moderately complex program in Scheme, I felt
that reading the code seemed similar to looking directly at a flowchart,
the code _was_ the algorithm, I had never felt that way with similar
java or c++ code. Even after 12 years writing in imperative languages,
and being a scheme/lisp newbie, I find there is much more mental effort
in going from code to algorithm with an imperative language.
larry wrote:
> 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
Hi larry,
> 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
"Francis Avila" <·············@yahoo.com> wrote in message news:<··············@corp.supernews.com>...
> 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.
Given that this thread is Lisp related, and that Python users have had
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 <·······@mclink.it>
"Francis Avila" <·············@yahoo.com> wrote in message news:<··············@corp.supernews.com>...
> 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
http://www.tilton-technology.com/
"Francis Avila" <·············@yahoo.com> wrote in message news:<··············@corp.supernews.com>...
> "Christian Lynbech" <·················@ericsson.com> wrote in message
<snip an enormous long bit of post and re-post>
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.
A. Lloyd Flanagan wrote:
> "Francis Avila" <·············@yahoo.com> wrote in message news:<··············@corp.supernews.com>...
>
>>"Christian Lynbech" <·················@ericsson.com> wrote in message
>
> <snip an enormous long bit of post and re-post>
>
> 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.
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
A. Lloyd Flanagan wrote:
> "Francis Avila" <·············@yahoo.com> wrote in message news:<··············@corp.supernews.com>...
>
>>"Christian Lynbech" <·················@ericsson.com> wrote in message
>
> <snip an enormous long bit of post and re-post>
>
> 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.
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
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@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).
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 _/_/_/
_/_/ ~~~~~~~~~~~~~~~~~~~~[·····@gnosis.cx]~~~~~~~~~~~~~~~~~~~~~ _/_/
_/_/ The opinions expressed here must be those of my employer... _/_/
_/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them! _/_/
Lulu of the Lotus-Eaters wrote:
> 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).
Do you often let the behavior of others control how you think
about technical topics?
Paul
Paul F. Dietz wrote:
>
> Do you often let the behavior of others control how you think
> about technical topics?
>
In a stretched sense of "to control" and "to think" such as is implied by
context, I start with ridding myself of any illusion that my manner of
"thinking about" technical topics could be free from any "control" by the
behavior of other people.
Lulu of the Lotus-Eaters wrote:
> Kenny Tilton <·······@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).
So you would charge right out and use Lisp, except you do not like me?
Hmmmm....
>
> 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).
I phrased that with a vague metaphor precisely to avoid saying anything
about Python's history and motivation, about which I am largely
ignorant. I have no idea where the ideas for garbage collection,
first-class functions, and a MOP came from, but Peter Norvig, a Python
fan, writes:
"Basically, Python can be seen as a dialect of Lisp with "traditional"
syntax (what Lisp people call "infix" or "m-lisp" syntax). One message
on comp.lang.python said "I never understood why LISP was a good idea
until I started playing with python." Python supports all of Lisp's
essential features except macros, and you don't miss macros all that
much because it does have eval, and operator overloading, and regular
expression parsing, so you can create custom languages that way."
That's at: http://www.norvig.com/python-lisp.html
Note that Norvig is not saying how Python ended up so close to Lisp,
just that it has. Me neither/too.
> 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.
Nonsense. We actually hope a few Pythonistas will come help us build up
some free libraries for Lisp to solve a weak point for us. We recognize
Pythonistas as (a) Early Adopters who (b) groove on interactive,
dynamic, powerful languages.
We are recruiting, not flaming.
> 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.
It's funny this never occurred to me, but my own Cells hack uses macros
big time. Here is a before/after in which I manually macroexpanded the
code and spliced the output back into where it would have expanded:
Before:
(make-instance 'boiler1
:temp (cv 20)
:status (c? (if (< (temp self) 100)
:on :off))
:vent (c? (ecase (^status)
(:on :open)
(:off :closed))))
After:
(make-instance 'boiler1
:temp (make-c-variable :value 20)
:status (make-c-dependent
:rule (lambda (c &aux (self (c-model c))
(.cache (c-value c)))
(if (< (temp self) 100) :on :off)))
:vent (make-c-dependent
:rule (lambda (c &aux (self (c-model c))
(.cache (c-value c)))
(ecase (let ((*synapse-factory* nil))
(status self))
(:on :open) (:off :closed)))))
Some observations:
(1) This is an extreme case, because Cells is an ambitious hack. But the
principles are the same for simpler applications
(2) If I did not have macros, I could compress the above 20%, but no more
(3) Expanding the macros exposes implementation details. I use Cells a
lot, and I refactor a lot. Exposing internals is not just a theoretical
no-no, I'd be dead.
(4) So as not to overstate my case, I snipped this clause from the
actual expansion:
:code '((ecase (let ((*synapse-factory* nil))
(status self))
(:on :open) (:off :closed)))
That is just plain scary. What I am doing is not only expanding the user
code into a lambda form, but also generating /this/ code to dynamically
(at run-time) stuff the code's source (in symbolic form, what the macro
gets its hands on at compile-time) into a slot in the cell data
structure to help with debugging at crash-time. (ie, the source level
debugging on my particular implementation could be a lot better (I just
learned they are working on it) but I have anyway worked around that
with macros.
(5) Leaving aside exposed implementation (a fatal problem, mind you) "I
can do that in Python without macros" is /not/ an objection, unless the
code comes out as terse as the "before". One thing we Lispniks should
have emphasized early on is that one thing macros do is compress and
prettify the code. Surely Pythonistas will acknowledge the value of that.
(6) Paul Graham says it better: http://www.paulgraham.com/onlisp.html
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <llri5eh5.fsf@comcast.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> Lulu of the Lotus-Eaters wrote:
>
>> Kenny Tilton <·······@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).
>
> So you would charge right out and use Lisp, except you do not like me?
> Hmmmm....
Keep it up, Kenny. I don't like `Lulu the Lotus Eater' and don't want
him in my club.
Lulu of the Lotus-Eaters wrote:
> Kenny Tilton <·······@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
|> 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).
Pascal Costanza <········@web.de> wrote previously:
|You don't like Lisp because you don't like some other guy who is using
|it?!?
Absolutely! One of the things that is greatest about Python is its
programming community, and its newsgroup. Quite apart from any matters
of syntax or semantics, or OOP vs. FP, or any of that stuff, it's a
heck of a lot nicer working in a language where you can get friendly,
helpful, informative answers to questions... and ones that lack scorn
and contempt.
>From what I can tell, Lisp would be a terrible choice from that POV.
Python is good, but so are, e.g., Ruby or Haskell in slightly different
ways. Perl, PHP, C++, and Java would probably be ranked in descending
order here, but still mostly positive.
The only languages I've seen with truly vindictive and nasty user
communities are Lisp... and VB. It's a strange closeness of the two.
All the more so because VB has a lot of poorly educated, not
particularly bright, user who are merely boastfully defensive about the
only thing they know. To the contrary, I clearly recognize that
Lispers--even most of the most over-the-top rude ones--are startlingly
intelligent. I'm not sure which is worse though... someone like Tilton
is easily smart enough to avoid sophistry, and yet he engages in it.
All that said, I also know that you cannot choose a language ONLY on its
user community. Obviously issues like static/dynamic typing, available
libraries, platform ports, and lots of issues cannot be brushed off.
Even speed of execution occassionally matters.
Yours, Lulu...
--
·····@ _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis _/_/ Postmodern Enterprises _/_/ s r
.cx _/_/ MAKERS OF CHAOS.... _/_/ i u
_/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/ g s
Lulu of the Lotus-Eaters wrote:
> ... someone like Tilton
> is easily smart enough to avoid sophistry, and yet he engages in it.
what is sophistry?
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@nyc.rr.com> writes:
> what is sophistry?
The story goes that in ancient Greece the sophists were recognized
experts on public speaking, who took pride in being able to sway their
audience into any point of view they liked, or got paid for. (Much
like todays "spin doctors", I believe.) This in contrast to the
philosophers, who were the experts on what is True, regardless of
popularity or any pragmatics.
So sophistry usually means something like a lot of fancy talk that
isn't very helpful in establishing what is true, or important, or
right, or bestest of parens and white-space.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>what is sophistry?
>
>
> The story goes that in ancient Greece the sophists were recognized
> experts on public speaking, who took pride in being able to sway their
> audience into any point of view they liked, or got paid for. (Much
> like todays "spin doctors", I believe.) This in contrast to the
> philosophers, who were the experts on what is True, regardless of
> popularity or any pragmatics.
>
> So sophistry usually means something like a lot of fancy talk that
> isn't very helpful in establishing what is true, or important, or
> right, or bestest of parens and white-space.
And it often involved asking questions, whose answers were already known.
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> And it often involved asking questions, whose answers were already known.
>
Guilty! Guilty! Guilty! i did that when I asked someone about using
symbols as initargs instead of keywords on defstructs, when of course
defstruct creates the initargs without offering any overrides, so I knew
the answer: "um, no, those are keywords".
But then I felt my subterfuge would be obvious and it would be
understood to be a clever way to point out that there was a standard
practice the symbol initarg crowd was corrupting in order to calm their
package paranoia (induced by package abuse (necessitated by bad naming)).
kenny "the sophist"
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
|Kenny Tilton <·······@nyc.rr.com> writes:
|> what is sophistry?
Frode Vatvedt Fjeld <······@cs.uit.no> wrote previously:
|The story goes that in ancient Greece the sophists were recognized
|experts on public speaking, who took pride in being able to sway their
|audience into any point of view they liked...
This is a good description of the word. But I think Kenny, in this
case, was making a rather nice joke: Being sophistical by pretending
not to know the word... a slightly self-deprecating self-reference.
If so, I give him many positive points for the meta-discourse.
Yours, Lulu...
--
---[ to our friends at TLAs (spread the word) ]--------------------------
Iran nuclear neocon POTUS patriot Pakistan weaponized uranium invasion UN
smallpox Gitmo Castro Tikrit armed revolution Carnivore al-Qaeda sarin
---[ Gnosis Software ("We know stuff") <·····@gnosis.cx> ]---------------
Lulu of the Lotus-Eaters wrote:
> |Kenny Tilton <·······@nyc.rr.com> writes:
> |> what is sophistry?
>
> Frode Vatvedt Fjeld <······@cs.uit.no> wrote previously:
> |The story goes that in ancient Greece the sophists were recognized
> |experts on public speaking, who took pride in being able to sway their
> |audience into any point of view they liked...
>
> This is a good description of the word. But I think Kenny, in this
> case, was making a rather nice joke: Being sophistical by pretending
> not to know the word... a slightly self-deprecating self-reference.
I was reaching for my dictionary when it occurred to me that coming
clean on my ignorance was the best response/joke I could make. See sig
for my exemplar (whatever that means).
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
"I don't know what 'truculent' means, but if it's good, that's me."
-- Muhammad Ali, without missing a beat, after Howard Cosell
remarked on Ali's sullenness during an interview.
Frode Vatvedt Fjeld wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>what is sophistry?
>
>
> The story goes that in ancient Greece the sophists were recognized
> experts on public speaking, who took pride in being able to sway their
> audience into any point of view they liked, or got paid for.
Oh, OK, thx. That was back in '71, I realized I could argue awesomely on
either side of a debate, and spontaneously lost all interest in
debating. After then...
(Much
> like todays "spin doctors", I believe.) This in contrast to the
> philosophers, who were the experts on what is True, regardless of
> popularity or any pragmatics.
...yes, I went in search of the Tao.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@nyc.rr.com> writes:
> Frode Vatvedt Fjeld wrote:
>> (Much like todays "spin doctors", I believe.) This in contrast to
>> the philosophers, who were the experts on what is True, regardless
>> of popularity or any pragmatics.
>
> ...yes, I went in search of the Tao.
That's easy: http://www.cs.wustl.edu/~schmidt/TAO.html
--
Raymond Wiker Mail: ·············@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/
Raymond Wiker wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Frode Vatvedt Fjeld wrote:
>
>
>>>(Much like todays "spin doctors", I believe.) This in contrast to
>>>the philosophers, who were the experts on what is True, regardless
>>>of popularity or any pragmatics.
>>
>>...yes, I went in search of the Tao.
>
>
> That's easy: http://www.cs.wustl.edu/~schmidt/TAO.html
>
They trademarked TAO? For CORBA?!!!!! <rofl>
"The Tao that can be talked about is not the true Tao."
-- First sentence of the Tao Te Ching
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Frode Vatvedt Fjeld wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> what is sophistry?
>
> The story goes that in ancient Greece the sophists were recognized
> experts on public speaking, who took pride in being able to sway their
> audience into any point of view they liked, or got paid for. (Much
> like todays "spin doctors", I believe.) This in contrast to the
> philosophers, who were the experts on what is True, regardless of
> popularity or any pragmatics.
>
> So sophistry usually means something like a lot of fancy talk that
> isn't very helpful in establishing what is true, or important, or
> right, or bestest of parens and white-space.
>
In Zen and the Art of Motorcycle Maintenance, Robert Pirsig discusses the
philosopher vs sophist debate and to some extent resurrects the honor of
the sophists. According to Pirsig, the sophists thought the most important
question was 'What is Good?'. The philosophers thought the more important
question was 'What is Truth?'. The philosophers seem to have won the
debate, at least in the West. And as they say, the victors write the
history books, so sophistry came to mean fancy arguments intended to evade
or obscure the truth.
For good or ill, the history of western civilization has been driven in
large part by that outcome. In almost every field of human endeavor, we
have brilliant technical solutions to almost every problem. All too often,
the solution only creates another problem. A modern day sophist (a real
one, not the snake oil salemen who have inherited the name) might say with
a certain smugness, "A clever man will do what makes sense, even if it
isn't any good. A wise man will do what is good, even if it doesn't make
any sense."
--
budr at netride dot net
Lulu of the Lotus-Eaters <·····@gnosis.cx> writes:
> The only languages I've seen with truly vindictive and nasty user
> communities are Lisp... and VB.
We are a wicked gang indeed. Actually we were thrown out of the hotel
at the ILC this week because we were harrasing the other guests with
nasty lamda expressions in the elevators!
--
(espen)
Espen Vestre wrote:
> Lulu of the Lotus-Eaters <·····@gnosis.cx> writes:
>
>>The only languages I've seen with truly vindictive and nasty user
>>communities are Lisp... and VB.
>
>
> We are a wicked gang indeed. Actually we were thrown out of the hotel
> at the ILC this week because we were harrasing the other guests with
> nasty lamda expressions in the elevators!
The Savages of comp.lang.lisp!
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
In article <·····················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Espen Vestre wrote:
> > Lulu of the Lotus-Eaters <·····@gnosis.cx> writes:
> >
> >>The only languages I've seen with truly vindictive and nasty user
> >>communities are Lisp... and VB.
> >
> >
> > We are a wicked gang indeed. Actually we were thrown out of the hotel
> > at the ILC this week because we were harrasing the other guests with
> > nasty lamda expressions in the elevators!
>
> The Savages of comp.lang.lisp!
You should have seen the Robocup hooligans at the ILC.
They were bad!!!
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <ptgu5ekq.fsf@comcast.net>
Lulu of the Lotus-Eaters <·····@gnosis.cx> writes:
> I'm not sure which is worse though... someone like Tilton is easily
> smart enough to avoid sophistry, and yet he engages in it.
What can I say? Lisp attracts a more sophistricated kind of programmer.
...it could have something to do with its users.
Now, if just someone would take this thread, and put it further up than
the sun will ever reach...
--
-rune
Incognito, ergo sum.
Rune Steffensen wrote:
> ...it could have something to do with its users.
>
more personal attacks? <yechh> what part of the thread subject do you
not understand? You are reading this thread voluntarily, and your only
contribution is bile. Super.
The fact is, Pythonistas are using python because Java (and C++) did not
meet their needs. ie, thy are not sheep. They think for themselves.
Lispniks consider such folk Deeply Worthy.
This thread arose (in a prior incarnation) only because Python merely
/considered/ macros. Some mis-characterizations of macros arose and a
few of us swung by to say those characterizations did not match our
experience. We (I) do not give a rat's ass if Python adopts macros, but
we have a ball with them and we thought Pythonistas should have the Best
Information before rejecting them.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Pascal Costanza wrote:
> 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.
FWIW, I have used Python in anger, and the textual clarity of my code
was indeed remarkable.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <u1665eox.fsf@comcast.net>
Lulu of the Lotus-Eaters <·····@gnosis.cx> writes:
> Kenny Tilton <·······@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).
Yeah, that Tilton guy....
Hey, he's not looking. Let's all join comp.lang.python and ditch him.
Lulu of the Lotus-Eaters <·····@gnosis.cx> wrote in message news:<·······································@python.org>...
> 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.
It is very strange. The Pythonista in me wonders if Common Lispers
(as a whole) realize what appeals to Python users. But then, their
most coherent marketing story is an attempt to reach those attracted
to Python for its powerful nature, not necessarily the mainstream
Python user.
The big appealing argument in favor of macros is with-open-files. You
set up a block, and the power of macros close the file automagically
when you're done. None of this try/finally madness. The try/finally
is hidden inside the macro.
So you basically have something like:
with_open_file f (filename, 'r'):
# read from f, do what you want;
# once you leave the block it will be autoclosed!
# Even if the clever user reassigns f it will be closed!
(In fact, I keep on wanting to describe Emacs's save-excursion as a
fantasy that you wake up from at the end. The system protects you
from the likely negative consequences of your actions.)
Alex Martelli argued that macros create hidden things that affect code
at-a-distance. But there are CL tools to fix this! I just used
macroexpand to see what with-open-file "really" becomes.
macroexpand(with_open_file f (filename, 'r')) would become something
like:
try:
unique_temp = open(filename, 'r')
f = unique_temp
# do work here with f
finally:
if unique_temp:
unique_temp.close()
Now, I don't know if macros can seriously be done within Python, it's
just a demonstration on how safe macros can make a language.
Another nicety of the lisps is you can have almost whatever names you
like, for functions and variables. Something like "number->string"
could be a name of a function that converts a number into a string.
Everyone gets those destructive Python functions like list.sort()
wrong at first, thinking that it returns a list. Why not have it be
sort!() for something that returns None? Of course, many of these
names would be up to kindly people like Guido & Co, so that coherent
guidelines could ripple through the Python continuum.
It's not absolutely clear if Common Lisp is readable in the small. I
believe the normal CL argument is about readability in the large,
since the Lisps have good abstraction facilities. (This way, you can
"name" nasty pieces of code with simple representations.) Scheme is
very readable in the small; but it's unclear whether it will evolve a
highly used Lisp anytime soon. But in terms of WRITING code, I prefer
Common Lisp even though Python's nicer to read. So a lot of CL is
invisible. In particular, the difficulty of reading CL may be partly
due to CLers removing patterns whenever they come up.
Anyway, just my opinion, as someone with the Pythonic and Lisp DNA.
Hi Lulu of the Lotus-Eaters,
> Kenny Tilton <·······@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).
Sure David. Please don't make this personal as some may be less gracious
in overlooking your failings to even post correctly indented
Python-the-language code when arguing against Lisp and its syntax:
<http://groups.google.com/groups?selm=mailman.1065550637.20363.python-list%40python.org>
Can't even insert four spaces without destroying the semantics of your
code three times in a row? I note you didn't later acknowledge the three
flaws, which indicates that you still couldn't see them when reviewing
your code:
<http://groups.google.com/groups?selm=mailman.1065555441.8896.python-list%40python.org>
You may have more numerous libraries and a larger set of groupies but you
will never have the satisfaction of using a superior language. Please let
me know if this response makes me a shining example of a "truly vindictive
and nasty" Lisp user. Posters to comp.lang.lisp are extremely likely to
receive polite and extraordinary help. For a long time all newbies to
comp.lang.lisp could expect to be humiliated. That time has passed.
Regards,
Adam
Adam Warner <······@consulting.net.nz> wrote previously:
|in overlooking your failings to even post correctly indented
|Python-the-language code when arguing against Lisp and its syntax:
Sure... but just imagine how badly matched my parentheses would have
been had I attempted to post Lisp code.
|You may have more numerous libraries and a larger set of groupies but
|you will never have the satisfaction of using a superior language.
Nah... I think Paul Graham has them lined up around the block, my
groupies only straggle in slowly. Still, do my callous remarks mean
that I will be blocked from downloading other programming language
distributions? Or is it just that I am too doltish to ever really enjoy
the satisfaction of CL?
|Please let me know if this response makes me a shining example of a
|"truly vindictive and nasty" Lisp user.
Not so much. I think my personal posting foibles slightly miss the
point, but the sting in observing them is in good enough humor.
Yours, David...
--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <·····@gnosis.cx> ]--------------------------
Hi David Mertz,
> Sure... but just imagine how badly matched my parentheses would have
> been had I attempted to post Lisp code.
I suspect you pasted in validly formatted Python code:
def categorize_compose(filters, iter):
results = tuple([[] for _ in len(filters)])
for x in iter:
results[compose(filters)(x)].append(x)
return results
Before proceeding to indent it for display:
....def categorize_compose(filters, iter):
.... results = tuple([[] for _ in len(filters)])
.... for x in iter:
.... results[compose(filters)(x)].append(x)
return results
Making this mistake will not affect the semantics of Lisp code. If you had
attempted to indent valid Lisp code you could not have made the same
mistake.
Even if you ultimately remember to indent everything correctly for display
you are still changing the semantics of the program with every interim
indentation change (and an interim failure could leave you with invalid
code). A related issue is moving a block of Python code within a program
and having to fix indentation of every line in the block to avoid changing
its original semantics.
Lisp parentheses combined with form analysis provide enough information to
automatically reformat any arbitrary block of code. Lisp's parentheses and
syntax are one of Lisp's greatest assets (and they also support effortless
code generation). One could say Lisp's syntax is essential for achieving
these aims. One could also say Python's syntax is essential for achieving
its aesthetic aims and markedly distinguishing it from other programming
languages.
Regards,
Adam
|I suspect you pasted in validly formatted Python code:
|Before proceeding to indent it for display:
Nah... that's not the specific error I made. It's plausible, sure. But
I rather hastily wrote the code directly in my newsreader, rather than
in a Python shell or Python-aware editor (and made some other
non-indentation errors in the process too).
Of course, then I copied the same function a couple times to create
variations of the behavior... never noticing the error in each of them.
Definitely a kicking myself moment (as I wrote in the subsequent post...
admittedly not belaboring every individual error).
I -did- do a little bit of Scheme programming lately (I guess before I
was barred from all future downloads :-)). Admittedly, this was
starting from little familiarity with the language (and also I cannot
get my little brain around emacs, and jEdit on my Powerbook doesn't seem
to want to reindent for me--maybe there's a plugin to do that).
I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of misplaced
parentheses (most of the rest were from a fuzziness about the different
between strings and symbols; but I think I've worked that out). I sure
had to stare a LOT longer at those parens (and do lots of counting on my
fingers) than I would have had to look at wrongly indented Python code.
In fact, this much would be true even compared to way back during my
first few weeks of Python programming.
But maybe that error will go away over time. I have some doubts, but
also an open mind.
Yours, David...
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
On Sun, 19 Oct 2003 03:59:07 -0400, ·····@gnosis.cx (David Mertz) wrote:
> I -did- do a little bit of Scheme programming lately (I guess before
> I was barred from all future downloads :-)). Admittedly, this was
> starting from little familiarity with the language (and also I
> cannot get my little brain around emacs, and jEdit on my Powerbook
> doesn't seem to want to reindent for me--maybe there's a plugin to
> do that).
>
> I found that about 70% of the mistakes I made during playing with
> variations on some (pretty simple) functions were because of
> misplaced parentheses (most of the rest were from a fuzziness about
> the different between strings and symbols; but I think I've worked
> that out). I sure had to stare a LOT longer at those parens (and do
> lots of counting on my fingers) than I would have had to look at
> wrongly indented Python code. In fact, this much would be true even
> compared to way back during my first few weeks of Python
> programming.
It is my experience that this definitely goes away very quickly if
you're actually using the language. When I started with Lisp some
years ago I initially had some problems with things like DO, LET, or
COND. It seemed to me as if I would forever have to look up the
definition and count the parens before I could use one of these.
It turned out that this only lasted for a couple of days. In fact,
once you get it, you realize that every single form in Lisp has
exactly the right number of parentheses and as long as you know the
arglist (tools like ILISP will help with that) it's a no-brainer to
know how many parens you'll need. Plus, should I ever make a mistake
with parens I'll notice immediately after hitting RETURN because Emacs
will get the indentation wrong.
As others have pointed out it is _essential_ to use Emacs or an Emacs
clone (like Hemlock or the editors coming with the commercial Lisps)
if you're going to write Lisp programs. Your editor should be able to
at least get the indentation right automatically, it should be able to
show matching parentheses, and it should feature a couple of
convenient ways to navigate through s-exps and lists, see for example
<http://www.google.com/groups?selm=d6d7ef84.fsf%40ccs.neu.edu>.
Edi.
"Edi Weitz" <···@agharta.de> wrote in message
···················@bird.agharta.de...
> It turned out that this only lasted for a couple of days. In fact,
> once you get it, you realize that every single form in Lisp has
> exactly the right number of parentheses and as long as you know the
> arglist (tools like ILISP will help with that) it's a no-brainer to
> know how many parens you'll need.
Last night I accepted the repeated suggestion to download and read
(some of) OnLisp. Problem: I *don't* know the arglist structure of
every form Graham uses, and since Graham assumes such knowledge, I had
to count parens to reverse engineer function prototypes and determine
what is an argument to what. A Python beginner would more easily do
this with Python code.
What is ILISP. Is there a usable online CL reference that would let
me lookup, for instance, DO and get the prototype and short
description?
I will admit that after a few chapters, the parens did begin to fade a
bit. They are a surface issue. I think some others are more
important.
> As others have pointed out it is _essential_ to use Emacs or an
Emacs
> clone (like Hemlock or the editors coming with the commercial Lisps)
> if you're going to write Lisp programs. Your editor should be able
to
> at least get the indentation right automatically, it should be able
to
> show matching parentheses,
Lisp-aware editors do not solve the problem of reading Lisp code
embedded in text, as with OnLisp formatted .ps or .pdf.
Terry J. Reedy
Terry Reedy wrote:
> Lisp-aware editors do not solve the problem of reading Lisp code
> embedded in text, as with OnLisp formatted .ps or .pdf.
I agree. A big wadge of Lisp is not readable like NL text. And having
seen Graham's MOSTN posted here, wow, that is really verbose lisp. With
any Lisp, the indentation increment is just a few characters. I think
one can extend that in many editors, but then the structured nature of
functional code has one sailing off the right margin before too long.
As for reading code, I do not do that in books much, and when I do they
are pretty short examples. When they get bigger, right, I slow down and
destructure mentally. For example, in MOSTN I saw the earliest few lines
were just handling the edge case of a null input list. I moved a couple
of levels into the tree and forgot that outer check (which was
unnecessary!).
I was recommending Chapter's 1 & 8 for well-written thoughts on the
macro issue.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
On Sun, 19 Oct 2003 12:12:37 -0400, "Terry Reedy" <·······@udel.edu> wrote:
> Last night I accepted the repeated suggestion to download and read
> (some of) OnLisp. Problem: I *don't* know the arglist structure of
> every form Graham uses, and since Graham assumes such knowledge, I
> had to count parens to reverse engineer function prototypes and
> determine what is an argument to what. A Python beginner would more
> easily do this with Python code.
Well, "On Lisp" is not a book for beginners. It's a book about the
power of CL macros and was written for people who alread know Common
Lisp.
> What is ILISP.
<http://www.cliki.net/ILISP>
<http://sourceforge.net/projects/ilisp/>
> Is there a usable online CL reference that would let me lookup, for
> instance, DO and get the prototype and short description?
Yes, definitely. Common Lisp has an ANSI standard and the ANSI
standard is available online.[1]
<http://www.lispworks.com/reference/HyperSpec/Front/index.htm>
Be warned that this is a language standard, though. It's not a
textbook written for people who want to learn the language.
Tools like ILISP will allow you do put your cursor on a symbol and
open the corresponding page of the HyperSpec with one keystroke. Or
try something like <http://weitz.de/clhs.html>.
> Lisp-aware editors do not solve the problem of reading Lisp code
> embedded in text, as with OnLisp formatted .ps or .pdf.
Yes, but experience does.
Edi.
[1] Well, technically this is not the ANSI standard (you have to pay
money to ANSI to get it - it's a printed document) but for all
practical purposes it is.
"Edi Weitz" <···@agharta.de> wrote in message
···················@bird.agharta.de...
> > Is there a usable online CL reference that would let me lookup,
for
> > instance, DO and get the prototype and short description?
>
> Yes, definitely. Common Lisp has an ANSI standard and the ANSI
> standard is available online.[1]
>
> <http://www.lispworks.com/reference/HyperSpec/Front/index.htm>
>
> Be warned that this is a language standard, though. It's not a
> textbook written for people who want to learn the language.
Very helpful. I've read the first W&H Lisp on MacLisp, but CL has
lots of new name and syntax symbols, like &rest, :whatever, etc that I
can now look up as needed.
Thanks, Terry J. Reedy
On 19 Oct 2003 18:40:20 +0200, I wrote:
> <http://www.cliki.net/ILISP>
> <http://sourceforge.net/projects/ilisp/>
I should have mentioned that Bill Clementson gave a talk about using
Emacs as a Lisp IDE at ILC 2003 (alas, I wasn't there, but I saw a
draft of his paper) last week. It will be partly available from
<http://cl-cookbook.sf.net/emacs-ide.html>
in a couple of days.
Edi.
Terry Reedy wrote:
>
> ...
> Lisp-aware editors do not solve the problem of reading Lisp code
> embedded in text, as with OnLisp formatted .ps or .pdf.
well, to the extent that they indent consistently, they do. one trains ones
eye to ignore the parentheses. perhaps one may have misinterpretated the
resistance to tyrannical indentation. one very effective way to read lisp
attends to the indentation and ignores the parentheses. the compiler does not
do this, but the eye does. different eyes are trained differently, but the
principle remains.
for instance, if we take m.kowalczyk's example. a competent lisp programmer
could just as readily interpret the text below, as interpret the text with
parentheses. the parenthese are redundant information which aids
disambiguation - eg where numerous forms are on a single line, and corrects
errors, but fairly early on one no longer "reads" them.
defun mostn fn lst
if null lst
values nil nil
let result list car lst
max funcall fn car lst
dolist obj cdr lst
let score funcall fn obj
cond > score max
setq max score
result list obj
= score max
push obj result
values nreverse result max
practice. one suggestion would be to find an old mac and download a copy of
mcl. if you can get along with a mac, it really is the easiest of the lisps to
break in with.
...
Terry Reedy wrote:
> Last night I accepted the repeated suggestion to download and read
> (some of) OnLisp. Problem: I *don't* know the arglist structure of
> every form Graham uses, and since Graham assumes such knowledge, I had
> to count parens to reverse engineer function prototypes and determine
> what is an argument to what. A Python beginner would more easily do
> this with Python code.
Other people have already pointed you to some resources. I have also
liked the book "Common Lisp, The Language - 2nd edition" (CLtL2) by Guy
Steele a lot. It is a snapshot of the then ongoing ANSI standardization
from 1989. The HyperSpec is based on the final ANSI standard, as
published in 1995.
There are some minor differences between CLtL2 and the ANSI standard,
but they are neglectable, especially for a beginner. CLtL2 is generally
more accessible IMHO - better overall structure and more examples. It
feels a little bit like an advanced tutorial. When in doubt, refer to
the HyperSpec.
CLtL2 can be downloaded for free at
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/cltl2.html
> I will admit that after a few chapters, the parens did begin to fade a
> bit. They are a surface issue. I think some others are more
> important.
Yes, exactly.
> Lisp-aware editors do not solve the problem of reading Lisp code
> embedded in text, as with OnLisp formatted .ps or .pdf.
That's right. A good exercise is to type in the code that you find in
the books by yourself. This should make you get a better feel for how to
read Lisp code.
Pascal
On Sun, 19 Oct 2003 13:18:38 +0200, Edi Weitz wrote:
> In fact, once you get it, you realize that every single form in Lisp
> has exactly the right number of parentheses and as long as you know the
> arglist (tools like ILISP will help with that) it's a no-brainer to know
> how many parens you'll need.
The problem is not that I don't know why each paren is there. I know it.
It doesn't help with the fact that there are a lot of them and that code
is not easily readable because of deep nesting.
> As others have pointed out it is _essential_ to use Emacs or an Emacs
> clone (like Hemlock or the editors coming with the commercial Lisps)
> if you're going to write Lisp programs.
What about reading (in books, on WWW)? I guess you would say
"indentation"...
Indentation in Lisp is not clear enough. Let's look at an example from
http://www-users.cs.umn.edu/~gini/aiprog/graham/onlisp.lisp:
(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.
Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):
def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};
| Lisp | Python | above
-------------------------------------------+------+--------+-------
different amounts of indentation | 10 | 4 | 3
at the beginnings of lines | | |
| | |
maximum number of nested parens | 9 | 1 | 4
| | |
maximum number of adjacent closing parens | 5 | 1 | 2
| | |
total number of parens | 60 | 16 | 18
where paren = ()[]{} | | |
This is why I don't find Lisp syntax readable. It requires apparently
3 times more complicated nesting structure to express the same thing.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <······························@knm.org.pl>,
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> Indentation in Lisp is not clear enough. Let's look at an example from
> http://www-users.cs.umn.edu/~gini/aiprog/graham/onlisp.lisp:
>
> (defun mostn (fn lst)
> (if (null lst)
> (values nil nil)
> (let ((result (list (car lst)))
> (max (funcall fn (car lst))))
> (dolist (obj (cdr lst))
> (let ((score (funcall fn obj)))
> (cond ((> score max)
> (setq max score
> result (list obj)))
> ((= score max)
> (push obj result)))))
> (values (nreverse result) max))))
>
> Note that only one pair of adjacent lines is indented by the same amount.
> Other alignments are in the middle of lines.
>
> Here is a straightforward translation into my dream language; note that
> there aren't a lot of parens despite insignificant indentation and despite
> using braces (like C) instead of bracketing keywords (like Pascal):
>
> def mostn Fun [] = [], null;
> def mostn Fun (First\List) {
> var Result = [First];
> var Max = Fun First;
> each List ?Obj {
> let Score = Fun Obj;
> if Score > Max {Max = Score; Result = [Obj]}
> if Score == Max {Result = Obj\Result}
> };
> reversed Result, Max
> };
Isn't your dream-language-pseudocode buggy?
Looks like the first item in the returned result list is included twice.
Anyway, here's some untested Python, it doesn't seem so far from your
dream:
def mostn(fn, lst):
results,maxscore = [],None
for x in lst:
score = fn(x)
if not results or score > maxscore:
results,maxscore = [x],score
elif score == maxscore:
results.append(x)
return results,maxscore
I changed "max" to "maxscore" to avoid shadowing a builtin, and "result"
to "results" to hint better that there may be more than one. Note that
with Python append order there is no need for the reversal.
Probably it would be more Pythonic to do it like this:
def mostn(fn, lst):
scores = [fn(x) for x in lst]
maxscore = max(scores)
results = [x for score,x in zip(scores,lst) if score==maxscore]
return results,maxscore
--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science
David Eppstein wrote:
> In article <······························@knm.org.pl>,
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
...
> > def mostn Fun [] = [], null;
> > def mostn Fun (First\List) {
> > var Result = [First];
> > var Max = Fun First;
> > each List ?Obj {
> > let Score = Fun Obj;
> > if Score > Max {Max = Score; Result = [Obj]}
> > if Score == Max {Result = Obj\Result}
> > };
> > reversed Result, Max
> > };
>
> Isn't your dream-language-pseudocode buggy?
> Looks like the first item in the returned result list is included twice.
Nope. The loop is iterating over List, which is the tail
of the argument. The second line there is destructuring
the argument.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> David Eppstein wrote:
>
>
>>In article <······························@knm.org.pl>,
>> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
>
> ...
>
>>>def mostn Fun [] = [], null;
>>>def mostn Fun (First\List) {
>>> var Result = [First];
>>> var Max = Fun First;
>>> each List ?Obj {
>>> let Score = Fun Obj;
>>> if Score > Max {Max = Score; Result = [Obj]}
>>> if Score == Max {Result = Obj\Result}
>>> };
>>> reversed Result, Max
>>>};
>>
>>Isn't your dream-language-pseudocode buggy?
>>Looks like the first item in the returned result list is included twice.
>
>
> Nope. The loop is iterating over List, which is the tail
> of the argument. The second line there is destructuring
> the argument.
>
But when you get a new max you re-init Result to be a list containg the
Object which produced the new max. And you set max to the new max.
Then, if the score of the obj is equal to the max (it is for the obj
establishing the new max) you cons it onto result. So it is there twice.
You could elif the second test, or initialize result to nil in the
first. or pushnew or... :)
The above is actually in the form of a question, since my brief visit to
Python was a while ago and I did not even get to some of that syntax.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
On Mon, 20 Oct 2003 18:50:48 +0000, Kenny Tilton wrote:
>>>> if Score > Max {Max = Score; Result = [Obj]}
>>>> if Score == Max {Result = Obj\Result}
> But when you get a new max you re-init Result to be a list containg the
> Object which produced the new max. And you set max to the new max.
>
> Then, if the score of the obj is equal to the max (it is for the obj
> establishing the new max) you cons it onto result. So it is there twice.
Ok, perhaps I should have used elsif when designing the language. But it
would not align so nicely.
> The above is actually in the form of a question, since my brief visit to
> Python was a while ago and I did not even get to some of that syntax.
It's not Python. I thought counting parenthesis in Python and Lisp would
be unfair, you would say "surely it has less parens *because* of significant
indentation" (and you would be right that this is one of the reasons),
so I showed my own syntax. It's real.
My point is:
- Lisp *really* has lots of parentheses, by all counts.
- Lisp syntax needs more "ragged" indentation than average syntaxes.
In particular administrative words like let and progn have their own
indentation level.
All syntactic constructs have a closing paren after their last argument.
This implies the necessity of let for multiple variables at once,
otherwise you would have one nesting level for each variable. This implies
that the first variable in a sequence of variables is preceded by let
while others aren't (in most syntaxes when multiple local variables are
introduced, their lines look similar to each other).
The let chain must be broken when another construct intervenes. Similarly
for progn. Let's suppose there is an imperative fragment (I don't have
much experience in Lisp so I'm sorry if my indentation is not what is
recommended):
(progn (f1 ...)
(f2 ...)
(f3 ...)
(f4 ...))
Then we realize that the result of f2 is needed in f4, it shouldn't be
ignored. In most languages the change needed is something like adding
"foo =" before the f2 call. In Lisp it is:
(progn (f1 ...)
(let ((foo (f2 ...)))
(progn (f3 ...)
(f4 ...))))
See why I don't like this syntax? Among f1, f2, f3 & f4 there are 3
distinct horizontal positions, despite these commands being in a logical
sequence in my mind.
Even syntaxes which treat their equivalents of let and progn differently,
e.g. OCaml, looks more pleasantly for me - because it can use syntactic
constructs which don't have a closing marker after their last argument:
f1 ...;
let foo = f2 ... in
f3 ...;
f4 ...
Please don't get me wrong, I like many aspects of Lisp, and I didn't came
here from Python. The thing I dislike the most is unpleasant syntax.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> On Mon, 20 Oct 2003 18:50:48 +0000, Kenny Tilton wrote:
> snip
> (progn (f1 ...)
> (f2 ...)
> (f3 ...)
> (f4 ...))
>
> Then we realize that the result of f2 is needed in f4, it shouldn't be
> ignored. In most languages the change needed is something like adding
> "foo =" before the f2 call. In Lisp it is:
>
> (progn (f1 ...)
> (let ((foo (f2 ...)))
> (progn (f3 ...)
> (f4 ...))))
>
The PROGN inside the LET is unnecessary.
(progn
(f1 ...)
(let ((foo (f2 ...)))
(f3 ...)
(f4 ...)))
But I agree with your point; it is a little cumbersome. On the plus
side, there is no question what the scope of FOO is. In the OCAML
example below, it's less obvious IMO.
BTW, you could write the above as
(let (foo)
(f1 ...)
(setq foo (f2 ...))
(f3 ...)
(f4 ...))
which is not unlike how C would do it:
{
sometype foo;
f1();
foo=f2();
f3();
f4(using foo);
}
> See why I don't like this syntax? Among f1, f2, f3 & f4 there are 3
> distinct horizontal positions, despite these commands being in a logical
> sequence in my mind.
>
> Even syntaxes which treat their equivalents of let and progn differently,
> e.g. OCaml, looks more pleasantly for me - because it can use syntactic
> constructs which don't have a closing marker after their last argument:
>
> f1 ...;
> let foo = f2 ... in
> f3 ...;
> f4 ...
>
Jock Cooper wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
>
>>On Mon, 20 Oct 2003 18:50:48 +0000, Kenny Tilton wrote:
>>snip
>> (progn (f1 ...)
>> (f2 ...)
>> (f3 ...)
>> (f4 ...))
>>
>>Then we realize that the result of f2 is needed in f4, it shouldn't be
>>ignored. In most languages the change needed is something like adding
>>"foo =" before the f2 call. In Lisp it is:
>>
>> (progn (f1 ...)
>> (let ((foo (f2 ...)))
>> (progn (f3 ...)
>> (f4 ...))))
>>
>
>
...
>
> BTW, you could write the above as
> (let (foo)
> (f1 ...)
> (setq foo (f2 ...))
> (f3 ...)
> (f4 ...))
>
Yup. And another question is why not a functional solution?
(f4 ... (f2 ..) ...)
? The only answer could be that amazing side-effects were going on
inside all these fns. In which case the new question is, why not a
functional solution?
What the OP did was (in effect) apply a different paradigmed-language
without changing the paradigm of the solution. aka suicide. if you want
to try something new, give it the best shot possible so you really know
what you are rejecting if that is what you decide. Don't test the
new-fangled airplane by driving it around like a car on the ground in
traffic -- of course the wings are a problem!
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton wrote:
> Yup. And another question is why not a functional solution?
>
> (f4 ... (f2 ..) ...)
>
> ? The only answer could be that amazing side-effects were going on
> inside all these fns. In which case the new question is, why not a
> functional solution?
Programmers have been trained (by C) to not nest side-effecting function
calls, since the meaning (in C) of the expression may be undefined
in cases where order of evaluation matters.
Paul
Paul F. Dietz wrote:
> Kenny Tilton wrote:
>
>> Yup. And another question is why not a functional solution?
>>
>> (f4 ... (f2 ..) ...)
>>
>> ? The only answer could be that amazing side-effects were going on
>> inside all these fns. In which case the new question is, why not a
>> functional solution?
>
>
>
> Programmers have been trained (by C) to not nest side-effecting function
> calls, since the meaning (in C) of the expression may be undefined
> in cases where order of evaluation matters.
I wonder if C was really trying to train them not to write functions
with side effects. :)
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Jock Cooper wrote:
> (progn
> (f1 ...)
> (let ((foo (f2 ...)))
> (f3 ...)
> (f4 ...)))
>
> But I agree with your point; it is a little cumbersome.
There is something worrying me about all this. The real
value I see in all those brackets in a let is that let is
very suitable as a syntax in a target language for
macroexpansion.
To see what I mean, imagine a language "Crowe Lisp" in
which
(let ((a (+ x 7)))
body)
must be written
(single-let a (+ x 7)
body)
and
(let ((a (+ x 7))
(b (+ x 8)))
body)
must be written
(double-let a (+ x 7)
b (+ x 8)
body)
because let in "Crowe Lips" takes a list of three or more
bindings, and will not accept any fewer.
Writing macros for "Crowe Lisp" is a real drag
(defmacro with-bindings ((binding-list) body))
(case (length binding-list)
(1 ... ; use single-let
(2 ... ; use double-let
(t ... ; use let
You really want a bracketty let syntax, because it is more
convenient as a target language for macroexpansion.
But there is a paradox here. If we understand the syntax of
let as being a good thing in a language intended as the
target of macroexpansion, what could be more natural than to
actually write some macros that expand to let
(defmacro slet (variable value-form &rest body)
`(let ((,variable ,value-form)) ,@body))
(progn
(f1 ...)
(slet foo (f2 ...)
(f3 ...)
(f4 ...)))
Much the same reasoning applies to DO
(defmacro twin-do
(counter start increment
accumulator base step
&rest test-and-body)
`(do ((,counter ,start ,increment)
(,accumulator ,base ,step))
,@test-and-body))
Example:
(slet n 6
(twin-do i 1 (+ i 1)
p 1 (* p i)
((> i n) p)))
=>
720
All those brackets in
(let ((n 6))
(do ((i 1 (+ i 1))
(p 1 (* p i)))
((> i n) p)))
are supposed to be helping you when you write the body of
your defmacro, not hindering you when you write the body of
your defun.
I hope I'm not suffering from macro-intoxication :-) I've
been programming since 1973, but the possibilities of macros
are new to me and I might be getting carried away by the
excitement.
Alan Crowe
Alan Crowe wrote:
> I hope I'm not suffering from macro-intoxication :-) I've
> been programming since 1973, but the possibilities of macros
> are new to me and I might be getting carried away by the
> excitement.
Welcome to the club! ;-)
Pascal
Alan Crowe wrote:
> I hope I'm not suffering from macro-intoxication :-) I've
> been programming since 1973, but the possibilities of macros
> are new to me and I might be getting carried away by the
> excitement.
Yes, clear signs of nitrogen narcosis. Ascend 15 levels of parentheses
immediately.
:)
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <7k2zxz1v.fsf@comcast.net>
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> All syntactic constructs have a closing paren after their last argument.
All syntactic constructs are either atomic or a list of syntactic
constructs. A list is indicated by surrounding a series of zero
or more syntactic constructs by parenthesis.
This may seem pedantic, but it is important to understand that the
close parenthesis is not the equivalent of a `semicolon' in a C-like
language.
> This implies the necessity of let for multiple variables at once,
> otherwise you would have one nesting level for each variable.
Nested let forms are semantically *different* forms. The values are
computed in a context where none of the variables are bound. Once
*all* the values have been computed, only then are they bound to the
variables. In a series of nested let expression each nested let is
computed in a context where the previous binding has already been
established.
For convenience, Common Lisp defines the macro LET* that expands into
a nested LET expression.
> This implies that the first variable in a sequence of variables is
> preceded by let while others aren't (in most syntaxes when multiple
> local variables are introduced, their lines look similar to each
> other).
All the bindings in a LET form are enclosed in parenthesis and look
similar to each other. Obviously some bindings textually preceed the
others, but that happens in all languages that have a linear form.
> The let chain must be broken when another construct intervenes.
No. The LET chain must only be broken when a new lexical contour is
necessary. It would be perfectly reasonable (and only somewhat unusual)
to have a LET expression bind a `dummy' variable only for the purpose
of sequencing a side effect during evaluation of the value forms:
(let ((foo 22)
(bar 99)
(dummy (format t "~&About to call QUUX"))
(quux-result (quux))
(dummy2 (format t "~&Finished calling QUUX"))
(baz 42))
...body...)
> Similarly for progn. Let's suppose there is an imperative fragment
> (I don't have much experience in Lisp so I'm sorry if my indentation
> is not what is recommended):
>
> (progn (f1 ...)
> (f2 ...)
> (f3 ...)
> (f4 ...))
>
> Then we realize that the result of f2 is needed in f4, it shouldn't be
> ignored. In most languages the change needed is something like adding
> "foo =" before the f2 call. In Lisp it is:
>
> (progn (f1 ...)
> (let ((foo (f2 ...)))
> (progn (f3 ...)
> (f4 ...))))
>
> See why I don't like this syntax? Among f1, f2, f3 & f4 there are 3
> distinct horizontal positions, despite these commands being in a logical
> sequence in my mind.
These commands may be in logical sequence, but they are not in the
same lexical contour. The new binding FOO is not visible to F1, but
*is* visible to F3 and F4.
There are alternatives:
(let (foo)
(f1 ...)
(setq foo (f2 ...))
(f3 ...)
(f4 ...))
(let* ((f1-result (f1 ...))
(foo (f2 ...))
(f3-result (f3 ...)))
(f4 ...))
> Even syntaxes which treat their equivalents of let and progn differently,
> e.g. OCaml, looks more pleasantly for me - because it can use syntactic
> constructs which don't have a closing marker after their last argument:
>
> f1 ...;
> let foo = f2 ... in
> f3 ...;
> f4 ...
Again, the parenthesis isn't a closing marker, but an *enclosing* marker.
Marcin 'Qrczak' Kowalczyk wrote:
> All syntactic constructs have a closing paren after their last argument.
> This implies the necessity of let for multiple variables at once,
> otherwise you would have one nesting level for each variable. This implies
> that the first variable in a sequence of variables is preceded by let
> while others aren't (in most syntaxes when multiple local variables are
> introduced, their lines look similar to each other).
(defmacro seq (&body forms)
(labels ((classify1 (form) (cons (eq (first form) '<-) form))
(classify (forms) (mapcar #'classify1 forms))
(build-nest (assignment classified-forms bound)
`(let ((,(second assignment) ,(third assignment)))
. ,(build classified-forms (cons (second assignment) bound))))
(build (classified-forms bound)
(let ((result nil))
(loop for ((nest . form) . tail) on classified-forms do
(if nest
(if (member (second form) bound)
(push `(setq ,(second form) ,(third form)) result)
(progn
(push (build-nest form tail bound) result)
(return)))
(push form result)))
(nreverse result))))
(cons 'progn (build (classify forms) nil))))
(seq
(<- a 123)
(<- b 321)
(frobnicate a b)
(<- b 111)
(+ a b))
So if you're bothered by the effects of introducing variables
into PROGN-like constructs, you can solve this problem at a
one-off cost of 18 lines of code. No run-time cost, of course.
> (progn (f1 ...)
> (let ((foo (f2 ...)))
> (progn (f3 ...)
> (f4 ...))))
>
> See why I don't like this syntax? Among f1, f2, f3 & f4 there are 3
> distinct horizontal positions, despite these commands being in a logical
> sequence in my mind.
With the SEQ macro above, you could just write
(setq (f1 ...)
(<- foo (f2 ...))
(f3 ...)
(f4 ...))
But actually one gets used to having sequencing
indicated by horizontal as well as vertical positioning --
which you clearly don't *really* mind, since the bit
of your made-up language that you posted included
{ thing1; thing2; } constructs -- and it's just not
a problem.
For the record, many Lisp constructs come with an
"implicit PROGN". LET is one of them. Thus:
(progn
(f1 ...)
(let ((foo (f2 ...)))
(f3 ...)
(f4 ...)))
which looks pretty good to me. The change in indentation
*does* correspond to something real, namely the scope of FOO.
> Please don't get me wrong, I like many aspects of Lisp, and I didn't came
> here from Python. The thing I dislike the most is unpleasant syntax.
I think that for most of us "unpleasant" means almost
the same as "unfamiliar". Go and find a group of C or C++
programmers and ask them where they like to put their
braces and whitespace. Then stand back and watch. We all
find conventions in these matters "pleasant" when they're
ones we've worked with and grown used to, and "unpleasant"
when they aren't.
--
Gareth McCaughan
.sig under construc
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> (progn (f1 ...)
> (f2 ...)
> (f3 ...)
> (f4 ...))
>
> Then we realize that the result of f2 is needed in f4, it shouldn't be
> ignored. In most languages the change needed is something like adding
> "foo =" before the f2 call. In Lisp it is:
>
> (progn (f1 ...)
> (let ((foo (f2 ...)))
> (progn (f3 ...)
> (f4 ...))))
>
> See why I don't like this syntax? Among f1, f2, f3 & f4 there are 3
> distinct horizontal positions, despite these commands being in a logical
> sequence in my mind.
In Lisp: or:
(progn (let (foo)
(f1 ...) (f1 ...)
(let ((foo (f2 ...))) (setq foo (f2 ...))
(f3 ...) (f3 ...)
(f4 foo ...))) (f4 foo))
In C: or:
{ {
f1(...); type foo;
{ f1(...);
type foo=f2(...); foo=f2(...);
f3(...); f3(...);
f4(foo,...); f4(foo,...);
} }
}
Note that some right parethesis stand for some parenthesis, other
stand for ';' and other stand for '}'.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Lying for having sex or lying for making war? Trust US presidents :-(
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> My point is:
> - Lisp *really* has lots of parentheses, by all counts.
> - Lisp syntax needs more "ragged" indentation than average syntaxes.
> In particular administrative words like let and progn have their own
> indentation level.
>
> All syntactic constructs have a closing paren after their last argument.
> This implies the necessity of let for multiple variables at once,
> otherwise you would have one nesting level for each variable. This implies
> that the first variable in a sequence of variables is preceded by let
> while others aren't (in most syntaxes when multiple local variables are
> introduced, their lines look similar to each other).
But this is a good thing. The indentation always clearly shows the
scope of the (by let) introduced variable bindings. This is a clear
advantage compared to languages where this is not so. At least when
you learn to see it that way.
Bj�rn
Kenny Tilton <·······@nyc.rr.com> writes:
> Gareth McCaughan wrote:
>
> > David Eppstein wrote:
> >
> >>In article <······························@knm.org.pl>,
> >> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> > ...
> >
> >>>def mostn Fun [] = [], null;
> >>>def mostn Fun (First\List) {
> >>> var Result = [First];
> >>> var Max = Fun First;
> >>> each List ?Obj {
> >>> let Score = Fun Obj;
> >>> if Score > Max {Max = Score; Result = [Obj]}
> >>> if Score == Max {Result = Obj\Result}
> >>> };
> >>> reversed Result, Max
> >>>};
> >>
> >>Isn't your dream-language-pseudocode buggy?
> >>Looks like the first item in the returned result list is included twice.
> > Nope. The loop is iterating over List, which is the tail
> > of the argument. The second line there is destructuring
> > the argument.
> >
>
> But when you get a new max you re-init Result to be a list containg
> the Object which produced the new max. And you set max to the new max.
>
> Then, if the score of the obj is equal to the max (it is for the obj
> establishing the new max) you cons it onto result. So it is there
> twice. You could elif the second test, or initialize result to nil in
> the first. or pushnew or... :)
Oh yeah. I failed to notice that. Good catch. He should
have set Result to [] in the first conditional, as I did
in the Lisp code I suggested as an improvement on
Paul Graham's. (Oh, the arrogance!)
> The above is actually in the form of a question, since my brief visit
> to Python was a while ago and I did not even get to some of that
> syntax.
The code isn't in Python, it's in Marcin's non-existent
dream language.
--
Gareth McCaughan
.sig under construc
Marcin 'Qrczak' Kowalczyk wrote:
> Indentation in Lisp is not clear enough. Let's look at an example from
> http://www-users.cs.umn.edu/~gini/aiprog/graham/onlisp.lisp:
>
> (defun mostn (fn lst)
> (if (null lst)
> (values nil nil)
> (let ((result (list (car lst)))
> (max (funcall fn (car lst))))
> (dolist (obj (cdr lst))
> (let ((score (funcall fn obj)))
> (cond ((> score max)
> (setq max score
> result (list obj)))
> ((= score max)
> (push obj result)))))
> (values (nreverse result) max))))
>
> Note that only one pair of adjacent lines is indented by the same amount.
> Other alignments are in the middle of lines.
>
> Here is a straightforward translation into my dream language; note that
> there aren't a lot of parens despite insignificant indentation and despite
> using braces (like C) instead of bracketing keywords (like Pascal):
>
> def mostn Fun [] = [], null;
> def mostn Fun (First\List) {
> var Result = [First];
> var Max = Fun First;
> each List ?Obj {
> let Score = Fun Obj;
> if Score > Max {Max = Score; Result = [Obj]}
> if Score == Max {Result = Obj\Result}
> };
> reversed Result, Max
> };
Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
another verson in Common Lisp (and this is not a dream language ;):
(defmethod mostn (fn (list (eql nil)))
(declare (ignore fn list))
(values nil nil))
(defmethod mostn (fn list)
(loop with result = (list (car list))
with max = (funcall fn (car list))
for object in (cdr list)
for score = (funcall fn object)
when (> score max) do (setq max score
result (list object))
when (= score max) do (push object result)
finally return (values (nreverse result) max)))
Pascal
Pascal Costanza <········@web.de> writes:
> Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
> another verson in Common Lisp (and this is not a dream language ;):
>
> (defmethod mostn (fn (list (eql nil)))
> (declare (ignore fn list))
> (values nil nil))
>
> (defmethod mostn (fn list)
> (loop with result = (list (car list))
> with max = (funcall fn (car list))
> for object in (cdr list)
> for score = (funcall fn object)
> when (> score max) do (setq max score
> result (list object))
> when (= score max) do (push object result)
> finally return (values (nreverse result) max)))
C'mon guys, live a little,
(defun mostn (fn list)
(let ((max (apply #'max (mapcar fn list))))
(values (remove max list :test-not #'= :key fn) max)))
-Luke
Luke Gorrie wrote:
> C'mon guys, live a little,
>
> (defun mostn (fn list)
> (let ((max (apply #'max (mapcar fn list))))
> (values (remove max list :test-not #'= :key fn) max)))
Yes, live a little, get messy. Why is there this insistence that
everything be neat and tidy? (in your dreams) In reality it never is,
that's the beauty of it.
(defun mostn (fn lst)
(let ((mostn-elems nil) (max nil))
(tagbody
find-mostn
(unless (null lst)
(let ((score (funcall fn (car lst))))
(cond
((or (null max) (> score max))
(setf max score mostn-elems (list (car lst))))
((= score max)
(push (car lst) mostn-elems)))
(setf lst (cdr lst))
(go find-mostn))))
(values (nreverse mostn-elems) max)))
Wade
Paul Rubin wrote:
...
> This is untested but looks simpler than the lisp example:
>
> def mostn (fn, lst):
> max = None
> for a in lst:
> score = fn(lst)
Perhaps "score = fn(a)" ?
> if max is None or score > max:
> max = score
> ret = [a]
> elif score == max:
> ret.append(a)
> return ret
it it all right to raise an exception if lst is empty?
I'm not sure of the lisp example's behavior in that case,
but I suspect it returns an empty list and None. In
that case, we may need to initialize ret to [] too.
Stylistically (but it's just me) I don't much like that
"first-time switch" use -- null in lisp, None in Python.
An alternative might be to treat the empty lst as
an exceptional case:
def mostfn(fn, lst):
try: a = lst[0]
except IndexError: return [], None
ret, max = [], fn(a)
for a in lst:
score = fn(a)
if score > max:
max = score
ret = [a]
elif score == max:
ret.append(a)
return ret, max
a _bit_ more complicated than Paul's code, and calls
fn twice on lst[0], but it caters to my dislike for
"first-time switches"...;-). One could remove the
double-call problem by changing the start to:
def mostfn(fn, lst):
it = iter(lst)
try: a = it,next()
except StopIteration: return [], None
ret, max = [a], fn(a)
for a in it:
...
If taking O(N) auxiliary memory was acceptable, of
course, there would be an alternate possibility:
def mostfn(fn, lst):
if not lst: return [], None
aux = [ (fn(a), a) for a in lst ]
Max = max([ f for f, a in aux ])
return [ a for f, a in aux if f==Max ], Max
Typical problem with all high-level languages --
they often make most attractive an approach that
may not be quite as spare of bytes and cycles as
some lower-level one!-) [A simple test with
fn=lambda x:x%333 and lst=range(9999) shows the
lower-level approach is over 3 times faster,
both with and without psyco.proxy on both].
Alex
On Sun, 19 Oct 2003 17:22:17 +0200, Luke Gorrie wrote:
> C'mon guys, live a little,
>
> (defun mostn (fn list)
> (let ((max (apply #'max (mapcar fn list))))
> (values (remove max list :test-not #'= :key fn) max)))
I can write it shorter that way in Python and in my language too, and it's
not even equivalent because it applies fn twice for each element, so my
point stands.
Yours would be a valid point if Lisp provided a significantly different
paradigm. But it was about the syntax of function calls, local variables,
loops, conditionals, variables etc. which are about as common in Lisp as
in those languages.
def mostn(fn, list):
Max = max(map(fn, list))
return [x for x in list if fn(x) == Max], Max
def mostn Fn List {
let Max = map List Fn->maximum;
select List ?X {Fn X == Max}, Max
};
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Pascal Costanza wrote:
>
> Marcin 'Qrczak' Kowalczyk wrote:
>
> > Indentation in Lisp is not clear enough. Let's look at an example from
> > http://www-users.cs.umn.edu/~gini/aiprog/graham/onlisp.lisp:
> >
> > (defun mostn (fn lst)
> > (if (null lst)
> > (values nil nil)
> > (let ((result (list (car lst)))
> > (max (funcall fn (car lst))))
> > (dolist (obj (cdr lst))
> > (let ((score (funcall fn obj)))
> > (cond ((> score max)
> > (setq max score
> > result (list obj)))
> > ((= score max)
> > (push obj result)))))
> > (values (nreverse result) max))))
> >
> > Note that only one pair of adjacent lines is indented by the same amount.
> > Other alignments are in the middle of lines.
> >
> > Here is a straightforward translation into my dream language; note that
> > there aren't a lot of parens despite insignificant indentation and despite
> > using braces (like C) instead of bracketing keywords (like Pascal):
> >
> > def mostn Fun [] = [], null;
> > def mostn Fun (First\List) {
> > var Result = [First];
> > var Max = Fun First;
> > each List ?Obj {
> > let Score = Fun Obj;
> > if Score > Max {Max = Score; Result = [Obj]}
> > if Score == Max {Result = Obj\Result}
> > };
> > reversed Result, Max
> > };
>
> Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
> another verson in Common Lisp (and this is not a dream language ;):
>
> (defmethod mostn (fn (list (eql nil)))
> (declare (ignore fn list))
> (values nil nil))
>
> (defmethod mostn (fn list)
> (loop with result = (list (car list))
> with max = (funcall fn (car list))
> for object in (cdr list)
> for score = (funcall fn object)
> when (> score max) do (setq max score
> result (list object))
> when (= score max) do (push object result)
> finally return (values (nreverse result) max)))
i must admit, that i share this imputed aversion. you see, loop does something
counterproductive in the conventional formatting: it makes language constructs
which have different semantics and/or different scope appear similar. this is
something which m.kowalczyk, despite the thougtful exposition, fails to
understand. to have not been able to characterize the respective indentation
with any more precision than "in the middle of lines" indicates a deficiency
in reading comprehension.
there is a difference between an operator, an argument, a binding, an
antecedant, a consequent, etc. the conventional lisp indentation enables the
literate reader to assign these roles directly upon comprehending the operator
and - surprise, surprise - the indentation, and without having to comprehend
the content of the dependant form. this means that the reader need attend to
the dependant form only if that is their actual focus.
the form of the loop macro interfers with this.
as does the conventional formatting of the posted python example.
ps, if the cond is that simple, one might consider
> > (cond ((> score max) (setq max score result (list obj)))
> > ((= score max) (push obj result)))))
...
On Sun, 19 Oct 2003 16:20:40 +0200, Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> On Sun, 19 Oct 2003 13:18:38 +0200, Edi Weitz wrote:
>
> > In fact, once you get it, you realize that every single form in
> > Lisp has exactly the right number of parentheses and as long as
> > you know the arglist (tools like ILISP will help with that) it's a
> > no-brainer to know how many parens you'll need.
>
> The problem is not that I don't know why each paren is there. I know
> it. It doesn't help with the fact that there are a lot of them and
> that code is not easily readable because of deep nesting.
You have snipped part of my text where I essentially said that it's a
matter of becoming accustomed to the language. It might take a few
days, it might even take a few weeks but that's not much if you want
to use a language professionally. Most Lisp code I see seems to be
easily readable to me. If the nesting is to deep than some things
should be factored out but that's not a problem inherent in Lisp.
> > As others have pointed out it is _essential_ to use Emacs or an
> > Emacs clone (like Hemlock or the editors coming with the
> > commercial Lisps) if you're going to write Lisp programs.
>
> What about reading (in books, on WWW)? I guess you would say
> "indentation"...
Yes.
> Indentation in Lisp is not clear enough.
I guess the right claim would have been "Indentation in Lisp is not
clear enough to me."
> Let's look at an example from
> http://www-users.cs.umn.edu/~gini/aiprog/graham/onlisp.lisp:
>
> (defun mostn (fn lst)
> (if (null lst)
> (values nil nil)
> (let ((result (list (car lst)))
> (max (funcall fn (car lst))))
> (dolist (obj (cdr lst))
> (let ((score (funcall fn obj)))
> (cond ((> score max)
> (setq max score
> result (list obj)))
> ((= score max)
> (push obj result)))))
> (values (nreverse result) max))))
>
> Note that only one pair of adjacent lines is indented by the same
> amount.
So?
> Other alignments are in the middle of lines.
I usually don't do that but I don't see the problem either.
Its the same thing as, say,
short_id = 234;
long_identifier = 12345;
in Algol-like languages - some people do it, some don't. Matter of
fact, your "dream language" also seems to do these nasty things:
> if Score > Max {Max = Score; Result = [Obj]}
> if Score == Max {Result = Obj\Result}
See?
> | Lisp | Python | above
> -------------------------------------------+------+--------+-------
> different amounts of indentation | 10 | 4 | 3
> at the beginnings of lines | | |
> | | |
> maximum number of nested parens | 9 | 1 | 4
> | | |
> maximum number of adjacent closing parens | 5 | 1 | 2
> | | |
> total number of parens | 60 | 16 | 18
> where paren = ()[]{} | | |
>
> This is why I don't find Lisp syntax readable. It requires
> apparently 3 times more complicated nesting structure to express the
> same thing.
Shrug. Do these numbers prove anything? If so, why is it that many
people find Lisp syntax readable? Maybe they're not so good at
counting - so don't tell them what you've found out... :)
Cheers,
Edi.
In article <······························@knm.org.pl>,
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> On Sun, 19 Oct 2003 13:18:38 +0200, Edi Weitz wrote:
>
> > In fact, once you get it, you realize that every single form in Lisp
> > has exactly the right number of parentheses and as long as you know the
> > arglist (tools like ILISP will help with that) it's a no-brainer to know
> > how many parens you'll need.
>
> The problem is not that I don't know why each paren is there. I know it.
> It doesn't help with the fact that there are a lot of them and that code
> is not easily readable because of deep nesting.
>
> > As others have pointed out it is _essential_ to use Emacs or an Emacs
> > clone (like Hemlock or the editors coming with the commercial Lisps)
> > if you're going to write Lisp programs.
>
> What about reading (in books, on WWW)? I guess you would say
> "indentation"...
>
> Indentation in Lisp is not clear enough. Let's look at an example from
> http://www-users.cs.umn.edu/~gini/aiprog/graham/onlisp.lisp:
>
> (defun mostn (fn lst)
> (if (null lst)
> (values nil nil)
> (let ((result (list (car lst)))
> (max (funcall fn (car lst))))
> (dolist (obj (cdr lst))
> (let ((score (funcall fn obj)))
> (cond ((> score max)
> (setq max score
> result (list obj)))
> ((= score max)
> (push obj result)))))
> (values (nreverse result) max))))
I would write that differently - but then.
You know what I see?
Expressions with parentheses at the begin and end.
That's cool.
Why?
**** Because expressions have a clearly visible, stable marker: parentheses. ****
Why is that good?
I can click on them with the mouse and directly manipulate expressions
(mark them, move them, exchange them, transpose them, drag them,
copy them, cut them, ...)
I know where to click when I want to manipulate an expression: on
its parentheses. Directly manipulating GUIs are everywhere - just
your programming language should not support that? How stupid.
Python does not have any visual representing thing for the expression
itself. Where do I click?
I use that feature in Lisp all the time.
There is special support for manipulating expressions with the
mouse in Zmacs (mouse copy), FRED and some other editors.
Wow. People who have hacked on the Lisp Machine or with MCL are
finding that totally cool.
You know, if you hack a while professionally, you make your editor
a tool. Zmacs (and others) + presentations + Lisp syntax is totally cool.
Sure you can hack without editor tools or try to hack tools
for languages that don't have such a nice syntax like Lisp.
But if you really want it hard, you could even type with your
feet.
> Note that only one pair of adjacent lines is indented by the same amount.
> Other alignments are in the middle of lines.
>
> Here is a straightforward translation into my dream language; note that
> there aren't a lot of parens despite insignificant indentation and despite
> using braces (like C) instead of bracketing keywords (like Pascal):
>
> def mostn Fun [] = [], null;
> def mostn Fun (First\List) {
> var Result = [First];
> var Max = Fun First;
> each List ?Obj {
> let Score = Fun Obj;
> if Score > Max {Max = Score; Result = [Obj]}
> if Score == Max {Result = Obj\Result}
> };
> reversed Result, Max
> };
Oh oh. What a mess of a syntax. My eyes are hurt.
>
> | Lisp | Python | above
> -------------------------------------------+------+--------+-------
> different amounts of indentation | 10 | 4 | 3
> at the beginnings of lines | | |
> | | |
> maximum number of nested parens | 9 | 1 | 4
> | | |
> maximum number of adjacent closing parens | 5 | 1 | 2
> | | |
> total number of parens | 60 | 16 | 18
> where paren = ()[]{} | | |
>
> This is why I don't find Lisp syntax readable. It requires apparently
> 3 times more complicated nesting structure to express the same thing.
Rainer Joswig <······@lispmachine.de> writes:
> Expressions with parentheses at the begin and end.
>
> That's cool.
>
> Why?
>
> **** Because expressions have a clearly visible,
> stable marker: parentheses. ****
>
> Why is that good?
>
> I can click on them with the mouse and directly manipulate expressions
> (mark them, move them, exchange them, transpose them, drag them,
> copy them, cut them, ...)
> I know where to click when I want to manipulate an expression: on
> its parentheses.
Not only that's cool, but that's essential to be able to have macro
AND variable-adic operators.
Even if we had only fixed number of operand for each operator, not
having the parenthesis would mean that the macro would have to have
knowledge of the number of argument expected by each operator.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Lying for having sex or lying for making war? Trust US presidents :-(
On Sun, 19 Oct 2003 16:20:40 +0200, Marcin 'Qrczak' Kowalczyk
<······@knm.org.pl> wrote:
>Indentation in Lisp is not clear enough.
*nods* I also find indentation alone isn't really adequate to make the
code clear.
Have you tried using an editor that provides syntax coloring? I find
it's _extremely_ useful in Lisp - more so than in other languages,
because it compensates for the uniform syntax, provides the eye with
something to latch onto.
(It may not be a coincidence that the inventor of the other
uniform-syntax language I know of - Forth - has come up with
ColorForth, an environment that puts a very strong emphasis on
coloring.)
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Hi Marcin 'Qrczak' Kowalczyk,
> What about reading (in books, on WWW)? I guess you would say
> "indentation"...
>
> Indentation in Lisp is not clear enough. Let's look at an example from
> http://www-users.cs.umn.edu/~gini/aiprog/graham/onlisp.lisp:
>
> (defun mostn (fn lst)
> (if (null lst)
> (values nil nil)
> (let ((result (list (car lst)))
> (max (funcall fn (car lst))))
> (dolist (obj (cdr lst))
> (let ((score (funcall fn obj)))
> (cond ((> score max)
> (setq max score
> result (list obj)))
> ((= score max)
> (push obj result)))))
> (values (nreverse result) max))))
>
> Note that only one pair of adjacent lines is indented by the same amount.
> Other alignments are in the middle of lines.
I have ignored the followup-to because your comment is ignorant. If you
want to make ignorant comments please only make them in comp.lang.lisp so
corrections don't also have to be posted to comp.lang.python.
Here is what a Common Lisp users see from the indentation:
1. IF takes a "test" form, a "then" form and in this case an "else"
form. By the indentation I can instantly see that the "test" form is
(null lst), the "then" form is (values nil nil) and the "else" form is:
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
2. LET is binding values to RESULT and MAX. By the indentation I can
instantly see that this binding is in effect for the remainder of the form:
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
3. By the indentation I can also instantly see that the DOLIST is
only operating over:
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
4. I can instantly see that SCORE is bound only within this form:
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
5. And finally I can instantly see that there are two test conditions, the
first being (> score max) and the second (= score max). Again by the
indentation I can see the return results grouped with the test conditions.
In pulling apart these forms there are still dangling parentheses
remaining on the page. That's the point. You can read the semantics
through knowledge of the special forms and the indentation alone. I didn't
attempt to manually delete the parentheses without the assistance
of an appropriate editor because I would probably screw something up. But
it did not stop me from being able to read the code.
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> wrote in message
···································@consulting.net.nz...
> Here is what a Common Lisp users see from the indentation:
Thanks for the helpful folklore lesson. I had sort of understood,
half-conciously what you said. But the following point had me
slightly confused until now. It seems that one-space indents
introduce major new forms, while four-space indents occur within such
forms and may even represent a line continuation. In Python, we do
the opposite: 4 spaces (usually) for major, syntactically significant
indents, and possibly less (or more) for logical line continuations.
And of course, the some-Lisper bashing of Python indents scarely led
me to know that some other Lispers actually ignore the precious parens
and read indents the same way a Pythoneer would.
Terry J. Reedy
Terry Reedy wrote:
> And of course, the some-Lisper bashing of Python indents scarely led
> me to know that some other Lispers actually ignore the precious parens
> and read indents the same way a Pythoneer would.
Yes, the irony is that Lispniks live or die by indentation, we just let
the editor /do/ the indentation. One might say the parens are markup
characters, available to the editor as well as the compiler, by which
programers express the structure of their code.
Very handy after heavy refactoring for auto-reindent, and during
refactoring to drag and drop or just move meaningful code chunks.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@nyc.rr.com> writes:
> Terry Reedy wrote:
> > And of course, the some-Lisper bashing of Python indents scarely led
> > me to know that some other Lispers actually ignore the precious parens
> > and read indents the same way a Pythoneer would.
>
> Yes, the irony is that Lispniks live or die by indentation
No doubt. Lisp code can, and must be, indented cannonically, so any
of us can read it. Probably the only Lisper that doesn't read by the
indentation is McCarthy, who seems to still use m-expressions and was
the only one to present un-indented s-expressions. Wow.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Hi Terry Reedy,
> Thanks for the helpful folklore lesson. I had sort of understood,
> half-consciously what you said. But the following point had me
> slightly confused until now. It seems that one-space indents
> introduce major new forms, while four-space indents occur within such
> forms and may even represent a line continuation. In Python, we do
> the opposite: 4 spaces (usually) for major, syntactically significant
> indents, and possibly less (or more) for logical line continuations.
It depends upon the conventions for the special form. It's usually done to
make the subforms and return value obvious. Consider:
(progn
(fn 1)
(fn 2)
(fn 3))
Versus:
(prog1
(fn 1)
(fn 2)
(fn 3))
PROGN evaluates the forms in order and returns the last (nth)
value (this is standard). PROG1 evaluates the forms in order but
returns the 1st value. The extra indentation on the first form makes
this apparent.
I think 2 additional spaces of indentation is standard for nested forms.
I think indentation after the function name is standard for function
arguments that span more than one line (e.g. all the recent loop examples).
This can be annoying with long function names (e.g. concatenate. As a
related issue, concatenate 'string takes up so much horizontal space that
I now use a macro called `cs' in its place).
Emacs needs to be put in Common Lisp indentation mode so some forms are
indented appropriately (e.g. IF). I didn't realise this initially so you
could find some wrong advice on indenting this function in archives.
It can be so inconvenient when a form is not automatically indented
satisfactorily that I'd rather modify Emacs indentation mode than
manually reformat the form.
Regards,
Adam
Marcin Kowalczyk slept, woke and posted
Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):
def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};
I too dream of designing computer languages. I try to force
myself to understand that these dreams are really
nightmares. I ought not to start from scratch, and anyway,
who would install the compiler for Crowe's Dream Language on
their machine, when I was the only programmer writing in it?
There is a better way. For example, your dream language does
pattern matching on the arguments. Add this to CL with a
macro
(defmacro def-fun-pat (name (&rest arg-pattern) &body code)
`(defun ,name (structured-argument)
(destructuring-bind ,arg-pattern
structured-argument
,@code)))
Then you can say
(def-fun-pat test1 (a (b (c d) e (f)))
(print (list a (+ c d)(funcall f b e))))
(test1 '(foo (bar (5 7) "string" (cons))))
=> (FOO 12 (BAR . "string"))
or
(def-fun-pat test2 (first second third . rest)
(print (+ first second third))
(if (consp rest)
(test2 rest)))
(test2 '(0 1 2 3 4 5 6 7 8))
=>
3
12
21
NIL
This doesn't really work. The point of having patterns in
the argument list is to have a /different/ pattern in each
of several definitions of the function and have the matching
pattern invoked. destructing-bind is a bit of a let down
here. So there is a lot of work to really add this to CL,
and I don't feel competent to attempt it just yet. Also it
is only one of the many features of our dream languages.
On the other hand, saying it is a lot of work is a bit
misleading. It is a tiny amount of work compared to starting
from scratch. The really stunning point is
compatibility. One is part way to ones dream language, with
the feature that ones heart most desired, and yet one is
still within ANSI standard Common Lisp. My examples run on
your machine, but you never downloaded anything from the
Crowe's Dream Language website. This should give you the
same kind of shock as if you saw C++ being compiled on an
old C compiler. Open your heart to the excitment.
Alan Crowe
Alan Crowe wrote:
> There is a better way. For example, your dream language does
> pattern matching on the arguments. Add this to CL with a
> macro
>
> (defmacro def-fun-pat (name (&rest arg-pattern) &body code)
> `(defun ,name (structured-argument)
> (destructuring-bind ,arg-pattern
> structured-argument
> ,@code)))
...
> This doesn't really work. The point of having patterns in
> the argument list is to have a /different/ pattern in each
> of several definitions of the function and have the matching
> pattern invoked. destructing-bind is a bit of a let down
> here. So there is a lot of work to really add this to CL,
> and I don't feel competent to attempt it just yet. Also it
> is only one of the many features of our dream languages.
Here's a slightly less unsatisfactory implementation.
It's not very efficient; a better implementation would
analyse the patterns and build clever recognizing code
for them.
(define-condition patmatch-wrapped-error (error)
((original-error :initarg :original-error
:reader pmwe-original-error)))
(define-condition patmatch-unmatched-error (error) ())
(defmacro wrapping-errors (&body body)
`(handler-case (progn . ,body)
(error (e)
(signal (make-condition 'patmatch-wrapped-error
:original-error e)))))
(defun patmatch-builder (args-sym clauses)
(if (null clauses)
`(signal (make-condition 'patmatch-unmatched-error))
(destructuring-bind (arglist . body)
(first clauses)
`(handler-case
(destructuring-bind ,arglist ,args-sym (wrapping-errors . ,body))
(patmatch-wrapped-error (e)
(error (pmwe-original-error e)))
(error (e)
,(patmatch-builder args-sym (rest clauses)))))))
(defmacro def-patmatch-fun (name &rest clauses)
(let ((args-sym (gensym)))
`(defun ,name (&rest ,args-sym)
,(patmatch-builder args-sym clauses))))
Now you can do
(def-patmatch-fun wibble
(() 123)
((a) (list a))
((a b) (+ a b))
((a b c) (/ a b c)))
and then
(wibble) ==> 123
(wibble 1) ==> (1)
(wibble 1 2) ==> 3
(wibble 1 0 0) produces a division-by-0 error
(wibble 1 2 3 4) produces a patmatch-unmatched-error
Building a more efficient pattern-matching system is
left as an exercise to the reader. I think it's pretty
cool that we can make one that works pretty well in
only 24 lines. I suppose we should add a couple more
to make PATMATCH-UNMATCHED-ERROR instances report
more helpfully.
--
Gareth McCaughan
.sig under construc
On 2003-10-19 12:18:38, Edi Weitz wrote:
> As others have pointed out it is _essential_ to use Emacs or an Emacs
> clone (like Hemlock or the editors coming with the commercial Lisps)
> if you're going to write Lisp programs.
That's another thing why people don't like lisp. :-)
Not everyone wants to use Emacs. Isn't there something like SLIME
for Vim?
Stefan Scholl <······@no-spoon.de> writes:
> On 2003-10-19 12:18:38, Edi Weitz wrote:
>
> > As others have pointed out it is _essential_ to use Emacs or an Emacs
> > clone (like Hemlock or the editors coming with the commercial Lisps)
> > if you're going to write Lisp programs.
>
> That's another thing why people don't like lisp. :-)
>
> Not everyone wants to use Emacs. Isn't there something like SLIME
> for Vim?
Isn't vi slimey enough already?
Gregm
Hi David Mertz,
> |I suspect you pasted in validly formatted Python code:
> |Before proceeding to indent it for display:
>
> Nah... that's not the specific error I made. [...]
OK!
> I found that about 70% of the mistakes I made during playing with
> variations on some (pretty simple) functions were because of misplaced
> parentheses (most of the rest were from a fuzziness about the different
> between strings and symbols; but I think I've worked that out). I sure
> had to stare a LOT longer at those parens (and do lots of counting on my
> fingers) than I would have had to look at wrongly indented Python code.
> In fact, this much would be true even compared to way back during my
> first few weeks of Python programming.
There is not one single gratuitous parenthesis in Lisp. But there are a
number of special forms and before those become hard coded into the brain
it's confusing. For example, consider LET:
(let ((symbol value))
...)
The binding of the symbol to the value is nested within another set
of parentheses because LET handles multiple bindings:
(let ((symbol1 value1)
(symbol2 value2))
...)
There is another less commonly used variation of LET that binds every
symbol to NIL, i.e.:
(let (symbol1 symbol2)
...)
Is shorthand for:
(let ((symbol1 nil)
(symbol2 nil))
...)
After one internalises _why_ each parenthesis is included everything falls
into place. Before that point the parentheses feel like line noise instead
of critical structure. The next step comes with automatic (re-)indentation
of code. To see a fault in a program one can just look at the indentation.
It's at this final point that the parentheses fade from consciousness
(incorrect indentation indicates a problem!)
Code may be slightly more verbose because of the parentheses but they also
encode some of the information required to reconstruct the formatting
of the code. Not having to manually reformat a function (I just press
C-M-q) is a big win.
As this reply was solely about (Common) Lisp I've set the followup-to
comp.lang.lisp only. But I also replied to comp.lang.python so you could
see my reply.
> But maybe that error will go away over time. I have some doubts, but
> also an open mind.
Everyone begins with doubts about Lisp, and the doubts easily intensify
before there is any obvious payback.
Regards,
Adam
From: Joe Marshall
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <r818c8e6.fsf@ccs.neu.edu>
Adam Warner <······@consulting.net.nz> writes:
> A related issue is moving a block of Python code within a program
> and having to fix indentation of every line in the block to avoid
> changing its original semantics.
Python syntax is context-sensitive. Except in limited cases, you
cannot move a subgraph around without having to adjust the context.
> Lisp parentheses combined with form analysis provide enough
> information to automatically reformat any arbitrary block of code.
Lisp syntax is extremely context-free. You can move subgraphs around
at will.
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. 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" <·············@yahoo.com> wrote in message news:<··············@corp.supernews.com>...
> "Christian Lynbech" <·················@ericsson.com> wrote in message
> ···················@situla.ted.dk.eu.ericsson.se...
> > >>>>> "mike420" == mike420 <·······@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 wrote:
> The world is moving in the direction of languages like Python
Yes, and that's a good thing.
It's a good thing because it means that static approaches are replaced
by dynamic approaches.
Pascal
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <3cdq6ti9.fsf@comcast.net>
·········@yahoo.com (dan) writes:
> 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. Functional notation is
> non-intuitive and hard to read.
Damn, but I wish we'd noticed that! It would have saved us such
trouble. Who'd have thought that it was something as simple as
parenthesis?
I'm really surprised that McCarthy didn't realize this and invent some
sort of meta-language for lisp that resembled FORTRAN. Why didn't
someone with expertise in the translation of English into logical
expressions, like Vaughn Pratt for example, *do* something about this?
Perhaps we should have used curly braces?
> The world is moving in the direction of languages like Python, that
> fit naturally with how we speak and write.
That is to say:
world.MovingDirection = fit(we.speak() and \
we.write, fitfunctions.Naturally))
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. 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" <·············@yahoo.com> wrote in message news:<··············@corp.supernews.com>...
> "Christian Lynbech" <·················@ericsson.com> wrote in message
> ···················@situla.ted.dk.eu.ericsson.se...
> > >>>>> "mike420" == mike420 <·······@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 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.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
·········@yahoo.com (dan) writes:
> 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
······@math.bme.hu (Simon Andr�s) writes:
> ·········@yahoo.com (dan) writes:
>
> > 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.
Yep, it's completeley dead:
http://www.informatimago.com/users/pascal/dead-lambda.png
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Lying for having sex or lying for making war? Trust US presidents :-(
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <y8vi5euk.fsf@comcast.net>
······@math.bme.hu (Simon Andr�s) writes:
> 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?
Apparently they do. Religiously in fact. (Do they have a choice?)
·············@comcast.net writes:
> ······@math.bme.hu (Simon Andr�s) writes:
>
>> 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?
>
> Apparently they do. Religiously in fact. (Do they have a choice?)
I write quite a lot of Python at work, and I *never* count
whitespace. I count parens in Lisp more often than spaces
in Python. Heck, I count parens in *Python* more often than
spaces in Python.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <·····@g.local> writes:
> ·············@comcast.net writes:
>
> > ······@math.bme.hu (Simon Andr�s) writes:
> >
> >> 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?
> >
> > Apparently they do. Religiously in fact. (Do they have a choice?)
>
> I write quite a lot of Python at work, and I *never* count
> whitespace. I count parens in Lisp more often than spaces
> in Python. Heck, I count parens in *Python* more often than
> spaces in Python.
>
I assume your editor is counting the whitespace for you? Why is
having the editor count parens in Lisp any different?
I haven't counted parens or braces in any language since I started
using Emacs years ago.
Gregm
Greg Menke <··········@toadmail.com> writes:
> Gareth McCaughan <·····@g.local> writes:
>
> > ·············@comcast.net writes:
> >
> > > ······@math.bme.hu (Simon Andr�s) writes:
> > >
> > >> 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?
> > >
> > > Apparently they do. Religiously in fact. (Do they have a choice?)
> >
> > I write quite a lot of Python at work, and I *never* count
> > whitespace. I count parens in Lisp more often than spaces
> > in Python. Heck, I count parens in *Python* more often than
> > spaces in Python.
> >
>
> I assume your editor is counting the whitespace for you? Why is
> having the editor count parens in Lisp any different?
It isn't. I wasn't arguing that Python is better than
Lisp or that Lisp is bad because you have to count parens.
I was just correcting what looked to me like a very
incorrect statement.
> I haven't counted parens or braces in any language since I started
> using Emacs years ago.
Bingo. Complaining about Lisp because "you have to
count parens", about Python because "you have to count
spaces", or about C++ "because you have to count
braces", is daft. Counting delimiters is a tiny
fraction of what an experienced user of *any*
language does.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <·····@g.local> writes:
> I write quite a lot of Python at work, and I *never* count
> whitespace. I count parens in Lisp more often than spaces
> in Python. Heck, I count parens in *Python* more often than
> spaces in Python.
the only times I can remember having counted parens in my lisp programs
the last year, they were SQL parens inside a string in my program...
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> the only times I can remember having counted parens in my lisp programs
> the last year, they were SQL parens inside a string in my program...
I got tired of doing even that -
(collecting
(for-each-row
(((name 'artist)
(index 'artist-index))
:from 'f_event
:distinct t
:where `(and (> DATE ,(get-universal-time))
(like "" affiliate-name))
:order-by 'artist-index)
(unless (equal last index)
(setf last index)
(collect (list name index))))))
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
·········@yahoo.com (dan) writes:
> Lisp failed (yes, it did) because of the parentheses. Normal people
Lisp hasn't failed as long as emacs is around, and uses Lisp.
Actually, one of the problems with Lisp might be the steep learning
curve. Lisp does not offer the instant appeal of Python. The most
common initial impression of Lisp is "yuck" (parens), while w/ Python
it's mostly "wow, I didn't know code could be so readable and
powerful" (though the whitespace is sometimes an issue, the shock
might last for several minutes).
Now that neither Lisp not Python has the idustry-dominating status
(unlike Java, C++), instant appeal matters a lot. If people are
expected to hop in as a hobby, Python wins hands down. It takes just
3-4 toilet sessions (if you have the habit of reading in toilet) to
master Python, whereas w/ Lisp you have to hack the code for a
while. And still, you can't read the code fast enough; it's fast
enough to write, but reading can be painful initially (unlike perl,
where the pain lasts indefinitely).
Lisp offers a bit more power than Python (macros), but after a while
with Python, one notices that none of the power that is missing is
actually even needed. Python has just the right
features. Period. There are one or two warts (dangling variable after
list comprehensions comes to mind), but the language as a whole feels
natural. Lisp feels natural if you are writing a compiler or want to
be as orthogonal as possible, Python feels natural for most (all
except drivers/applications with extreme performance requirements) of
the real world applications.
> The world is moving in the direction of languages like Python, that
> fit naturally with how we speak and write.
Yes it is; that doesn't mean that Lisp would be dead after a while. At
least not until emacs supports Python natively :-). Seriously though,
Lisp is one of the more programmer centric (== least evil) languages
around, loved by programmers and shunned by the managers. If Python
(and ruby, which I view mostly as a Python with different syntax)
weren't around, Lisp would be the language of choice for most
pythoneers.
Hmm, I guess I should leave usenet alone on saturday nights, but what
the heck :-).
--
Ville Vainio http://www.students.tut.fi/~vainio24
Ville Vainio <······················@spamtut.fi> writes:
> Lisp offers a bit more power than Python (macros), but after a while
> with Python, one notices that none of the power that is missing is
> actually even needed. Python has just the right
> features. Period. There are one or two warts (dangling variable
> after list comprehensions comes to mind), but the language as a
> whole feels natural. Lisp feels natural if you are writing a
> compiler or want to be as orthogonal as possible, Python feels
> natural for most (all except drivers/applications with extreme
> performance requirements) of the real world applications.
No language feels more natural than Lisp. There's a real sense that
while Python was invented by a brilliant programmer, Lisp is built
into of the structure of the Universe. Bob Kanefsky's song "The
Eternal Flame" is a humor piece for sure, but it expresses that
sentiment beautifully. I can't imagine it being written about Python
or any other language than Lisp.
http://www.songworm.com/lyrics/songworm-parody/EternalFlame.html
Paul Rubin <·············@NOSPAM.invalid> writes:
> No language feels more natural than Lisp. There's a real sense that
> while Python was invented by a brilliant programmer, Lisp is built
> into of the structure of the Universe.
yes! The following quote from the ILC-03 (please help me: I can't
remember who said it!) says it all: "John Mc Carthy didn't invent lisp,
he _discovered_ it".
--
(espen)
[Followup posted to comp.lang.lisp only]
Espen Vestre writes:
> yes! The following quote from the ILC-03 (please help me: I can't
> remember who said it!) says it all: "John Mc Carthy didn't invent lisp,
> he _discovered_ it".
Most probably Paul Graham.
Paolo
--
Paolo Amoroso <·······@mclink.it>
On 18 Oct 2003 21:44:53 +0300, Ville Vainio
<······················@spamtut.fi> wrote:
>Lisp offers a bit more power than Python (macros), but after a while
>with Python, one notices that none of the power that is missing is
>actually even needed. Python has just the right
>features. Period. There are one or two warts (dangling variable after
>list comprehensions comes to mind), but the language as a whole feels
>natural. Lisp feels natural if you are writing a compiler or want to
>be as orthogonal as possible, Python feels natural for most (all
>except drivers/applications with extreme performance requirements) of
>the real world applications.
Depends. For a lot of things I agree with you, writing Python code is
very natural and straightforward. (I've decided my aesthetic dislike
of Python is such that I'd never be happy writing anything other than
throwaway scripts in it, but that's a different matter; aesthetics is
in the eye of the beholder.)
However, this really applies only when you're doing things the
language designer anticipated. The great thing I find about Lisp is
that when I'm doing something the language was _not_ designed to
handle, it's not an "oh shit" problem, it's a "well, I suppose I can
do this with a few macros" problem.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> However, this really applies only when you're doing things the
> language designer anticipated. The great thing I find about Lisp is
When I'm really doing something the language designer didn't
anticipate (and the required features don't already exist), I'm
probably doing something wrong and need to revise my design
anyway. You can do a whole lot in Python, esp. as you can code parts
in C if you really need that.
> that when I'm doing something the language was _not_ designed to
> handle, it's not an "oh shit" problem, it's a "well, I suppose I can
> do this with a few macros" problem.
One can always go to c.l.py and ask, only to see that the problem is
easily solved in plain old Python. I think the benefits of Python far
outweigh the theoretical scenario that I actually needed some feature
that isn't there, and could be done in Lisp. Most often the missing
features involve not having a library to, say, access some database,
and I doubt Lisp has more than Python to offer in that area.
Meanwhile, people are voting with their feet: a lot (thousands? don't
know the exact figure) of people are taught Lisp (well, Scheme, but
anyway) at colleges/whatever every year, and they abandon it in a
blink of an eye after the course (obviously this might be because the
courses emphasize functional programming). Many even think that C++,
of all things, is easier!
--
Ville Vainio http://www.students.tut.fi/~vainio24
On 20 Oct 2003 09:01:33 +0300, Ville Vainio <······················@spamtut.fi> wrote:
> Meanwhile, people are voting with their feet: a lot (thousands?
> don't know the exact figure) of people are taught Lisp (well,
> Scheme, but anyway) at colleges/whatever every year, and they
> abandon it in a blink of an eye after the course (obviously this
> might be because the courses emphasize functional programming). Many
> even think that C++, of all things, is easier!
Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. You know the "50 million flies" saying?
Edi.
"If a million people say a foolish thing, it is still a foolish
thing."
(Anatol France)
Edi Weitz <···@agharta.de> writes:
> Yeah, sure. And 95% of all computer users use Windows so it must be
> the best OS. [..]
..and presumably the masses of Windows users are also thinking that
whatever theoretical (read "something I've never heard of") benefits
other systems may offer, it will surely be offset by the next
point-and-click application from Microsoft.
--
Frode Vatvedt Fjeld
Edi Weitz <···@agharta.de> writes:
> Yeah, sure. And 95% of all computer users use Windows so it must be
> the best OS. You know the "50 million flies" saying?
Yep, but when exposed to a clearly superior language, one might assume
that at least a part of the students would get the clue and keep on
using it after the course. You can only go so far with "all college
students are morons". People diss Python if they haven't tried it, but
convert soon after giving it a spin; people diss Lisp even after
trying it. Perhaps they are morons, flies, whatever. Python also
welcomes them with open arms. When all is said and done, being 31337
is not that important.
However, Lisp (Emacs Lisp) *is* one of the three languages I actually
can find use for. The other two are C++ (day job) and Python.
--
Ville Vainio http://www.students.tut.fi/~vainio24
On 20 Oct 2003 12:29:39 +0300, Ville Vainio <······················@spamtut.fi> wrote:
> Edi Weitz <···@agharta.de> writes:
>
> > Yeah, sure. And 95% of all computer users use Windows so it must
> > be the best OS. You know the "50 million flies" saying?
>
> Yep, but when exposed to a clearly superior language, one might
> assume that at least a part of the students would get the clue and
> keep on using it after the course.
As the OP wrote, most of these students are taught Scheme, not Common
Lisp. (And, as we have seen quite often on c.l.l., probably by
teachers who force them to use weird recursive constructs and tell
stories about Lisp - "it is slow, it is interpreted, ..." - that have
been obsolete for decades.)
Also, where do you see evidence that /all/ students dismiss Lisp
immediately? We have a constant (albeit small) influx of newbies on
c.l.l.
As a counter-example consider the courses Robert Strandh teaches in
France (Bordeaux?) - they seem to be very successful. He's teaching
Common Lisp and some of his students "got the clue." They even
implemented a perfectly usable window manager in Common Lisp during
the course.[1]
Edi.
[1] <http://common-lisp.net/project/eclipse/>
The website is mostly empty but you can download the software and
also subscribe to the mailing list.
Ville Vainio wrote:
> Edi Weitz <···@agharta.de> writes:
>
>
>>Yeah, sure. And 95% of all computer users use Windows so it must be
>>the best OS. You know the "50 million flies" saying?
>
>
> Yep, but when exposed to a clearly superior language, one might assume
> that at least a part of the students would get the clue and keep on
> using it after the course.
In fact this happens. There are people out there who get it and stick to
Lisp. It's true that the majority doesn't do it (yet?), but that's
because Lisp doesn't give you instant rewards. I guess it takes
considerably longer to learn Lisp so that you can use it effectively, in
the sense that you can go beyond the stage that you can maximally get at
in other languages. (Also think about the possible net effects of
instructors who try to teach Lisp without having gotten it themselves.
Especially in the functional programming camp, there are people who see
Lisp as just a prelude to languages like ML and Haskell. This misses
some important points.)
All in all, these things are hard to measure. I have first learned about
Lisp about 10-15 years ago, and then completely forgot about it. It was
only about one and a half years ago that I have rediscovered it. In the
meantime, I have learned a lot about restrictions that most languages
impose on me as a programmer. Now I can really appreciate the expressive
power of Lisp and the degree to which unnecessary restrictions don't
bother me anymore in Lisp. This wouldn't have been possible 15 years
ago. Now do you really think the fact that I have "dissed" Lisp at first
tells us something really important about the language other than that I
was just too inexperienced to be able to appreciate it?
And in the meantime the world is continuously moving in the direction of
more dynamic and less restricted languages. Otherwise other languages
before Python would have been enough already. I think there is a pattern
involved here, and I am pretty sure that it will ultimately lead to
something that is as powerful as Lisp is today.
This is not just a fanatical rant of a religious follower, although it
may sound like that. However, you can objectively point out the
ingredients that make Lisp the mother of all languages in a certain
sense. See http://www.paulgraham.com/rootsoflisp.html
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> All in all, these things are hard to measure. I have first learned
> about Lisp about 10-15 years ago, and then completely forgot about
> it. It was only about one and a half years ago that I have
> rediscovered it. In the meantime, I have learned a lot about
> restrictions that most languages impose on me as a programmer. Now I
> can really appreciate the expressive power of Lisp and the degree to
> which unnecessary restrictions don't bother me anymore in Lisp. This
> wouldn't have been possible 15 years ago. Now do you really think the
> fact that I have "dissed" Lisp at first tells us something really
> important about the language other than that I was just too
> inexperienced to be able to appreciate it?
I still need to drag myself over the learning curve. I am forever
being distracted by other things and not devoting time to Lisp or any
other programming right now.
However.
My personal desire is to use Lisp as a competitive advantage for my
own software development. Self employment with a livable income is
what I want and I think that Lisp can get me there.
I have no beef with Python. I don't like the use of white space to
define block structures, but that is just my hangup. I think it is a
Good Thing that Perl has something to compete against. There is also
Ruby of course. Heck, it's not hard to point out all the different
scripting languages out there. I think scripting languages will rule
in the web based application world, Java notwithstanding.
I've served time doing web based applications. They have their
place, but they are not something I find very interesting. I prefer
the old school application that each computer has a copy of to run.
Compiled languages server better for that purpose I think. Sure,
embedding a scripting language like Python in a traditional
application will make it tons better (unless the application is a
Dali Clock). However, the base language is rather irrelevant in that
case. At least it is to the user.
On an unrelated note, I'm not entirely comfortable with all this
cross posting. It generates the sort of debate you see in the
*.advocacy groups. I'm not saying the debate is a bad thing. It
just clutters up the news groups that are intended to provide support
for their respective languages. If the group doesn't already exist,
perhaps a formal proposal for comp.lang.advocacy is in order. I know
some languages have specific advocacy groups already.
comp.lang.java.advocacy could be moved to comp.lang.advocacy.java to
go with the new group as well as the others that are out there so
that everything is in one pile.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
Edi Weitz <···@agharta.de> wrote in message news:<··············@bird.agharta.de>...
[yada yada...]
> "If a million people say a foolish thing, it is still a foolish
> thing."
>
> (Anatol France)
Did you know that Anatole France had one of the smallest brains on
record? See for instance:
http://www.sciencenetlinks.com/sci_update.cfm?DocID=166
search for 'anatole'
Slightly OT I guess, but these threads get boring fast.
ps on the topic -- any language that *requires* bloatware like Emacs
in order to use is already out of the running. I wrote my first large
Python program in Wordpad.
·········@yahoo.com (dan) writes:
> Edi Weitz <···@agharta.de> wrote in message news:<··············@bird.agharta.de>...
> [yada yada...]
>> "If a million people say a foolish thing, it is still a foolish
>> thing."
>>
>> (Anatol France)
>
> Did you know that Anatole France had one of the smallest brains on
> record? See for instance:
>
> http://www.sciencenetlinks.com/sci_update.cfm?DocID=166
>
> search for 'anatole'
>
> Slightly OT I guess, but these threads get boring fast.
>
> ps on the topic -- any language that *requires* bloatware like Emacs
> in order to use is already out of the running. I wrote my first large
> Python program in Wordpad.
Jesus. Are you bragging about using a non-editor on a non-OS?
Calling Emacs "bloatware" when you're using Windows seems more
than a little bit silly.
--
Raymond Wiker Mail: ·············@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/
Raymond Wiker <·············@fast.no> writes:
> ·········@yahoo.com (dan) writes:
>
> > Did you know that Anatole France had one of the smallest brains on
> > record?
Oh *hell* no. Phrenetics?!?! That pretty much disqualifies anyone
within two degrees of you from being taken seriously.
> Jesus. Are you bragging about using a non-editor on a non-OS?
This fool was talking about nonsense that's been discredited for 80
years, and 20 years in the popular press (cf. The Mismeasure of Man).
I wouldn't be surprised if it was bragging that 2 + 2 = -17.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Raymond Wiker <·············@fast.no> writes:
>
>> ·········@yahoo.com (dan) writes:
>>
>> > Did you know that Anatole France had one of the smallest brains on
>> > record?
>
> Oh *hell* no. Phrenetics?!?! That pretty much disqualifies anyone
> within two degrees of you from being taken seriously.
>
>> Jesus. Are you bragging about using a non-editor on a non-OS?
>
> This fool was talking about nonsense that's been discredited for 80
> years, and 20 years in the popular press (cf. The Mismeasure of Man).
> I wouldn't be surprised if it was bragging that 2 + 2 = -17.
Maybe we should all chip in and book him a session at a good
retrophrenologist's?[1]
Footnotes:
[1] See
http://shorty.wz.cz/download/pratchett_orig/15men_at_arms.htm#_ftn15[2]
[2] Better yet, but the book.
--
Raymond Wiker Mail: ·············@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/
dan writes:
> ps on the topic -- any language that *requires* bloatware like Emacs
> in order to use is already out of the running. I wrote my first large
> Python program in Wordpad.
No big deal: all text editors are ex-complete.
Paolo
--
Paolo Amoroso <·······@mclink.it>
·········@yahoo.com (dan) writes:
>
> ps on the topic -- any language that *requires* bloatware like Emacs
> in order to use is already out of the running. I wrote my first large
> Python program in Wordpad.
Now, I _know_ that you're a troll, but for the young innocent
minds who may one day read this and take you seriously:
Sorting `top' by memory size I get:
1135 ap 9 0 24704 24m 15m S 0.0 4.0 0:05.41 MozillaFirebird
1091 root 8 -10 55764 21m 4144 S 0.3 3.6 0:09.05 XFree86
1249 ap 13 5 20276 19m 4028 S 0.0 3.3 0:13.11 emacs
So this "bloatware" comes in easily under what is being
promulgated as a "small, fast, light" web browser.
That's all MozillaFirebird does: browse the web.
Emacs does my mail, news, editing, cvs, compiling, shells,
inferior lisp interaction... and web to boot!
Bloatware indeed. Sheesh.
In article <····························@posting.google.com>,
·········@yahoo.com (dan) wrote:
> ps on the topic -- any language that *requires* bloatware like Emacs
> in order to use is already out of the running. I wrote my first large
> Python program in Wordpad.
~bruce$ ls -l `which emacs`
-rwxr-xr-x 1 root wheel 4596224 Sep 24 04:29 /usr/bin/emacs
~bruce$ ls -l /Applications/Microsoft\ Office\ X/Microsoft\ Word
-rwxr-xr-x 1 bruce admin 10568066 Sep 26 2002
/Applications/Microsoft Office X/Microsoft Word
Uhh, dude ... emacs is less than half the size of Word...
Sorry, don't have Wordpad on this Mac.
And don't bother to quote me the size of Wordpad on W2k or XP ... most
of it is built into the operating system, just as IE and WMP and the
rest of them are.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> Sorry, don't have Wordpad on this Mac.
It's pretty small, a little smaller than vi, actually:
··@liten:~$ ls -l /mnt/vfat/Program\ Files/Accessories/WORDPAD.EXE
-rwxrwxr-x 1 ev ev 204800 Apr 23 1999 /mnt/vfat/Program Files/
Most needles are also small. That doesn't make them suitable as
chopsticks.
--
(espen)
Bruce Hoult <·····@hoult.org> wrote previously:
|~bruce$ ls -l `which emacs`
|-rwxr-xr-x 1 root wheel 4596224 Sep 24 04:29 /usr/bin/emacs
|~bruce$ ls -l /Applications/Microsoft\ Office\ X/Microsoft\ Word
|-rwxr-xr-x 1 bruce admin 10568066 Sep 26 2002
|/Applications/Microsoft Office X/Microsoft Word
Not even Windows users use MS-Word to edit program code; this is a
completely irrelevant comparison.
For more realistic ones (from my OS/2 machine that I'm sitting at, and
the editors I actually use):
D:\editors % ls boxer\b2.exe jEdit4.2pre1\jedit.jar fte\fte.exe
3-24-95 7:00a 317127 0 b2.exe
5-06-03 1:36a 2797098 219 jedit.jar
1-04-00 9:19p 585235 0 fte.exe
On a Linux box where my website is hosted (and emacs isn't installed
even if I wanted to use it):
~$ ls -l /usr/bin/joe /usr/bin/vim
-r-xr-xr-x 1 root root 166160 Feb 28 2001 /usr/bin/joe*
-rwxr-xr-x 1 root root 1172464 Dec 5 2001 /usr/bin/vim*
On my Macs I use jEdit too, so the size is basically the same (although
I have a bit more up-to-date version there). On my FreeBSD box maybe
I'll use kEdit or kDevel, or jed or vim; but I'm not sure of file sizes
from here.
IOW: Emacs is BLOATED.
Yours, David...
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
·····@gnosis.cx (David Mertz) writes:
> |-rwxr-xr-x 1 root wheel 4596224 Sep 24 04:29 /usr/bin/emacs
> |~bruce$ ls -l /Applications/Microsoft\ Office\ X/Microsoft\ Word
> |-rwxr-xr-x 1 bruce admin 10568066 Sep 26 2002
> |/Applications/Microsoft Office X/Microsoft Word
>
> Not even Windows users use MS-Word to edit program code; this is a
> completely irrelevant comparison.
OK, compare it to Visual Studio (not counting the compilers) instead.
> IOW: Emacs is BLOATED.
Or whatever else you're using is underpowered...
·····@gnosis.cx (David Mertz) wrote in message news:<·······································@python.org>...
> IOW: Emacs is BLOATED.
In an era of 250 GB hard drives, and GB RAM modules, who cares that
emacs is about 5MB in size, and uses 4 (real) to 10 (virtual) MB of
RAM.
Moore's law is lisp's friend. ;^)
·····@gnosis.cx (David Mertz) writes:
[examples snipped]
> IOW: Emacs is BLOATED.
I have 512 MB of memory on my $300 PC. Mozilla at the time of posting
eats 36M, emacs 15 M. I reckon that BLOAT will be approaching a real
problem when I run, like, twenty or thirty emacses or so, at once.
In short, a non-issue for the ordinary computer user.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
·····@gnosis.cx (David Mertz) writes:
> IOW: Emacs is BLOATED.
Size alone isn't what determines whether Emacs is bloated or
not. Size / functionality gives a fair measure, and in that case
notepad is more bloated than Emacs is.
Of course, Emacs is wasted on people who don't actually take
the time to learn to use it properly.
--
Raymond Wiker Mail: ·············@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/
·····@gnosis.cx (David Mertz) writes:
> Not even Windows users use MS-Word to edit program code; this is a
> completely irrelevant comparison.
I'm not sure you're right. Using Words little brother Wordpad is just
as weird, and we just had proof of that.
--
(espen)
In article <····························@posting.google.com>,
·········@yahoo.com (dan) wrote:
> ps on the topic -- any language that *requires* bloatware like Emacs
> in order to use is already out of the running. I wrote my first large
> Python program in Wordpad.
Good point! I always thought that Python's popularity stems from
that special property of the language. It relieves the vendors
from writing special editors for the language and shift the burden
to the user. Particularly attractive for embedding it as a
scripting language for an application.
However I don't agree that CL requires bloatware as big as
Emacs. You need only a small portion of Emacs for lisp editing.
Still it is going to be much more work than writing a WordPad
though.
Ville Vainio wrote:
> ················@eircom.net (Russell Wallace) writes:
>
>> However, this really applies only when you're doing things the
>> language designer anticipated. The great thing I find about Lisp is
>
> When I'm really doing something the language designer didn't
> anticipate (and the required features don't already exist), I'm
> probably doing something wrong and need to revise my design
> anyway. You can do a whole lot in Python, esp. as you can code parts
> in C if you really need that.
Yes to the latter, no to the former. Say that you want to do, e.g.,
aspect-oriented programming: that's something Guido definitely did
not anticipate, so Python "out of the box" doesn't support it --
that doesn't mean you're "doing something wrong and need to revise
your design" if your purpose is to experiment with AOP. Sure, you
can download several packages offering AOP for Python (google for
python aop
for a few thousand links), but each of them will do so within the
normal confines of ordinary Python syntax. If you want to experiment
with divergent syntax, too, as well as revolutionary semantics, then
those packages can't do it for you, except by implementing a new and
different language, separate from Python though integrated with it.
If your purpose in life is to write good, working applications with
high productivity, then I agree it's most likely suboptimal to play
around with paradigms that are novel, experimental and not (yet?)
well-integrated -- but if your purpose is experimenting with the very
bases of computing itself, such experimentation can't be called "wrong"!
Although it IS quite feasible to integrate most such experiments with
Python, there _are_ other languages that may be even more suitable for
that: Ruby if you don't care all that much about syntax sugar (you can
redefine just about any methods of Object etc to get the semantics you
want to play with -- but it may not have quite the syntax you'd most
like, e.g. you may find yourself having to use f.call(x) rather than
just f(x) because Ruby distinguishes callables from non-callables) --
Lisp (or Dylan, basically an infix-syntax dialect thereof;-) if you DO
care a lot about molding the syntax sugar to your experimental wishes.
>> that when I'm doing something the language was _not_ designed to
>> handle, it's not an "oh shit" problem, it's a "well, I suppose I can
>> do this with a few macros" problem.
>
> One can always go to c.l.py and ask, only to see that the problem is
> easily solved in plain old Python. I think the benefits of Python far
> outweigh the theoretical scenario that I actually needed some feature
> that isn't there, and could be done in Lisp. Most often the missing
You're taking it for granted that one's actual purpose is just to write
good working applications. That need not be the case: another might
have the purpose of experimenting with novel paradigms, instead.
> features involve not having a library to, say, access some database,
> and I doubt Lisp has more than Python to offer in that area.
From the point of view of deploying working applications, yes, you're
surely right. But it's not the ONLY valid point of view in the world.
> Meanwhile, people are voting with their feet: a lot (thousands? don't
> know the exact figure) of people are taught Lisp (well, Scheme, but
> anyway) at colleges/whatever every year, and they abandon it in a
> blink of an eye after the course (obviously this might be because the
> courses emphasize functional programming). Many even think that C++,
> of all things, is easier!
Sure, there's a "network effect" (in the sense of economics, nothing
to do with computer networks, necessarily;-) that goes to the advantage
of popular languages (C, Java, C++, perl) over less-popular ones (Python,
Ruby, lisps of all sorts). E.g., it's easier to find add-ons, books,
people to cooperate with, etc, etc. But it's only one of many factors
to consider in language choice, particularly when you're comparing
languages particularly hard to master, such as C++ or perl, with ones
that are particularly EASY to master, such as Scheme, Python, Ruby --
teaching one of the latter to people new to it then zipping along with it
may still be faster, for a large enough project, than finding people who
THINK they master, e.g., C++, and slogging through the project while
repeatedly having to engage in bouts of "emergency fire-fighting" and
unplanned tutoring each time some aspects they DON'T master comes up:-).
Alex
On 20 Oct 2003 09:01:33 +0300, Ville Vainio
<······················@spamtut.fi> wrote:
>When I'm really doing something the language designer didn't
>anticipate (and the required features don't already exist), I'm
>probably doing something wrong and need to revise my design
>anyway.
If you find that, then that would be a good reason for you to use
Python; there is of course no rule that says the same programming
language has to be best for everyone (or even for every program
written by a given person).
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Ville Vainio wrote:
> ················@eircom.net (Russell Wallace) writes:
>
>
>>However, this really applies only when you're doing things the
>>language designer anticipated. The great thing I find about Lisp is
>
>
> When I'm really doing something the language designer didn't
> anticipate (and the required features don't already exist), I'm
> probably doing something wrong and need to revise my design
> anyway.
So why is it that Python is continuously evolving as a language? Do you
think this is going to stop at some stage?
Wouldn't it be better if everyone could contribute to the evolution of a
language, and then let the community decide what the best approaches are?
See for example, the SRFI approach of the Scheme community.
>>that when I'm doing something the language was _not_ designed to
>>handle, it's not an "oh shit" problem, it's a "well, I suppose I can
>>do this with a few macros" problem.
>
> One can always go to c.l.py and ask, only to see that the problem is
> easily solved in plain old Python. I think the benefits of Python far
> outweigh the theoretical scenario that I actually needed some feature
> that isn't there, and could be done in Lisp.
The approach for Lisp is to write a domain-specific language for the
problem at hand, and then to write the program in that domain-specific
language. (These are not actually two distinct steps, but these parts
are usually achieved in an evolutionary way.)
If you want to keep your Lisp program in a specific programming style
(OOP, functional, imperative, etc.) you can do that either. Lisp gives
you a choice here.
With Python, you have to stick to the constructs the languages give you.
When you want to add domain-specific abstractions on the language level,
you have to step outside of the language, and for example use program
generators. Python doesn't give you a choice here.
This is only to say that in general, we usually don't use macros just to
"fix" the language, but we want macros because it enables a programming
style that is not available in most other programming languages.
> Most often the missing
> features involve not having a library to, say, access some database,
> and I doubt Lisp has more than Python to offer in that area.
That's correct.
> Meanwhile, people are voting with their feet: a lot (thousands? don't
> know the exact figure) of people are taught Lisp (well, Scheme, but
> anyway) at colleges/whatever every year, and they abandon it in a
> blink of an eye after the course (obviously this might be because the
> courses emphasize functional programming). Many even think that C++,
> of all things, is easier!
They can't vote with their feet wrt to particular features of the
programming languages they use, can they?
And as a sidenote, if you are seriously considering to learn and maybe
use Lisp in practice, you should take a look at _both_ major dialects,
i.e. Common Lisp and Scheme. They are very different in several
respects, and if you think that one of them sucks, this doesn't
necessarily mean that you will also despise the other one.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> wrote previously:
|Wouldn't it be better if everyone could contribute to the evolution of a
|language, and then let the community decide what the best approaches are?
I can think of almost nothing worse than this!
Well, "design-by-committee" results like XSLT are even worse. But the
"benevolent dictator" model is VASTLY better than the "let 1000 flowers
bloom" approach.
Incidentally, I have never seen--and expect never to see--some new
mysterious domain where Python is too limited because the designers did
not forsee the problem area. Nor similarly with other very high level
languages. It NEVER happens that you just cannot solve a problem
because of the lack of some novel syntax to do so... that's what
libraries are for.
Yours, Lulu...
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
"Lulu of the Lotus-Eaters" <·····@gnosis.cx> wrote in message
············································@python.org...
> Pascal Costanza <········@web.de> wrote previously:
> |Wouldn't it be better if everyone could contribute to the evolution of a
> |language, and then let the community decide what the best approaches are?
>
> I can think of almost nothing worse than this!
>
> Well, "design-by-committee" results like XSLT are even worse. But the
> "benevolent dictator" model is VASTLY better than the "let 1000 flowers
> bloom" approach.
>
> Incidentally, I have never seen--and expect never to see--some new
> mysterious domain where Python is too limited because the designers did
> not forsee the problem area. Nor similarly with other very high level
> languages. It NEVER happens that you just cannot solve a problem
> because of the lack of some novel syntax to do so... that's what
> libraries are for.
>
> Yours, Lulu...
>
Can't one make the same argument for Visual Basic. Use libraries as the
method to "build up the language" to a domain. Keep the language as simple
as possible and just use libraries - yeah, that's the ticket.
-R. Scott McIntire
> --
> Keeping medicines from the bloodstreams of the sick; food from the bellies
> of the hungry; books from the hands of the uneducated; technology from the
> underdeveloped; and putting advocates of freedom in prisons. Intellectual
> property is to the 21st century what the slave trade was to the 16th.
>
|"Lulu of the Lotus-Eaters" <·····@gnosis.cx> wrote in message
|> It NEVER happens that you just cannot solve a problem
|> because of the lack of some novel syntax to do so... that's what
|> libraries are for.
"Scott McIntire" <····················@comcast.net> wrote previously:
|Can't one make the same argument for Visual Basic. Use libraries as the
|method to "build up the language" to a domain.
Sure, in a sense. But the problem(s) with VB are not that it cannot be
extended to some novel domain syntax because it lacks macros.
VB is a bad language, but it is JUST AS BAD in its "core" areas as it is
when extended to new problems. There is a very strong disanalogy with
Python here. Python does a good job of expressing all the basic
*programming* constructs that go into ANY programming domain: loops,
branches, collections, objects and inheritence, HOFs, declared
constraints, etc. I have no expectation of EVER seeing some new problem
area that isn't built out of these same application parts.
Once in a great while, something really new comes along in programming
constructs themselves. OOP was such a thing, HOFs were, multimethods
are at a smaller level, constraint declarations (i.e. logic programming)
were; maybe coroutines are. Python does all of these things well--see
some of my articles for explanations of some of them where the basic
syntax needs some straightforward (pure-Python) extension modules.
The ONLY example I can think of where a basic construct is difficult to
shoehorn into Python might be AOP. I remain agnostic about the staying
power of this one, but it might prove important. There are some modules
out there, and metaclasses let you do it (in a less than elegant way).
On the other hand, Lisp--macros and all--is not any better suited to AOP
than is Python. I know you can work up something that nominally
qualifies as AOP using obscenely brittle macros... but it's not
something I would want to do.
Yours, David...
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
David Mertz wrote:
> Python does a good job of expressing all the basic
> *programming* constructs that go into ANY programming domain: loops,
> branches, collections, objects and inheritence, HOFs, declared
> constraints, etc. I have no expectation of EVER seeing some new problem
> area that isn't built out of these same application parts.
How do you justify your expectation? What's the rationale?
Pascal
Lulu of the Lotus-Eaters <·····@gnosis.cx> wrote in message news:<·······································@python.org>...
> Incidentally, I have never seen--and expect never to see--some new
> mysterious domain where Python is too limited because the designers did
> not forsee the problem area. Nor similarly with other very high level
> languages. It NEVER happens that you just cannot solve a problem
> because of the lack of some novel syntax to do so... that's what
> libraries are for.
The problem I have with this argument is, people already invent little
"languages" whenever they create new libraries. Right now I'm working
with wxPython. Here's an idiom that comes up (you don't need to
understand it):
app = wxPySimpleApp()
frame = MainWindow(None, -1, "A window")
frame.Show(True)
app.MainLoop()
Here, I have to put each line in a magical order. Deviate the
slightest bit, the thing crashes hard. It is hard to work with this
order; wxPython inherited an old design (not wxPython's fault), and
it's showing its age.
I'd fix it, but functions don't give me that power. I need to specify
the order of execution, because GUIs are all about side-effects --
macros are a solution worth having in your belt.
I am chained to wxPython's language. It's a language that is
basically Python-in-a-weird-order. Why not accept we need good
abstraction facilities because code has a habit of spiralling into
unmaintainability?
I'm not slamming Python or wxPython, since for this project they're
objectively better than today's CL. My only point is macros shouldn't
be underestimated. Especially since there are lots of things built
into lisp to make macros nice to use. (Like the macroexpand function,
which shows you what macros turn into.) Even if macros are
objectively wrong for Python, people should still know about them.
On Sat, 25 Oct 2003 20:57:58 -0700, Tayss wrote:
> app = wxPySimpleApp()
> frame = MainWindow(None, -1, "A window")
> frame.Show(True)
> app.MainLoop()
>
> Here, I have to put each line in a magical order. Deviate the
> slightest bit, the thing crashes hard. It is hard to work with this
> order; wxPython inherited an old design (not wxPython's fault), and
> it's showing its age.
>
> I'd fix it, but functions don't give me that power.
Why?
> I need to specify the order of execution,
What's the problem in specifying the order of execution in functions?
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote in message news:<······························@knm.org.pl>...
> > 1 app = wxPySimpleApp()
> > 2 frame = MainWindow(None, -1, "A window")
> > 3 frame.Show(True)
> > 4 app.MainLoop()
> >
> > Here, I have to put each line in a magical order. Deviate the
> > slightest bit, the thing crashes hard. It is hard to work with this
> > order; wxPython inherited an old design (not wxPython's fault), and
> > it's showing its age.
> >
> > I'd fix it, but functions don't give me that power.
>
> Why?
Ok, here I need to make every line execute in order or it crashes.
The problem is that, like Lisp, Python wants to greedily execute any
function I give it. So if I try abstracting lines 1, 3 and 4 in a
function, like the following, it will execute line 2 first, crashing
the system:
def make_app(frame):
app = wxPySimpleApp() # 1
frame.Show(True) # 3
app.MainLoop() # 4
# oops, #2 is executed first. game over!
make_app( MainWindow(None, -1, "Sample editor") ) # 2
So I have to somehow wrap up line 2 in something so it won't greedily
execute. One way is to flash-freeze it in a function, say:
lambda: MainWindow(None, -1, "A window")
or freeze it in a list:
[MainWindow, None, -1, "A window"]
And these are possible solutions. But it's less readable and frankly
strange to anyone who has to read my code. It's a weird functional
trick to deal with side-effect ridden code. When I really just wanted
to make execution work in the right order. So I likely fail in making
it more readable and maintainable, which is the whole point in doing
this.
> > I need to specify the order of execution,
>
> What's the problem in specifying the order of execution in functions?
Because in most languages (like Python and Lisp), functions don't give
the right amount of control over side-effects. They're great when
side-effects don't matter, but once they do, something like macros are
made for that situation.
Now, is this a big deal? Not really; it doesn't dominate the
advantages of using Python and wxPython. Just something I noticed.
But the tool is missing from the programmer's belt -- and whoever
defines a framework is already writing a new language that people must
deal with.
BTW, if in my other post you notice that in line 2
"A window"
morphs into
"Sample editor"
don't let it bother your subconscious. I was wrestling with google
groups to post (acting buggy recently, I wonder what's up..), and in
the process I cut 'n pasted the wrong stuff from my code. But it acts
the same, except for the window having a different title.
Pascal Costanza <········@web.de> writes:
> So why is it that Python is continuously evolving as a language? Do
> you think this is going to stop at some stage?
Python is not only the language, it's also the implementation (or
implementations). I don't know whether the evolution is ever going to
stop, you've got to ask Guido :-). Obviously I wouldn't mind if the
language reached Perfection within, say, 10 years, after which it
could be standardized and only the libraries and the implementation
would evolve.
> Wouldn't it be better if everyone could contribute to the evolution of
> a language, and then let the community decide what the best approaches
> are?
Possibly. But personally, I trust the guys in charge. Lisp might the
very essence of programming, built into the DNA of computer science,
but Python is the channeling of that quintessential truth into a form
that is *easily* writeable and esp. readable by mere mortals. It might
lose some of the power, but improved productivity in 90% of the
situations complements this nicely.
> With Python, you have to stick to the constructs the languages give
> you. When you want to add domain-specific abstractions on the language
Yes, and it gives me all I need. You can do a whole lot with
dynamically typed OO and powerful data types.
> > Meanwhile, people are voting with their feet: a lot (thousands? don't
> And as a sidenote, if you are seriously considering to learn and maybe
> use Lisp in practice, you should take a look at _both_ major dialects,
> i.e. Common Lisp and Scheme. They are very different in several
I only use Emacs Lisp. I have Python for the problem domains that CL
and Scheme would cover. I guess I might start hacking CL if/when
XEmacs switched their Lisp implementation, which I believe is in the
roadmaps...
--
Ville Vainio http://www.students.tut.fi/~vainio24
Ville Vainio wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>So why is it that Python is continuously evolving as a language? Do
>>you think this is going to stop at some stage?
>
>
> Python is not only the language, it's also the implementation (or
> implementations). I don't know whether the evolution is ever going to
> stop, you've got to ask Guido :-). Obviously I wouldn't mind if the
> language reached Perfection within, say, 10 years, after which it
> could be standardized and only the libraries and the implementation
> would evolve.
...and if it never reached perfection? If perfection were not reachable,
not for Python, not for any language?
>>Wouldn't it be better if everyone could contribute to the evolution of
>>a language, and then let the community decide what the best approaches
>>are?
>
>
> Possibly. But personally, I trust the guys in charge. Lisp might the
> very essence of programming, built into the DNA of computer science,
> but Python is the channeling of that quintessential truth into a form
> that is *easily* writeable and esp. readable by mere mortals.
No, it's not. Python doesn't have the "programs = data" feature.
>>With Python, you have to stick to the constructs the languages give
>>you. When you want to add domain-specific abstractions on the language
>
>
> Yes, and it gives me all I need. You can do a whole lot with
> dynamically typed OO and powerful data types.
What makes you so sure that it gives you all you need? Is this merely a
belief, or can you back that claim by objective facts?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> ...and if it never reached perfection? If perfection were not
> reachable, not for Python, not for any language?
I guess some pythonistas are like communists, they happily accept the
dictatorship of the proletariat as an intermediate solution...
Common Lips programmers, on the other hand, are like laid-back
anarchists with a Loneley Planet guide book: "Getting there is half
the fun" :-)
--
(espen)
Pascal Costanza <········@web.de> writes:
> ...and if it never reached perfection? If perfection were not
> reachable, not for Python, not for any language?
Then we'll just let it evolve, working around the shortcomings as we
go.
> > Yes, and it gives me all I need. You can do a whole lot with
> > dynamically typed OO and powerful data types.
> What makes you so sure that it gives you all you need? Is this merely
> a belief, or can you back that claim by objective facts?
It gives me all *I* need, it is very possible that it doesn't give
anyone else what they need. Perhaps I just don't need much. As far as
facts go, I don't even have objective facts to back my own existence,
so I'm not going to pursue that route.
Let's put it this way: Lisp is obviously the best language in
existence. All rivers flow from Lisp, and flow back to
Lisp. Preferences of human beings are inconsequential, it's not Lisp's
fault that some people are somewhat lacking in cognitive capability. I
just don't expect it to be hugely popular in the near future, at least
outside academia.
I'll go shut up now - don't really feel like reheating the old c.l.l
vs c.l.py flamewars (we've had enough of those - somehow these two
groups just don't mix). I have no axe to grind with Lisp; in fact I'm
planning to improve my skills in it. And some of you Lispers might do
well to check out Python - Lisp is Love, and thus very forgiving even
if you stray from the One True Way a little bit. Who knows, you might
have some fun :-).
--
Ville Vainio http://www.students.tut.fi/~vainio24
Ville Vainio <······················@spamtut.fi> writes:
> I only use Emacs Lisp. I have Python for the problem domains that CL
> and Scheme would cover. I guess I might start hacking CL if/when
> XEmacs switched their Lisp implementation, which I believe is in the
> roadmaps...
If even XEmacs is ported over to Common Lisp in my lifetime I will be
surprised. If it happens to GNU Emacs, surprise will not be enough
and I will have to resort to astonishment.
I'm not thinking of the core code. I'm thinking of all those *.el
files floating around the universe.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> If even XEmacs is ported over to Common Lisp in my lifetime I will be
> surprised. If it happens to GNU Emacs, surprise will not be enough
> and I will have to resort to astonishment.
>
> I'm not thinking of the core code. I'm thinking of all those *.el
> files floating around the universe.
Plans have been to convert Emacs to use a Scheme dialect with hacks to
support old .el files.
Paul Rubin wrote:
>
> David Steuber <·············@verizon.net> writes:
> > If even XEmacs is ported over to Common Lisp in my lifetime I will be
> > surprised. If it happens to GNU Emacs, surprise will not be enough
> > and I will have to resort to astonishment.
> >
> > I'm not thinking of the core code. I'm thinking of all those *.el
> > files floating around the universe.
>
> Plans have been to convert Emacs to use a Scheme dialect with hacks to
> support old .el files.
I have seen a translator written in scheme to convert el files
to scheme automatcially. I don't know how good it is or whether
it's ready to go, but it was basically source-to-source
compilation using a chained series of thunks as the output.
And of course, there's an emacs-alike editor called 'edwin' that is
coded directly in scheme. I don't know whether it runs any .el
files, but I think that it doesn't.
Bear
From: Roland Kaufmann
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <tl2r812io0d.fsf@space.at>
>>>>> "Ray" == Ray Dillinger <····@sonic.net> writes:
[[snip]]
Ray> And of course, there's an emacs-alike editor called 'edwin' that is
Ray> coded directly in scheme. I don't know whether it runs any .el
Ray> files, but I think that it doesn't.
According to
Message-ID: <···············@brabantio.informatik.uni-tuebingen.de>#1/1
it managed to run enough Emacs lisp for Gnus.
best regards
Roland
Pascal Costanza wrote:
...
> So why is it that Python is continuously evolving as a language? Do you
Basically because Guido LIKES language design, I think;-).
> think this is going to stop at some stage?
Not as long as Guido's at the helm:-).
> Wouldn't it be better if everyone could contribute to the evolution of a
> language, and then let the community decide what the best approaches are?
Everybody CAN contribute to Python! Indeed, I've never seen a community
more attuned to open source. But as for "who decides" -- you DO know that
a camel is a horse designed by a committee, right? I far prefer to have
one highly respected designer with final decision-making power. Guido's
not impervious to "the community", of course, but, in the end, it's HIS
final decision to make -- NOT some amorphous committee's.
Note that this delegation of final power IS "the community's decision".
Exactly because Python is aggressively open-source, there's NOTHING
stopping you, me, or anybody else, from taking a CVS snapshot and
forking off our own "python-like language" (presumably keeping binary
FFI compatibility to take advantage of the mainstream's abundance
of libraries and extensions). But people _don't_ -- thus concretely
recognizing the advantages of sticking to "Python as Guido indented
it" over designing their own language[s]. Even things that may look
like forks to the uninitated, such as Stackless, are anything but --
Christian Tismer took huge pains in Stackless development to turn it
back into a small patch anybody can apply to Python's official sources,
just to avoid diverging from the mainstream.
I think you couldn't CALL your altered language "Python", but there
are plenty of other reptiles and/or British comedy groups that you
can no doubt freely choose from.
> The approach for Lisp is to write a domain-specific language for the
> problem at hand, and then to write the program in that domain-specific
Right. People who fancy themselves as language designers will surely
be happier that way. People who prefer to use languages used by better
language designers than themselves, such as me, will be happier with
Python.
> If you want to keep your Lisp program in a specific programming style
> (OOP, functional, imperative, etc.) you can do that either. Lisp gives
> you a choice here.
>
> With Python, you have to stick to the constructs the languages give you.
Which include roughly the same paradigms as the above, BTW.
> When you want to add domain-specific abstractions on the language level,
Specifically: when you want to ALTER SYNTAX...
> you have to step outside of the language, and for example use program
> generators. Python doesn't give you a choice here.
...you can't "just alter Python's own syntax with your own changes":
you have plenty of choices (implement your chosen semantics within
Python's syntax, use any of N available parsers to parse your favourite
syntax -- user EITHER "program generators" OR interpreters at any
level on the parsed forms -- etc, etc). You just don't have the one
choice of *altering Python's own syntax wholly within Python itself*.
Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous", it seems to me.
> They can't vote with their feet wrt to particular features of the
> programming languages they use, can they?
What are you saying? Anybody can vote with their editor to alter
whatever set of features they hate. Well, in practice, at the
moment, only if they know enough C, or Java, or maybe C#, or
O'CAML -- they ARE welcome to download the pypy sources and fork
off those, of course, but if they did that right now their dialect's
performance would be, ahem, somewhat slightly sub-optimal (as in,
HUNDREDS of times too slow -- we're far from turning to various
optimizations that we plan to remedy that!).
But _in practice, people don't_, except for play and experiments
of various kinds. You can find a bazillion extremely varied
extensions to Python of all imaginable kinds, *BUT* they're ALL
*add-ons*, NEVER alteration of syntax or fundamental semantics
(Stackless had to work hard to ensure unchanged semantics JUST
adding [used to be continuations, now instead] microthreads --
no semantic alteration; psyco builds machine code on the fly
WITHOUT any syntax nor semantic alteration; etc, etc). The way
Pythonistas are voting with their feet and their editors seems
to be overwhelmingly in favour of Guido, see...
Alex
Alex Martelli <·····@aleax.it> writes:
> Describing a situation of having 99 available strategies rather than
> 100 as "doesn't give you a choice" can be charitably described as
> "ridiculous", it seems to me.
But it's not 100 against 99, it's 2 against 1. The two are functional
and syntactic abstraction.
And: All programming can be seen as an exercise in building a
language, where the programming language per se is merely a starting
point and provider of mechanisms for extending that starting point. So
whenever you define a function (or macro) you extend the language,
usually in the direction of some particular application area.
The "but I'm not a programming language designer" argument against
macros is very common and very bogus. Every programmer is.
--
Frode Vatvedt Fjeld
Alex Martelli wrote:
>>Wouldn't it be better if everyone could contribute to the evolution of a
>>language, and then let the community decide what the best approaches are?
>
>
> Everybody CAN contribute to Python! Indeed, I've never seen a community
> more attuned to open source. But as for "who decides" -- you DO know that
> a camel is a horse designed by a committee, right? I far prefer to have
> one highly respected designer with final decision-making power. Guido's
> not impervious to "the community", of course, but, in the end, it's HIS
> final decision to make -- NOT some amorphous committee's.
Who cares about committees? I don't.
Yes, there exist committee-driven standards for Scheme and Common Lisp.
But they are not by far as limiting as those for other languages.
In the case of Python, couldn't you rightfully regard it as driven by a
one-man commitee? ;-)
>>With Python, you have to stick to the constructs the languages give you.
>
>
> Which include roughly the same paradigms as the above, BTW.
Yes, roughly.
>>When you want to add domain-specific abstractions on the language level,
>
>
> Specifically: when you want to ALTER SYNTAX...
>
If it were only about making small alterations to the syntax, I wouldn't
lead this discussion. I mean what I say, I am talking about adding
full-fledged language constructs.
>>you have to step outside of the language, and for example use program
>>generators. Python doesn't give you a choice here.
>
>
> ...you can't "just alter Python's own syntax with your own changes":
> you have plenty of choices (implement your chosen semantics within
> Python's syntax, use any of N available parsers to parse your favourite
> syntax -- user EITHER "program generators" OR interpreters at any
> level on the parsed forms -- etc, etc). You just don't have the one
> choice of *altering Python's own syntax wholly within Python itself*.
Exactly. Lisp-style Macros make these things a breeze. The other
alternatives you suggest are considerably more complicated. As I have
said before, Lisp makes the simple things a little bit harder (-> syntax
for beginners), so that the hard things become considerably simpler (->
adding sophisticated abstractions in order to considerably reduce the
amount of code for complex tasks).
> Describing a situation of having 99 available strategies rather than
> 100 as "doesn't give you a choice" can be charitably described as
> "ridiculous", it seems to me.
I know about these choices, I have tried them all. I have written
compilers, interpreters, with and without parser generators, and have
co-designed and used transformation frameworks. These things are
considerably harder to build, and you need to spend a considerable
amount of time on the technology itself which distracts you from solving
the problem at hand. With Lisp-style macros, these things are much
simpler to handle once you have gotten it.
> But _in practice, people don't_, except for play and experiments
> of various kinds. You can find a bazillion extremely varied
> extensions to Python of all imaginable kinds, *BUT* they're ALL
> *add-ons*, NEVER alteration of syntax or fundamental semantics
You still have a wrong idea of how macros work. Macros are of course
also only add-ons. You don't alter unrelated syntax or unrelated
portions of source code, and you don't change fundamental semantics.
Instead of spreading misconceptions you should really start to get to
know the things better that you criticize.
Pascal
Pascal Costanza wrote:
...
> In the case of Python, couldn't you rightfully regard it as driven by a
> one-man commitee? ;-)
Ah, what a wonderfully meaningful view that is.
>> Specifically: when you want to ALTER SYNTAX...
>
> If it were only about making small alterations to the syntax, I wouldn't
I didn't say SMALL. Small or large, it's about alteration to the
syntax. Other lispers have posted (on several of this unending
multitude of threads, many but not all of which I've killfiled)
stating outright that there is no semantic you can only implement
with macros: that macros are ONLY to "make things pretty" for
given semantics. If you disagree with them, I suggest pistols at
ten paces, but it's up to you lispers of course -- as long as
you guys with your huge collective experience of macros stop saying
a million completely contradictory things about them and chastising
me because (due, you all keep claiming, to my lack of experience)
I don't agree with all of them, I'll be glad to debate this again.
Till then, this is yet another thread that get killfiled.
> lead this discussion. I mean what I say, I am talking about adding
> full-fledged language constructs.
Right: exactly what I _DON'T_ want to happen to my favourite language.
>>>you have to step outside of the language, and for example use program
>>>generators. Python doesn't give you a choice here.
>>
>> ...you can't "just alter Python's own syntax with your own changes":
>> you have plenty of choices (implement your chosen semantics within
>> Python's syntax, use any of N available parsers to parse your favourite
>> syntax -- user EITHER "program generators" OR interpreters at any
>> level on the parsed forms -- etc, etc). You just don't have the one
>> choice of *altering Python's own syntax wholly within Python itself*.
>
> Exactly. Lisp-style Macros make these things a breeze. The other
> alternatives you suggest are considerably more complicated. As I have
What's "considerably more complicated" in, say,
my_frobazzer = frobaz_compiler('''
oh my pretty, my beauteous,
my own all my own special unique frambunctious *LANGUAGE*!!!
''')
and later on call my_frobazzed(bim. bum, bam) at need? The complexity
of the frobaz_compiler factory callable depends exclusively on the
complexity of the language you want it to parse and compile, and you
of course have total choice ("Python doesn't give you a choice" MY
LEFT FOOT) on how to apportion the work between the factory and the
__call__ method of the resulting my_frobazzer.
You just have to respect Python's syntax and fundamental semantics
(e.g., strict order when your Python code calls a Python callable --
you can ALWAYS, TOTALLY count on this, NO surprises possible EVER),
and you still have a BAZILLION of choices, even AFTER making the
decision, which SHOULD be momentous rather than "a breeze" (!!!),
to CHOOSE to structure your whole application around your own unique
language or sub-language.
If Python makes it just as appealing to structure applications in
other ways, reserving "language design" for those occasions which
really call for it, so much the better. As I've repeatedly posted,
I've SUFFERED the consequences of computer scientists "breezily"
designing embedded Lisp subdialects for "domain-specific languages"
for domains they DIDN'T know 1/10th as well as the poor non-CS'ers
forced to suffer under that mishmash (hardware design the domain,
hardware design engineers the poor non-CS'ers) -- while at other
competing firms language design was treated with the respect it
deserves, producing not-embedded-in-anything, not-necessarily-
distorted-extended-subsets-of-anything hardware design languages
that let people actually DESIGN HARDWARE when that was their job.
> said before, Lisp makes the simple things a little bit harder (-> syntax
> for beginners), so that the hard things become considerably simpler (->
> adding sophisticated abstractions in order to considerably reduce the
> amount of code for complex tasks).
The vast majority of applications has absolutely no need to tinker
with the language's syntax and fundamental semantics. When you need
a language with different syntax, this is best treated as a serious
task and devoted all the respect it deserves, NOT treated as "a
breeze". PARTICULARLY for domain-specific languages, the language's
designers NEED access to domain-specific competence, which typically
they won't have enough of for any domain that doesn't happen to be
what they've spent many years of their life actually DOING (just
STUDYING doesn't cut it); the people WITH the domain-specific
competence will in turn not typically be experienced programmers --
they've spent their lives getting experience in the specific domain
instead. Making things harder for "beginners" (which may well be
the domain-specific experts) is then the wrong choice: those
non-programmers fully deserve, if a domain-specific language is
indeed warranted by the task's complexity, a language that does NOT
just happens to embed bits and pieces of another, harder-for-
beginners language, just because it was "a breeze" to design it thus.
I'm talking about substantial applications meant to get into heavy
production use. For experimentation, play, research in computing
itself, whatever, go ahead, not my own interest. For application
programming, IF a domain-specific language is needed, I want it to
be designed FOR THE USERS' NEEDS AND CONVENIENCE (==productivity!),
NOT because it's easy to hack together with macros. And that IF is
a big one; more often than not, no weird new syntax and semantics
are warranted. If it's too easy to tweak syntax and semantics, they
will be tweaked whether that's warranted or not; such frequent and
lightly undertaken SYNTAX CHANGES are NOT what I want in the language
I will use, in collaboration with many others, to build applications.
Some resistance to change is useful. Without attrition, walking
would be VERY hard. Without a constitution that's FAR harder to
change than ordinary laws, and "balance of powers" so that the
legislature, the executive and the courts hamper each other, a
democracy might be dangerously unstable (the "Federalist Papers"
make that case particularly well). Without an unchanging core,
such as syntax and fundamental semantics, a language may be less
useful for application development by middling-large groups (the
language might be wonderful for play and free-spirited experiments
AND at the same time less wonderful for such usage).
>> Describing a situation of having 99 available strategies rather than
>> 100 as "doesn't give you a choice" can be charitably described as
>> "ridiculous", it seems to me.
>
> I know about these choices, I have tried them all. I have written
So, you KNOW "doesn't give you a choice" is ridiculous.
> compilers, interpreters, with and without parser generators, and have
> co-designed and used transformation frameworks. These things are
> considerably harder to build, and you need to spend a considerable
> amount of time on the technology itself which distracts you from solving
You are (by far) exaggerating the effort. Check out such tools as
spark or SimpleParse and you'll see that parsing a custom language,
e.g. into an AST, is reasonably trivial. Once you have your AST,
you're basically in the same position as you start out with
S-exprs, so compiling and/or interpreting them is the same work.
What you don't do this way is MERGING LANGUAGE AND META-LANGUAGE --
sprinkling bits and pieces of your own custom language in the middle
of your implementation language and vice versa -- not "casually": if
and when you decide to embed languages into each other you must
deliberately take all decisions about arranging that.
As a consequence, the language you design is NOT influenced by the
language[s] you choose to use for the implementation thereof -- no
special push to make the supposedly application-domain-specific
language conform to uses and conventions typical of the implementation
language, no fragments of the implementation language suddenly perking
up in the middle of the application-domain-specific language.
So, for example, the BLM Language being developed at AB Strakt
(www.strakt.com) is INDEPENDENT from Python (though the designers
have of course been influenced by the parts of Python's syntax
they most liked, e.g., significant indentation); in the first
implementation, the embedded language for expressions and actions
is also Python, but the syntax already provides for embedding
multiple procedural/imperative languages even inside a single
BLM module. The interface between the declarative parts and the
embedded imperative ones is defined in terms of functions and
objects, so that, if and when the application-domain-specific
experts demand it (and pay for it:-) other languages may just as
well be adapter (sufficiently non-dynamic ones will necessarily
end up with lots of boilerplate code such as
attrib := blm.services->get_attribute(current_name);
and the like, but then, users of non-dynamic languages do appear
to like such boilerplate:-).
Sure, it could perfectly have been done in lisp (or any other
sufficiently high-level language just as well), but one would
have had to resist the temptation to orient the language being
designed towards "ease of implementation with lisp macros and
ease of integration with snippets of lisp", making it a
totally separate language -- and I've seen, and suffered on
my own skin, what typical CS'ers do about resisting such
temptation, particularly when convinced (as most, though not
all, of you guys seem to be) that lisp is obviously the best
language for ANY task, so why EVER could one POSSIBLY want a
totally different one for [insert any application domain]...?!
[Well, I've seen what they did about it 20+ years ago -- no
doubt human nature HAS changed drastically since, I'm sure].
> the problem at hand. With Lisp-style macros, these things are much
> simpler to handle once you have gotten it.
But will the simple way be the RIGHT one? Or will you end up
designing application-domain-specific languages needlessly, in
applications that would be much better structured in other ways,
AND when an application-domain-specific language IS called for,
end up "along the continuum" designing it ``by inertia'' as just
some "extended subset" of lisp, instead...?
>> But _in practice, people don't_, except for play and experiments
>> of various kinds. You can find a bazillion extremely varied
>> extensions to Python of all imaginable kinds, *BUT* they're ALL
>> *add-ons*, NEVER alteration of syntax or fundamental semantics
>
> You still have a wrong idea of how macros work. Macros are of course
> also only add-ons. You don't alter unrelated syntax or unrelated
> portions of source code, and you don't change fundamental semantics.
I have HAD to use (several mutually incompatible varieties of)
"application-domain-specific languages" built by lispers with
their beloved macros (in the early '80s, so it wasn't common
lisp yet, but rather a congeries of different lisp dialects,
including scheme). I know how macros work: they get hacked by
computer scientists that don't really grok the application domain,
then the resulting "extended subset of lisp" du jour is foisted
on people who DO know the application domain, CLAIMING falsely
to be appropriate for the specific application domain -- why,
they're (some kind of) lisp, OF COURSE they're automatically ideal
for ANY application right? And I'm not sure what the "unrelated"
syntax or portions of sources were, if any -- we had to describe
system-level, interface-level, circuit-level &c views of a chip
being developed in one or more of those (expl.del) "application
awful languages" and NO of _course_ you can't use COND here
because [gibbledygook] -- that's in AAL 1 as designed in Lab 1,
while in AAL 2 designed in Lab 2 OBVIOUSLY you must use COND here,
I thought you were HIRED because you had used lisp (I had, scheme
actually, but that was the favoured lisp of lab _3_ so mentioning
it in labs 1 or 2 made you an instant leper obviously).
No doubt "the solution" you proposed would have been to learn a
few of those GD macro systems and write the N-plus-1-th divergent
incompatible subdialect. Yeah right. I found a better one --
jump ship to IBM Research, get a raise, get to use a GOOD (for
the times, mind you -- still over 20 years ago) hardware design
language, have the fun of my life designing HW for a while until
I had to go back to SW -- and reconciling myself to the latter when
I found out it didn't HAVE to mean endlessly designing languages
for domains you didn't truly grasp with congeries of pieces of an
existing language and half-baked concoctions of your own -- you
COULD actually design good systems and algorithms, just like you
could with hardware, using SOLID, UNCHANGING (inside a project's
timeframe:-), _almost_-decently-designed-for-the-general-domain
languages [PLURAL!!!! *YES*!!!]. Admittedly, "almost". I tried
my hand at designing specialized languages (one of those sins
that just about everybody practices in youth, I guess) and found
out that, even when I grasped the application domain perfectly
well, that still didn't make my languages usable by other experts
of the domain (maybe because I kept falling onto prefix s-exproid
syntax in those years -- and just about everybody else hated it).
> Instead of spreading misconceptions you should really start to get to
> know the things better that you criticize.
Been there, done that, *NEVER, NEVER AGAIN*. Don't keep repeating
this claim, analogous to one that somebody who's lived and suffered
under a dictatorship shouldn't be spreading misconceptions but try
being a dictator to "know the things better that you criticize". I
don't want to foist my half-baked macro-based lisp dialects on
others any more than I'm going to suffer others foisting their own
on me, thankyouverymuch. If and when I should find myself working
on a solo project for which the need to tweak syntax within an
s-expr world appears, I may try some kind of lisp (hopefully, by
then, Graham's new baby -- if he's as good as the reverence every
lisper devotes him seems to indicate, then his claim that he can
make a lisp that's better than both scheme and CL while having the
strenths of both -- and then some -- should be credible).
But, until then -- bye. And now, to killfile this thread too....
Alex
Alex Martelli <·····@aleax.it> writes:
> Pascal Costanza wrote:
>snip
> What's "considerably more complicated" in, say,
> my_frobazzer = frobaz_compiler('''
> oh my pretty, my beauteous,
> my own all my own special unique frambunctious *LANGUAGE*!!!
> ''')
> and later on call my_frobazzed(bim. bum, bam) at need? The complexity
> of the frobaz_compiler factory callable depends exclusively on the
> complexity of the language you want it to parse and compile, and you
> of course have total choice ("Python doesn't give you a choice" MY
> LEFT FOOT) on how to apportion the work between the factory and the
> __call__ method of the resulting my_frobazzer.
Just imagine if your embedded language also used white space to denote
program structure.. cut and paste would get a little more tricky...
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <1xt7xvax.fsf@comcast.net>
Alex Martelli <·····@aleax.it> writes:
> I didn't say SMALL. Small or large, it's about alteration to the
> syntax. Other lispers have posted (on several of this unending
> multitude of threads, many but not all of which I've killfiled)
> stating outright that there is no semantic you can only implement
> with macros: that macros are ONLY to "make things pretty" for
> given semantics. If you disagree with them, I suggest pistols at
> ten paces, but it's up to you lispers of course -- as long as
> you guys with your huge collective experience of macros stop saying
> a million completely contradictory things about them and chastising
> me because (due, you all keep claiming, to my lack of experience)
> I don't agree with all of them, I'll be glad to debate this again.
Programming language research is an ongoing, dynamic process and there
are many diverging opinions. No one asks you to agree with all of them.
> Till then, this is yet another thread that get killfiled.
That's one solution. It certainly will protect you from hearing
opinions you don't agree with.
>>>> you have to step outside of the language, and for example use program
>>>> generators. Python doesn't give you a choice here.
>>>
>>> ...you can't "just alter Python's own syntax with your own changes":
>>> you have plenty of choices (implement your chosen semantics within
>>> Python's syntax, use any of N available parsers to parse your favourite
>>> syntax -- user EITHER "program generators" OR interpreters at any
>>> level on the parsed forms -- etc, etc). You just don't have the one
>>> choice of *altering Python's own syntax wholly within Python itself*.
I find it curious that someone who *likes* a language will use a
*different* language to implement certain abstractions. It is doubly
curious because the abstractions in question --- meta-linguistic
constructs --- are both powerful and difficult to master. I would
*think* that one would want these sort of abstractions to be handled
directly within the language rather than delegated to some inferior
tool.
>> Exactly. Lisp-style Macros make these things a breeze. The other
>> alternatives you suggest are considerably more complicated. As I have
>
> What's "considerably more complicated" in, say,
> my_frobazzer = frobaz_compiler('''
> oh my pretty, my beauteous,
> my own all my own special unique frambunctious *LANGUAGE*!!!
> ''')
> and later on call my_frobazzed(bim. bum, bam) at need?
The complexity is that the input to the frobaz_compiler takes the form
of a string. Inputs to the frobaz_compiler must be gratuitously
serialized to a character form (and then immediately unserialized by
the frobaz_compiler). This makes it difficult to parameterize the
code that is being compiled.
> The vast majority of applications has absolutely no need to tinker
> with the language's syntax and fundamental semantics.
I'd agree somewhat with this. Certainly making wholesale changes to
the language semantics (such as making it non-strict or call-by-name)
or syntax (changing from cambridge polish to java-like) is generally
unnecessary. I say generally because it *might* be exactly what you
want to do.
> When you need a language with different syntax, this is best treated
> as a serious task and devoted all the respect it deserves, NOT
> treated as "a breeze".
This is simply mysticism.
There is no a priori reason that syntax changes ought to be difficult.
If *minor* syntax changes can be implemented easily, why burden the
programmer with an entire language design?
> For application programming, IF a domain-specific language is
> needed, I want it to be designed FOR THE USERS' NEEDS AND
> CONVENIENCE (==productivity!), NOT because it's easy to hack
> together with macros. And that IF is a big one; more often than
> not, no weird new syntax and semantics are warranted. If it's too
> easy to tweak syntax and semantics, they will be tweaked whether
> that's warranted or not; such frequent and lightly undertaken SYNTAX
> CHANGES are NOT what I want in the language I will use, in
> collaboration with many others, to build applications.
You seem to be asserting that there is an enormous pressure to change
the syntax and semantics of the language, but where is the evidence
for this?
> Some resistance to change is useful. Without attrition, walking
> would be VERY hard. Without a constitution that's FAR harder to
> change than ordinary laws, and "balance of powers" so that the
> legislature, the executive and the courts hamper each other, a
> democracy might be dangerously unstable (the "Federalist Papers"
> make that case particularly well). Without an unchanging core,
> such as syntax and fundamental semantics, a language may be less
> useful for application development by middling-large groups (the
> language might be wonderful for play and free-spirited experiments
> AND at the same time less wonderful for such usage).
Argument by false analogy.
> Check out such tools as spark or SimpleParse and you'll see that
> parsing a custom language, e.g. into an AST, is reasonably trivial.
> Once you have your AST, you're basically in the same position as you
> start out with S-exprs, so compiling and/or interpreting them is the
> same work.
>
> What you don't do this way is MERGING LANGUAGE AND META-LANGUAGE --
> sprinkling bits and pieces of your own custom language in the middle
> of your implementation language and vice versa -- not "casually": if
> and when you decide to embed languages into each other you must
> deliberately take all decisions about arranging that.
There is quite a bit of design that goes into a computer language. A
lot of it is minutae: conditional execution, variable binding,
namespace control, types, etc. Lisp provides all of these. If Lisp
is *missing* a desired concept, it makes little sense to design an
entire new language to encompass the concept. It makes substantially
more sense to add the construct to a proven language.
> But will the simple way be the RIGHT one?
Perhaps it will, in which case we have an easy win. Perhaps it
will not, in which case we did not waste much effort.
> Or will you end up designing application-domain-specific languages
> needlessly, in applications that would be much better structured in
> other ways, AND when an application-domain-specific language IS
> called for, end up "along the continuum" designing it ``by inertia''
> as just some "extended subset" of lisp, instead...?
This is starting from the assumption that application-domain-specific
languages are inherently incompatible with Lisp.
>>> But _in practice, people don't_, except for play and experiments
>>> of various kinds. You can find a bazillion extremely varied
>>> extensions to Python of all imaginable kinds, *BUT* they're ALL
>>> *add-ons*, NEVER alteration of syntax or fundamental semantics
>>
>> You still have a wrong idea of how macros work. Macros are of course
>> also only add-ons. You don't alter unrelated syntax or unrelated
>> portions of source code, and you don't change fundamental semantics.
>
> I have HAD to use (several mutually incompatible varieties of)
> "application-domain-specific languages" built by lispers with
> their beloved macros (in the early '80s, so it wasn't common
> lisp yet, but rather a congeries of different lisp dialects,
> including scheme). I know how macros work: they get hacked by
> computer scientists that don't really grok the application domain,
> then the resulting "extended subset of lisp" du jour is foisted
> on people who DO know the application domain, CLAIMING falsely
> to be appropriate for the specific application domain -- why,
> they're (some kind of) lisp, OF COURSE they're automatically ideal
> for ANY application right? And I'm not sure what the "unrelated"
> syntax or portions of sources were, if any -- we had to describe
> system-level, interface-level, circuit-level &c views of a chip
> being developed in one or more of those (expl.del) "application
> awful languages" and NO of _course_ you can't use COND here
> because [gibbledygook] -- that's in AAL 1 as designed in Lab 1,
> while in AAL 2 designed in Lab 2 OBVIOUSLY you must use COND here,
> I thought you were HIRED because you had used lisp (I had, scheme
> actually, but that was the favoured lisp of lab _3_ so mentioning
> it in labs 1 or 2 made you an instant leper obviously).
Argument from authority. It is a pity that you had bad experiences,
but we all have war stories.
>> Instead of spreading misconceptions you should really start to get to
>> know the things better that you criticize.
>
> Been there, done that, *NEVER, NEVER AGAIN*.
So you keep saying, yet you offer no evidence.
> But, until then -- bye. And now, to killfile this thread too....
Argument from pigheadedness.
Alex Martelli <·····@aleax.it> wrote in message news:<·························@news2.tin.it>...
> Pascal Costanza wrote:
> > Exactly. Lisp-style Macros make these things a breeze. The other
> > alternatives you suggest are considerably more complicated. As I have
>
> What's "considerably more complicated" in, say,
> my_frobazzer = frobaz_compiler('''
> oh my pretty, my beauteous,
> my own all my own special unique frambunctious *LANGUAGE*!!!
> ''')
> and later on call my_frobazzed(bim. bum, bam) at need?
The problem is that
program = compiler(character-string)
is too much of a closed design. A more flexible design resembles:
abstract-syntax-tree = reader(character-string)
target-syntax-tree = translator(abstract-syntax-tree)
program = compiler(target-syntax-tree)
The input to a compiler should not be a character string, but
structured data.
> The complexity
> of the frobaz_compiler factory callable depends exclusively on the
> complexity of the language you want it to parse and compile, and you
In Lisp, the complexity of the compiler is constant; it's a language
builtin. The complexity of the reader depends on the complexity of the
lexical properties of the language, and the complexity of the
translator depends on the semantic complexity of the language.
> The vast majority of applications has absolutely no need to tinker
> with the language's syntax and fundamental semantics.
This is a common fallacy: namely that the difficulty of doing
something, and the consequent infrequency of doing it, constitute
evidence for a lack of need of doing it. In fact this is nothing more
than rationalization: ``I know I have inadequate tools, but I really
don't need them''. It's not unlike ``I can't reach those grapes, but I
know they are sour anyway''.
In Lisp, tinkering with the syntax and semantics is done even in
trivial programs.
By the way, your use of ``fundamental'' suggests a misunderstanding:
namely that some kind of destructive manipulation of the language is
going on to change the foundations, so that existing programs are no
longer understood or change in meaning. This is not so: rather, users
extend the language to understand new constructs. The fundamental
syntax and semantics stay what they are; they are the stable target
language for the new constructs.
> When you need
> a language with different syntax, this is best treated as a serious
> task and devoted all the respect it deserves, NOT treated as "a
> breeze".
This is a common viewpoint in computer science. Let me state it like
this: ``language design is a Hard Problem that requires you to whip
out lexical analyzers, parser constructors, complex data structures
for symbol table management, intermediate code generation, target code
generation, instruction selection, optimization, etc.'' But when you
have this:
abstract-syntax-tree = reader(character-string)
target-syntax-tree = translator(abstract-syntax-tree)
program = compiler(target-syntax-tree)
you can do most of the language design work in the second step:
translation of syntax trees into other trees. This is where macro
programming is done, and there is a large amount of clever
infrastructure in Lisp which makes it easy to work at this level. Lisp
contains a domain language for language construction.
> PARTICULARLY for domain-specific languages, the language's
> designers NEED access to domain-specific competence, which typically
> they won't have enough of for any domain that doesn't happen to be
> what they've spent many years of their life actually DOING (just
Bingo! This is where Lisp comes in; it gives the domain experts the
power to express what they want, without requiring them to become
compiler construction experts. This is why Lisp is used by some
artificial intelligence researchers, biologists, linguists, musicians,
etc.
Kaz Kylheku:
> The problem is that
>
> program = compiler(character-string)
>
> is too much of a closed design. A more flexible design resembles:
>
> abstract-syntax-tree = reader(character-string)
>
> target-syntax-tree = translator(abstract-syntax-tree)
>
> program = compiler(target-syntax-tree)
But you didn't see the implementation of Alex's 'compiler' function.
It looks like
def compiler(character_string):
return compile_tree(translator(reader(character_string)))
and those intermediates are part of the publically usable
API.
> The input to a compiler should not be a character string, but
> structured data.
I think you're arguing naming preferences here. That's fine;
Alex's point remains unchanged. In a dynamic language like
Python, parsing a domain specific language can be done at
run-time, parsed, converted to a Python parse tree, and
compiled to Python byte codes, just like what you want and
in the form you want it.
> In Lisp, the complexity of the compiler is constant; it's a language
> builtin. The complexity of the reader depends on the complexity of the
> lexical properties of the language, and the complexity of the
> translator depends on the semantic complexity of the language.
Replace 'Lisp' with 'Python' and the result is still true. Ditto
for 'C'. So I'm afraid I don't understand your point.
> > The vast majority of applications has absolutely no need to tinker
> > with the language's syntax and fundamental semantics.
>
> This is a common fallacy: namely that the difficulty of doing
> something, and the consequent infrequency of doing it, constitute
> evidence for a lack of need of doing it. In fact this is nothing more
> than rationalization: ``I know I have inadequate tools, but I really
> don't need them''. It's not unlike ``I can't reach those grapes, but I
> know they are sour anyway''.
That's not Alex's argument. Python has the ability to do exactly
what you're saying (domain language -> AST -> Python code or AST ->
compiler). It's rarely needed (I've used it twice now in my six years
or so of Python), so why should a language cater to make that
easy at the expense of making frequent things harder?
> In Lisp, tinkering with the syntax and semantics is done even in
> trivial programs.
And that's a good thing? That means that everyone looking at
new Lisp code needs to understand the modifications to the syntax
and semantics. That may be appropriate for an insular organization,
but otherwise it makes it harder for others to understand any code.
> By the way, your use of ``fundamental'' suggests a misunderstanding:
> namely that some kind of destructive manipulation of the language is
> going on to change the foundations, so that existing programs are no
> longer understood or change in meaning. This is not so: rather, users
> extend the language to understand new constructs. The fundamental
> syntax and semantics stay what they are; they are the stable target
> language for the new constructs.
Alex and others have responded to this argument many times. The
summary is that 1) in practice those who extend the language are most
often not the domain experts so the result doesn't correctly capture
the domain, 2) because it's easy to do, different groups end up with
different, incompatible domain-specific modifications, 3) rarely
is that approach better than using OOP, HOF and other approaches,
where better is defined as more flexible, easier to read, more
succinct, etc.
> This is a common viewpoint in computer science. Let me state it like
> this: ``language design is a Hard Problem that requires you to whip
> out lexical analyzers, parser constructors, complex data structures
> for symbol table management, intermediate code generation, target code
> generation, instruction selection, optimization, etc.''
Actually, language design doesn't require any of those. They
are needed to implement a language.
Let me add that implementing a language *was* a Hard Problem,
but effectively solved in the 1970s. The solutions are now well
known and there are a huge number of tools to simplify all
the steps in that process, books on the subject, and people with
experience in doing it.
There are still hard problems, but they are hard engineering
problems, not hard scientific ones where the theory is not
well understood.
> But when you have this:
>
> abstract-syntax-tree = reader(character-string)
>
> target-syntax-tree = translator(abstract-syntax-tree)
>
> program = compiler(target-syntax-tree)
>
> you can do most of the language design work in the second step:
> translation of syntax trees into other trees. This is where macro
> programming is done, and there is a large amount of clever
> infrastructure in Lisp which makes it easy to work at this level. Lisp
> contains a domain language for language construction.
Python has all that, including the ability to turn a string into
a Python AST, manipulate that tree, and compile that tree.
It's not particularly clever; there's no real need for that. In
general, the preference is to be clear and understandable over
being clever. (The New Jersey approach, perhaps?)
(Though the compiler module is pretty clumsy to use.)
> > PARTICULARLY for domain-specific languages, the language's
> > designers NEED access to domain-specific competence, which typically
> > they won't have enough of for any domain that doesn't happen to be
> > what they've spent many years of their life actually DOING (just
>
> Bingo! This is where Lisp comes in; it gives the domain experts the
> power to express what they want, without requiring them to become
> compiler construction experts. This is why Lisp is used by some
> artificial intelligence researchers, biologists, linguists, musicians,
> etc.
Speaking as a representative from the biology community, the
Lisp programmers are a minority and far behind C, Fortran, Perl,
and still behind Python, Tcl, and even Ruby.
*If* the domain expert is also an expert Lisp program then
what you say is true. It's been my experience that most domain
experts are not programmers -- most domains aren't programming.
Even in what I do, computational life sciences, most chemists
and biologists can do but a smattering of programming. That's
why they hire people like me. And I've found that objects and
functions are good enough to solve the problems in that domain;
from a CS point of view, it's usually pretty trivial.
Andrew
·····@dalkescientific.com
"Andrew Dalke" <······@mindspring.com> writes:
> It's not particularly clever; there's no real need for that. In
> general, the preference is to be clear and understandable over
> being clever. (The New Jersey approach, perhaps?)
Some people (academics) are paid for being clever. Others (engineers)
are paid for creating systems that work (in the wide meaning of the
word), in a timeframe that the company/client can afford.
In the for-fun area, by analogy, some people get the kick from
creating systems that work (be it a Linux distribution or a network
programming framework), and some from creating an uber-3133t hacks in
order to impress their friends.
Macros provide billions of different ways to be "clever", so obviously
Lisp gives greater opportunity of billable hours for people who can
bill for clever stuff. I'm studying Grahams "On Lisp" as bad-time
reading ATM, and can also sympathize w/ people who use Lisp just for
the kicks.
Lisp might have a good future ahead of it if it was only competing
againt C++, Java and others. Unfortunately for Lisp, other dynamic
languages exist at the moment, and they yield greater
productivity. Most bosses are more impressed with getting stuff done
fast than getting it done slowly, using gimmicks that would have given
you an A+ if it was a CS research project.
--
Ville Vainio http://www.students.tut.fi/~vainio24
Ville Vainio <······················@spamtut.fi> writes:
> bill for clever stuff. I'm studying Grahams "On Lisp" as bad-time
^^^
Typo, s/bad/bed, obviously :).
--
Ville Vainio http://www.students.tut.fi/~vainio24
Ville Vainio <······················@spamtut.fi> wrote in message news:<···············@mozart.cc.tut.fi>...
> Some people (academics) are paid for being clever. Others (engineers)
> are paid for creating systems that work (in the wide meaning of the
> word), in a timeframe that the company/client can afford.
[ snip ]
> --
> Ville Vainio http://www.students.tut.fi/~vainio24
^^^^^^^^
Tee hee! :)
> > Some people (academics) are paid for being clever. Others (engineers)
> > Ville Vainio http://www.students.tut.fi/~vainio24
> ^^^^^^^^
> Tee hee! :)
Yes, I have an account at a university. I prefer to use it instead of
that of my ISP (because ISP's come and go) or my work account (to
avoid associating my company with any of my opinions, which I think
should be a standard policy.. also, they don't provide web publishing
space for obvious reasons).
--
Ville Vainio http://www.students.tut.fi/~vainio24
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <oew92uel.fsf@comcast.net>
Ville Vainio <······················@spamtut.fi> writes:
> "Andrew Dalke" <······@mindspring.com> writes:
>
>> It's not particularly clever; there's no real need for that. In
>> general, the preference is to be clear and understandable over
>> being clever. (The New Jersey approach, perhaps?)
>
> Some people (academics) are paid for being clever. Others
> (engineers) are paid for creating systems that work (in the wide
> meaning of the word), in a timeframe that the company/client can
> afford.
And we all know that nothing made by academics actually works.
Conversely there is no need to be clever if you are an engineer.
> Macros provide billions of different ways to be "clever", so obviously
> Lisp gives greater opportunity of billable hours for people who can
> bill for clever stuff. I'm studying Grahams "On Lisp" as bad-time
> reading ATM, and can also sympathize w/ people who use Lisp just for
> the kicks.
Shhh! Don't alert the PHB's to how we pad our hours!
> Lisp might have a good future ahead of it if it was only competing
> againt C++, Java and others. Unfortunately for Lisp, other dynamic
> languages exist at the moment, and they yield greater productivity.
For instance, a productivity study done by Erann Gat showed ... no
wait. Where was that productivity study that showed how far behind
Lisp was?
> Most bosses are more impressed with getting stuff done fast than
> getting it done slowly, using gimmicks that would have given you an
> A+ if it was a CS research project.
Which is *precisely* the reason that bosses have adopted C++ over C.
Ville Vainio wrote:
> Lisp might have a good future ahead of it if it was only competing
> againt C++, Java and others. Unfortunately for Lisp, other dynamic
> languages exist at the moment, and they yield greater
> productivity.
This is true for the things that are currently en vogue.
> Most bosses are more impressed with getting stuff done
> fast than getting it done slowly, using gimmicks that would have given
> you an A+ if it was a CS research project.
I have implemented an AOP extension for Lisp that took about a weekend
to implement. The implementation is one page of Lisp code and is rather
efficient (wrt usability and performance) because of macros.
I have heard rumors that the development of an AOP extension for Python
would take considerably longer.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Andrew Dalke" <······@mindspring.com> wrote in message news:<·················@newsread4.news.pas.earthlink.net>...
> Kaz Kylheku:
> > The input to a compiler should not be a character string, but
> > structured data.
>
> I think you're arguing naming preferences here. That's fine;
> Alex's point remains unchanged. In a dynamic language like
> Python, parsing a domain specific language can be done at
> run-time, parsed, converted to a Python parse tree, and
> compiled to Python byte codes, just like what you want and
> in the form you want it.
Ah, but in Lisp, this is commonly done at *compile* time. Moreover,
two or more domain-specific languages can be mixed together, nested in
the same lexical scope, even if they were developed in complete
isolation by different programmers. Everything is translated and
compiled together. Some expression in macro language B can appear in
an utterance of macro language A. Lexical references across these
nestings are transparent:
(language-a
... establish some local variable foo ...
(language-b
... reference to local variable foo set up in language-a!
))
The Lisp parse tree is actually just normal Lisp code. There is no
special target language for the compiler; it understands normal Lisp,
and that Lisp is very conveniently manipulated by the large library of
list processing gadgets. No special representation or API is required.
Do people write any significant amount of code in the Python parse
tree syntax? Can you use that syntax in a Python source file and have
it processed together with normal code?
What is Python's equivalent to the backquote syntax, if I want to put
some variant pieces into a parse tree template?
Kaz Kylheku:
> Ah, but in Lisp, this is commonly done at *compile* time.
Compile vs. runtime is an implementation issue. Doesn't
change expressive power, only performance. Type inferencing
suggests that there are other ways to get speed-ups from
dynamic languages.
> Moreover,
> two or more domain-specific languages can be mixed together, nested in
> the same lexical scope, even if they were developed in complete
> isolation by different programmers.
We have decidedly different definitions of what a "domain-specific
language" means. To you it means the semantics expressed as
an s-exp. To me it means the syntax is also domain specific. Eg,
Python is a domain specific language where the domain is
"languages where people complain about scope defined by
whitespace." ;)
Yes, one can support Python in Lisp as a reader macro -- but
it isn't done because Lispers would just write the Python out
as an S-exp. But then it wouldn't be Python, because the domain
language *includes*domain*syntax*.
In other words, writing the domain language as an S-exp
is a short cut to make it easier on the programmer, and not
on the domain specialist. Unless the domain is programming.
And you know, very few of the examples of writing a domain
specific language in Lisp have been for tasks other than
programming.
> Do people write any significant amount of code in the
> Python parse tree syntax?
No. First, it isn't handled as a syntax, it's handled as
as operations on a tree data structure. Second -- and
this point has been made several times -- that style of
programming isn't often needed, so there of course isn't
a "significant amount."
> Can you use that syntax in a Python source file and have
> it processed together with normal code?
Did you look at my example doing just that? I built
an AST for Python and converted it into a normal function.
> What is Python's equivalent to the backquote syntax, if I
> want to put some variant pieces into a parse tree template?
There isn't. But then there isn't need. The question isn't
"how do I do this construct that I expect in Lisp?" it's "how
do I solve this problem?" There are other ways to solve
that problem than creating a "parse tree template" and to
date there have been few cases where the alternatives were
significantly worse -- even in the case of translating a domain
language into local syntax, which is a Lisp specialty, it's only
about twice as long for Python as for Lisp and definitely
not "impossible" like you claimed. Python is definitely worse
for doing research in new programming styles, but then
again that's a small part of what most programmers need,
and an even smaller part of what most non-professional
programmers need. (Eg, my science work, from a computer
science viewpoint, is dead boring.)
There's very little evidence that Lisp is significantly better
than Python (or vice versa) for solving most problems.
It's close enough that it's a judgement call to decide which
is more appropriate.
But that's a Pythonic answer, which acknowledges that
various languages are better for a given domain and that it's
relatively easy to use C/Java bindings, shared memory, sockets,
etc to make them work together, and not a Lispish answer,
which insists that Lisps are the best and only languages
people should consider. (Broad brush, I know.)
Andrew
·····@dalkescientific.com
"Andrew Dalke" <······@mindspring.com> writes:
> In other words, writing the domain language as an S-exp
> is a short cut to make it easier on the programmer, and not
> on the domain specialist. Unless the domain is programming.
> And you know, very few of the examples of writing a domain
> specific language in Lisp have been for tasks other than
> programming.
Actually in my experience that hasn't been a problem. For example, I
wrote a program that crunched EDI documents. There were hundreds of
different document types each with its own rudimentary syntax. We had
a big 3-ring binder containing a printed copy of the ANSI standard
that had a semi-formal English description the syntax of each of these
documents. My program had an embedded Lisp interpreter and worked by
letting you give it the syntax of each document type as a Lisp
S-expression. The stuff in the S-expression followed the document
description in the printed EDI standard pretty closely. I typed in
the first few syntax specs and then was able to hand off the rest to a
non-programmer, who was able to see pretty quickly how the
S-expressions worked and code the rest of them. I think that the
version of the system we actually shipped to customers still had the
S-expression syntax specs buried in its guts somewhere, but my memory
about that is hazy.
The instructions about how to process specific documents were also
entered as Lisp programs at first. That let us very quickly determine
the semantic features we wanted in processing scripts, even though we
knew that our customers wouldn't tolerate Lisp. Once we had the
semantics figured out, we were able to design a language that
superficially looked like an unholy marriage of Basic and Cobol. We
wrote a Yacc script that parsed that language and built up
S-expressions in memory, and then eval'd them with the Lisp
interpreter.
> > Do people write any significant amount of code in the Python parse
> > tree syntax?
Peter Norvig talks about this some in his Python/Lisp comparison page:
http://www.norvig.com/python-lisp.html
Basically the Python AST structure is awful, but you arrange your life
so you don't have to deal with it very much.
> There's very little evidence that Lisp is significantly better
> than Python (or vice versa) for solving most problems.
> It's close enough that it's a judgement call to decide which
> is more appropriate.
There's one area where Lisp absolutely rules, which is providing a way
to write down complicated data structures without much fuss. These
days, XML is used as a Bizarro cousin of Lisp S-expressions in all
kinds of applications for similar purposes. The EDI program I
mentioned earlier was not originally intended to have an embedded
interpreter. I typed in some EDI syntax specs as S-expressions just
to have something to work with. I then wrote something like a Lisp
reader to read the S-expressions. I found myself then writing a Lisp
printer to debug the Lisp reader. Having a reader and printer it was
then entirely natural to add an eval and gc. The result became a
fairly important product in the EDI world for a time.
Paul Rubin:
> Actually in my experience that hasn't been a problem. For example, I
> wrote a program that crunched EDI documents.
Ahh, you're right. I tend to omit business-specific languages
when I think about programming.
I conjecture it would have be about the same amount of work to
do it in Python, based solely on your description, but I defer to
you on it.
> superficially looked like an unholy marriage of Basic and Cobol.
heh-heh :)
> > > Do people write any significant amount of code in the Python parse
> > > tree syntax?
>
> Peter Norvig talks about this some in his Python/Lisp comparison page:
>
> http://www.norvig.com/python-lisp.html
>
> Basically the Python AST structure is awful, but you arrange your life
> so you don't have to deal with it very much.
His description starts
] Python does not have macros. Python does have access to the
] abstract syntax tree of programs, but this is not for the faint of
] heart. On the plus side, the modules are easy to understand,
] and with five minutes and five lines of code I was able to get this:
] >>> parse("2 + 2")
] ['eval_input', ['testlist', ['test', ['and_test', ['not_test',
['comparison',
] ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term',
] ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term',
['factor',
] ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']]
I completely agree. Manipulating Python AST and the parse tree
are not for the faint of heart. However, he's not working with
the AST
>>> import compiler
>>> compiler.parse("2+2")
Module(None, Stmt([Discard(Add((Const(2), Const(2))))]))
>>>
The code I wrote uses the AST and, while clunky, isn't as bad
as his example suggests.
> There's one area where Lisp absolutely rules, which is providing a way
> to write down complicated data structures without much fuss. These
> days, XML is used as a Bizarro cousin of Lisp S-expressions in all
> kinds of applications for similar purposes.
That's an old debate. Here's a counter-response
http://www.prescod.net/xml/sexprs.html
Andrew
·····@dalkescientific.com
From: james anderson
Subject: sexprs [Re: Why don't people like lisp?
Date:
Message-ID: <3F97899C.D13B1F00@setf.de>
one of the ironic, telling things about that exposition, is that the
syntax-error contraposition is not quite right.
Andrew Dalke wrote:
>
>
>
> > There's one area where Lisp absolutely rules, which is providing a way
> > to write down complicated data structures without much fuss. These
> > days, XML is used as a Bizarro cousin of Lisp S-expressions in all
> > kinds of applications for similar purposes.
>
> That's an old debate. Here's a counter-response
> http://www.prescod.net/xml/sexprs.html
>
it also misses the point, that "abstract" is not "concrete", and the surface
syntax in the input stream is not everything. an issue which "xml" will still
be fighting with long after the last so-encoded bits have long faded into the
aether.
analogies apply.
...
"Andrew Dalke" <······@mindspring.com> writes:
> Paul Rubin:
>
>> There's one area where Lisp absolutely rules, which is providing a way
>> to write down complicated data structures without much fuss. These
>> days, XML is used as a Bizarro cousin of Lisp S-expressions in all
>> kinds of applications for similar purposes.
>
> That's an old debate. Here's a counter-response
> http://www.prescod.net/xml/sexprs.html
Oh, please... Prescod claims that one of the advantages of XML
is that it defaults to treat contents as text, so you won't have to
escape characters like ".", "'" and '"' (among others). XML has the
exact same problem, with the characters "<", ">" and "&". The
"standard" XML solutions are character escapes and CDATA sections;
Lisp would probably use strings or specialised reader macros.
He also claims that redundancy is good, because missing XML
end tags are easier to detect than missing right parens. This
*completely* misses the point, as neither Lisp syntax nor XML should
be edited in something that doesn't understand the format.
--
Raymond Wiker Mail: ·············@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/
Raymond Wiker <·············@fast.no> writes:
[Andrew Dalke:]
> > That's an old debate. Here's a counter-response
> > http://www.prescod.net/xml/sexprs.html
>
> Oh, please... Prescod claims that one of the advantages of XML
> is that it defaults to treat contents as text, so you won't have to
> escape characters like ".", "'" and '"' (among others). XML has the
> exact same problem, with the characters "<", ">" and "&". The
> "standard" XML solutions are character escapes and CDATA sections;
> Lisp would probably use strings or specialised reader macros.
You say this as if Prescod isn't aware of that. He is,
and he gives two reasons why he thinks XML wins here
for use as a markup language (*any* bit of plain text
needs some sort of quoting in s-exprs, unlike in XML;
the markup characters in XML are less common in ordinary
text).
> He also claims that redundancy is good, because missing XML
> end tags are easier to detect than missing right parens. This
> *completely* misses the point, as neither Lisp syntax nor XML should
> be edited in something that doesn't understand the format.
If "understand the format" means "know how to count
parentheses or match XML end-tags" then I think Prescod
is right when he says "Smart editing tools can help but
they cannot solve the problem". I don't happen to think
the problem is terribly important, mind you :-).
However, I agree that Prescod's article is wrong-headed.
Specifically: I think he's right that XML is better than
s-expressions *for document markup*. (Not perfect, just
better than s-exprs.) But, having argued that, he goes
on to say "So in my opinion, XML's syntax is wildly
better than S-expressions as a language to integrate
the worlds of documentation and data". But hang on,
where did "data" suddenly appear from? None of the
arguments he's given have anything to do with XML's
goodness or badness for anything other than document
markup. So he's fudged the issue here, and thereby
skipped over all the arguments that favour s-exprs
for the data side. Similarly, at the end he says "the
benefits of integrating the two [document processing
and data processing] domains outweigh the costs in
having a technology that is not optimized for the
data processing domain"; he needs to consider the
possibility that they might even more outweigh the
costs in having one that isn't optimized for the
document processing domain.
And, of course, referring to XML as a "language" is
a bit bogus, suggesting that if you have some application
that needs a way of representing documents and data
then you can just "do it in XML", whereas in fact
saying "do it in XML" isn't so very different from
saying "do it in plain text" or "do it in a binary
format that precedes each object with a byte count".
So the integration benefits you get from having "a
single language" (not Prescod's words, but his meaning)
are less than you might expect.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <·····@g.local> writes:
> Raymond Wiker <·············@fast.no> writes:
>
> [Andrew Dalke:]
>> > That's an old debate. Here's a counter-response
>> > http://www.prescod.net/xml/sexprs.html
>>
>> Oh, please... Prescod claims that one of the advantages of XML
>> is that it defaults to treat contents as text, so you won't have to
>> escape characters like ".", "'" and '"' (among others). XML has the
>> exact same problem, with the characters "<", ">" and "&". The
>> "standard" XML solutions are character escapes and CDATA sections;
>> Lisp would probably use strings or specialised reader macros.
>
> You say this as if Prescod isn't aware of that. He is,
> and he gives two reasons why he thinks XML wins here
> for use as a markup language (*any* bit of plain text
> needs some sort of quoting in s-exprs, unlike in XML;
> the markup characters in XML are less common in ordinary
> text).
But both for XML and sexprs you *have* to look closely at the
text, no matter how common or not the "special" characters are. This
is another reason that you should use a specialised tool for editing
XML and sexpr files, which in turn means that you shouldn't really
treat them as text :-) Note that even for CDATA sections you have to
examine the text; if the text contains the CDATA end marker ("]]>"),
then this will have to be treated specially.)
--
Raymond Wiker Mail: ·············@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/
Gareth McCaughan <·····@g.local> writes:
> However, I agree that Prescod's article is wrong-headed.
> Specifically: I think he's right that XML is better than
> s-expressions *for document markup*. (Not perfect, just
> better than s-exprs.) But, having argued that, he goes
> on to say "So in my opinion, XML's syntax is wildly
> better than S-expressions as a language to integrate
> the worlds of documentation and data". But hang on,
> where did "data" suddenly appear from? None of the
> arguments he's given have anything to do with XML's
> goodness or badness for anything other than document
> markup.
This has driven me mad since I discovered that _that_ is exactly
where the xml hype crowd is heading. The syntax is _geared_ at
_human_readable_ document markup, yet it is used for EVERYTHING ELSE!
Ok, it's used for Word documents too, but the Word xml-stuff is so
bloated it's almost less human readable than the binary format
(in fact _much_ less readable than 'strings' applied to the binary
format, which is my standard way of reading .doc ;-))
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Gareth McCaughan <·····@g.local> writes:
>
> > However, I agree that Prescod's article is wrong-headed.
> > Specifically: I think he's right that XML is better than
> > s-expressions *for document markup*. (Not perfect, just
> > better than s-exprs.) But, having argued that, he goes
> > on to say "So in my opinion, XML's syntax is wildly
> > better than S-expressions as a language to integrate
> > the worlds of documentation and data". But hang on,
> > where did "data" suddenly appear from? None of the
> > arguments he's given have anything to do with XML's
> > goodness or badness for anything other than document
> > markup.
>
> This has driven me mad since I discovered that _that_ is exactly
> where the xml hype crowd is heading. The syntax is _geared_ at
> _human_readable_ document markup, yet it is used for EVERYTHING ELSE!
Perhaps they meant _programmer_readable_.
> Ok, it's used for Word documents too, but the Word xml-stuff is so
> bloated it's almost less human readable than the binary format
> (in fact _much_ less readable than 'strings' applied to the binary
> format, which is my standard way of reading .doc ;-))
>
> --
> (espen)
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>> This has driven me mad since I discovered that _that_ is exactly
>> where the xml hype crowd is heading. The syntax is _geared_ at
>> _human_readable_ document markup, yet it is used for EVERYTHING ELSE!
>
> Perhaps they meant _programmer_readable_.
That, combined with the famous "design goal" that "terseness in XML
markup is of minimal importance", would certainly explain why it is
far more popular among Java programmers than in the C world.
Maybe we can, given the lack of XML fandom among Lispniks, even
conclude that the cdr camp is bigger then the
update-instance-for-redefined-class party when it comes to naming. One
more point for Arc?
>> Ok, it's used for Word documents too, but the Word xml-stuff is so
>> bloated it's almost less human readable than the binary format
>> (in fact _much_ less readable than 'strings' applied to the binary
>> format, which is my standard way of reading .doc ;-))
Why, you could simply write a small XSLT script for that...
"Andrew Dalke" <······@mindspring.com> writes:
> Kaz Kylheku:
> > Moreover,
> > two or more domain-specific languages can be mixed together, nested in
> > the same lexical scope, even if they were developed in complete
> > isolation by different programmers.
>
> We have decidedly different definitions of what a "domain-specific
> language" means.
Probably not; more likely it is just a different emphasis.
> To you it means the semantics expressed as
> an s-exp. To me it means the syntax is also domain specific. Eg,
> Python is a domain specific language where the domain is
> "languages where people complain about scope defined by
> whitespace." ;)
Your whole article leans heavily toward raising the importance of
syntax. Lispers tend to see it differently. For Common Lispers,
and many other lispers who tend to minimize syntax, if the domain-
specific language already has or is able to have similar syntax
as Lisp, then parsing is analready-solved problem, and one can
just use the CL parser (i.e. read) and move on to other more
important problems in the domain language. But if the syntax
doesn't match, then it really still isn't a big deal; a parser
is needed just as it is in any other language, and one must
(and can) solve that problem as well as the rest of the
domain-specifics. The real question is how quickly you can
finally leave the issue of syntax behind you in your new problem
domain and move on to the problem to solve.
In the early '80s, I did an experiment, using Franz Lisp and Naomi
Sager's (NYU) English Grammar parser from her early 1981 book
"Natural Language Information Processing". I wrote a parser
for English out of her BNF and Franz Lisp's character macros and
the lisp reader. When I joined Franz Inc, I was able to port the
parser to Common Lisp with a little cheating (CL doesn't define
infix-macros like Franz Lisp does, so I had to redefine read-list
in order to make the ' macro work well with the lexicon).
[Unfortunately, I can't release this parser, because in my
correspondences with her, Dr. Sager made it clear that although
the sentences and descriptions in the book are not copyrighted,
the BNF and restrictions are. So although you can see the BNF
nodes reresented in a tree below, I won't define the terms;
you'll have to get the book for that...]
The whole point of my experiment was not to write a parser or
to try to parse English, but to show how powerful Lisp's parser
already is. With an input of
"John's going to Mary's house."
for example, with neither John nor Mary being present in the
lexicon, the parser is able to provide the following analysis
(note that the parser was written as a stand-alone program used
in a fashion similar to a scripting language, with no actual
interactive input from the user except via pipe from stdin):
Franz Lisp, Opus 38.89+ plus English Grammar Parser version 0
-> nil
-> nil
-> t
-> t
-> sentence =
(|John's| going to |Mary's| house |.|)
form = <sentence>
revised sentence =
(|John's| going to Mary is house |.|)
form = <sentence>
revised sentence =
(|John's| going to Mary has house |.|)
form = <sentence>
revised sentence =
(John is going to |Mary's| house |.|)
form = <sentence>
found parse 1
1 1 <sentence>
2 2 <introducer>
4 2 <center>
5 3 <assertion>
6 4 <sa>
8 4 <subject>
9 5 <nstg>
10 6 <lnr>
11 7 <ln>
12 8 <tpos>
18 8 <qpos>
20 8 <apos>
22 8 <nspos>
24 8 <npos>
26 7 <nvar>
27 8 <namestg>
28 9 <lnamer>
29 10 <lname>
34 10 n --------------> John
35 10 <rname>
37 7 <rn>
39 4 <sa>
41 4 <tense>
42 5 <null>
43 4 <sa>
45 4 <verb>
47 5 <lv>
49 5 <vvar>
50 6 tv --------------> is
53 4 <sa>
55 4 <object>
56 5 <objectbe>
57 6 <vingo>
58 7 <lvsa>
60 7 <lvingr>
61 8 <lv>
63 8 ving --------------> going
64 8 <rv>
66 9 <rv1>
67 10 <pn>
69 11 <lp>
71 11 p --------------> to
72 11 <nstgo>
73 12 <nstg>
74 13 <lnr>
75 14 <ln>
76 15 <tpos>
77 16 <lnamesr>
78 17 <lname>
83 17 ns --------------> |Mary's|
84 15 <qpos>
86 15 <apos>
88 15 <nspos>
90 15 <npos>
92 14 <nvar>
93 15 n --------------> house
94 14 <rn>
98 7 <sa>
100 7 <object>
101 8 <nullobj>
102 7 <rv>
104 7 <sa>
106 4 <rv>
108 4 <sa>
110 2 <endmark>
111 3 |-.-| --------------> |.|
revised sentence =
(John is going to Mary is house |.|)
form = <sentence>
revised sentence =
(John is going to Mary has house |.|)
form = <sentence>
revised sentence =
(John has going to |Mary's| house |.|)
form = <sentence>
revised sentence =
(John has going to Mary is house |.|)
form = <sentence>
revised sentence =
(John has going to Mary has house |.|)
form = <sentence>
(no more parses count= 1)
->
A more complex structured sentence, which Sager gave in her book,
was "the force with which an isolated heart beats depends on
the concentration of calcium in the medium which surrounds it."
which also was parsed correctly, though I won't show the parse
tree for it here because it is long. I did have trouble with
conjunctions, because they were not covered fullly in her book
and involve splicing copies of parts of the grammar together,
and there are a number of "restrictions" (pruning and
well-formedness tests specific to some of the BNF nodes that help
to find the correct parse) which she did not describe in her book.
Again, the point is that syntax and parsing are already-solved
problems., and even problems that don't on the surface look like
problems naturally solved with the lisp reader can come fairly
close to being solved with very little effort. Perhaps we can
thus move a little deeper into the problem space a little faster.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Andrew Dalke wrote:
>
> Kaz Kylheku:
> > Ah, but in Lisp, this is commonly done at *compile* time.
>
> Compile vs. runtime is an implementation issue. Doesn't
> change expressive power, only performance. Type inferencing
> suggests that there are other ways to get speed-ups from
> dynamic languages.
>
> > Moreover,
> > two or more domain-specific languages can be mixed together, nested in
> > the same lexical scope, even if they were developed in complete
> > isolation by different programmers.
>
> We have decidedly different definitions of what a "domain-specific
> language" means. To you it means the semantics expressed as
> an s-exp. To me it means the syntax is also domain specific. Eg,
> Python is a domain specific language where the domain is
> "languages where people complain about scope defined by
> whitespace." ;)
that is an inaccurate projection of what "domain-specific" means in a
programming environment like lisp. perhaps it says more about what it would
mean in a programming environemtn like python? if the author would take the
example of one of the recent discussions which flew by here, e.weitz's
cl-interpol, it would be interesting to read how
>
> Yes, one can support Python in Lisp as a reader macro -- but
> it isn't done because Lispers would just write the Python out
> as an S-exp. But then it wouldn't be Python, because the domain
> language *includes*domain*syntax*.
it exemplifies "writing the [ domain-specific language ] out as an s-exp.
>
> In other words, writing the domain language as an S-exp
> is a short cut to make it easier on the programmer, and not
> on the domain specialist. Unless the domain is programming.
> And you know, very few of the examples of writing a domain
> specific language in Lisp have been for tasks other than
> programming.
the more likely approach to "python-in-lisp" would be a
reader-macro/tokenizer/parser/translater which compiled the
"python-domain-specific-language" into s-expressions.
...
james anderson <··············@setf.de> writes:
> the more likely approach to "python-in-lisp" would be a
> reader-macro/tokenizer/parser/translater which compiled the
> "python-domain-specific-language" into s-expressions.
That's not really feasible because of semantic differences between
Python and Lisp. It should be possible, and may be worthwhile, to do
that with modified Python semantics.
"Andrew Dalke" <······@mindspring.com> wrote in message news:<···················@newsread4.news.pas.earthlink.net>...
> Kaz Kylheku:
> > Moreover,
> > two or more domain-specific languages can be mixed together, nested in
> > the same lexical scope, even if they were developed in complete
> > isolation by different programmers.
>
> We have decidedly different definitions of what a "domain-specific
> language" means. To you it means the semantics expressed as
> an s-exp. To me it means the syntax is also domain specific. Eg,
> Python is a domain specific language where the domain is
> "languages where people complain about scope defined by
> whitespace." ;)
There are two levels of syntax: the read syntax, and a deeper abstract
syntax. People who understand only the first one to be syntax are
scared of syntactic manipulation, because they are used to being
burned by syntax: stupid precedence rules, quirky punctuation,
semicolon diseases, strange whitespace handling, and so on.
A symbolic expression is a printed form which codes for a data
structure. That data structure continues to exhibit syntax, long after
the parentheses, whitespace and other lexical elements are processed
and gone.
> Yes, one can support Python in Lisp as a reader macro -- but
> it isn't done because Lispers would just write the Python out
> as an S-exp.
They would do that in cases when they have to invoke so many escape
hatches to embed Lisp code in the Python that the read syntax no
longer provides any benefit.
> But then it wouldn't be Python, because the domain
> language *includes*domain*syntax*.
>
> In other words, writing the domain language as an S-exp
> is a short cut to make it easier on the programmer, and not
> on the domain specialist.
Writing the language in terms of a data structure (which can be
converted back and forth to a printed symbolic expression) is not a
shortcut; it's proper layering at work. The read syntax can be
independently developed; the symbolic expressions merely give you a
generic one for free! Read syntax is just lexical sugar. It can be
quite important. Heck symbolic expressions have enough of it; it would
be a pain to type (QUOTE X) all the time instead of 'X, or
#.(make-array '(4) :element-type 'bit :initial-contents '(1 1 0 1))
instead of #*1101!
> > Can you use that syntax in a Python source file and have
> > it processed together with normal code?
>
> Did you look at my example doing just that? I built
> an AST for Python and converted it into a normal function.
I'm looking for a Python example which adds a new kind of statement to
the language, and then later in the source file uses that statement to
write a part of the program, such that it's all processed in the same
pass. The statement can be nested in existing ones, and can have
existing syntax embedded in it. Oh yeah, and it should work on at
least two Python implementations.
> > What is Python's equivalent to the backquote syntax, if I
> > want to put some variant pieces into a parse tree template?
>
> There isn't. But then there isn't need. The question isn't
When you start talking about need, that quickly becomes a losing
proposition. Because needs are actually wants in disguise. Do human
beings need electricity, running water or food prepared by heating?
> "how do I do this construct that I expect in Lisp?" it's "how
> do I solve this problem?"
The answer is: if I can get Lisp, I use that. Otherwise I work around
that. If you are in the middle of civilization, and the question is
``what's for dinner'', the answers are to go to the supermarket or a
restaurant. If you are lost in the woods, then you have to reason
differently.
> There are other ways to solve
> that problem than creating a "parse tree template" and to
> date there have been few cases where the alternatives were
> significantly worse -- even in the case of translating a domain
What cases? Where? Can you be more specific? Can ``significantly
worse'' be put into some kind of numbers?
> language into local syntax, which is a Lisp specialty, it's only
> about twice as long for Python as for Lisp and definitely
> not "impossible" like you claimed.
Okay, I'm expecting that example I asked for to be only twice as long
as the Lisp version.
Kaz Kylheku <···@ashi.footprints.net> wrote:
+---------------
| Ah, but in Lisp, this is commonly done at *compile* time. Moreover,
| two or more domain-specific languages can be mixed together, nested in
| the same lexical scope, even if they were developed in complete
| isolation by different programmers. Everything is translated and
| compiled together. Some expression in macro language B can appear in
| an utterance of macro language A. Lexical references across these
| nestings are transparent:
|
| (language-a
| ... establish some local variable foo ...
| (language-b
| ... reference to local variable foo set up in language-a!
| ))
+---------------
Exactly so!
A concrete example of this is using a macro package such as Tim
Bradshaw's HTOUT together with (say) one's own application-specific
Lisp code. You can blithely nest macro-generated HTML inside Lisp
code inside macro-generated HTML, etc., and have *direct* access to
anything in an outer lexical scope! Big win. Consider the following
small excerpt from <URL:http://rpw3.org/hacks/lisp/appsrv-demo.lhp>
(which has been reformatted slightly to make the nesting more apparent).
Note that any form *not* starting with a keyword switches from the
HTML-generating language ("language-B") to normal Lisp ("language-A")
and that the MACROLET "htm" switches from normal Lisp ("A") back to
HTML generation ("B"):
(lhp-basic-page () ; Contains a call of WITH-HTML-OUTPUT.
...
(:table ()
(:tr ()
(loop for e from 1 to pows
and h in headings do
(let ((p (cond ((= e 1) ":") ((= e pows) "") (t ","))))
(htm (:th (:nowrap)
(fmt h e) p)))))
(loop for i from 1 to nums do
(htm
(:tr (:align "right")
(loop for e from 1 to pows do
(htm
(:td ()
(princ (expt i e) s))))))))
... )
Note how the innermost reference of "i" [in "(expt i e)"] is nested
inside *four* language shifts from the binding of "i" [in the LOOP form],
that is:
(Lisp
;; "i" is bound here
(HTML
(Lisp
(HTML
(Lisp
;; "i" is used here
)))))
Oh, and by the way, all of that HTML-generating code gets expanded
into Lisp code at macro-expansion time [roughly, at compile time].
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Andrew Dalke wrote:
> That's not Alex's argument. Python has the ability to do exactly
> what you're saying (domain language -> AST -> Python code or AST ->
> compiler). It's rarely needed (I've used it twice now in my six years
> or so of Python), so why should a language cater to make that
> easy at the expense of making frequent things harder?
Maybe you have only rarely used it because it is hard, and therefore
just think that you rarely need it. At least, this is my assessment of
what I have thought to be true before I switched to Lisp.
>>In Lisp, tinkering with the syntax and semantics is done even in
>>trivial programs.
>
> And that's a good thing? That means that everyone looking at
> new Lisp code needs to understand the modifications to the syntax
> and semantics. That may be appropriate for an insular organization,
> but otherwise it makes it harder for others to understand any code.
That's true for any language. In any language you build new data
structures, classes, methods/functions/procedures, and everyone looking
at new code in any language needs to understand these new definitions.
There is no difference here _whatsoever_.
Modifying syntax and creating new language abstractions only _sounds_
scary, but these things are like any other activity during programming
that take care, as soon as the language you use supports them well.
>>By the way, your use of ``fundamental'' suggests a misunderstanding:
>>namely that some kind of destructive manipulation of the language is
>>going on to change the foundations, so that existing programs are no
>>longer understood or change in meaning. This is not so: rather, users
>>extend the language to understand new constructs. The fundamental
>>syntax and semantics stay what they are; they are the stable target
>>language for the new constructs.
>
>
> Alex and others have responded to this argument many times. The
> summary is that 1) in practice those who extend the language are most
> often not the domain experts so the result doesn't correctly capture
> the domain,
Are these non-experts any better off with just data structures and
functions?
> 2) because it's easy to do, different groups end up with
> different, incompatible domain-specific modifications,
Do they also come up with different APIs? How is divergence of APIs
solved in practice? Can't you use the same solutions for macro libraries?
> 3) rarely
> is that approach better than using OOP, HOF and other approaches,
> where better is defined as more flexible, easier to read, more
> succinct, etc.
Are you guessing, or is this based on actual experience?
BTW, macros are definitely more flexible and more succinct. The only
claim that I recall being made by Pythonistas is that macros make code
harder to read. The Python argument is that uniformity eases
readability; the Lisp argument is that a better match to the problem
domain eases readability. I think that...
(with-open-file (f "...")
...
(read f)
...)
...is much clearer than...
try:
f=open('...')
...
f.read()
...
finally:
f.close()
Why do I need to say "finally" here? Why should I even care about
calling close? What does this have to do with the problem I am trying to
solve? Do you really think it does not distract from the problem when
you first encounter that code and try to see the forest from the trees?
BTW, this is one of the typical uses for macros: When designing APIs,
you usually want to make sure that certain protocols are followed. For
the typical uses of your library you can provide high-level macros that
hide the details of your protocol.
Here is an arbitrary example that I have just picked from the
documentation for a Common Lisp library I have never used before:
(with-transaction
(insert-record :into [emp]
:attributes '(x y z)
:values '(a b c))
(update-records [emp]
:attributes [dept]
:values 50
:where [= [dept] 40])
(delete-records :from [emp]
:where [> [salary] 300000]))
(see
http://www.lispworks.com/reference/lw43/LWRM/html/lwref-460.htm#pgfId-889797
)
What do you think the with-transaction macro does? Do you need any more
information than that to understand the code?
BTW, note that the third line of this example is badly indented. Does
this make reading the code more difficult?
Here is why I think that Python is successful: it's because it favors
dynamic approaches over static approaches (wrt type system, and so on).
I think this is why languages like Ruby, Perl and PHP are also
successful. Languages like Java, C and C++ are very static, and I am
convinced that static approaches create more problems than they solve.
It's clear that Python is a very successful language, but I think this
fact is sometimes attributed to the wrong reasons. I don't think its
success is based on prettier syntax or uniformity. Neither give you an
objectively measurable advantage.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Andrew Dalke wrote:
>
> (with-open-file (f "...")
> ...
> (read f)
> ...)
>
> ...is much clearer than...
>
> try:
> f=open('...')
> ...
> f.read()
> ...
> finally:
> f.close()
>
> Why do I need to say "finally" here? Why should I even care about
> calling close? What does this have to do with the problem I am trying
> to solve? Do you really think it does not distract from the problem
> when you first encounter that code and try to see the forest from the
> trees?
>snip
Can you implement with-open-file as a function? If you could how would
it compare to the macro version? It would look something like:
(defun with-open-file (the-func &rest open-args)
(let ((stream (apply #'open open-args)))
(unwind-protect
(funcall the-func stream)
(close stream))))
(defun my-func (stream)
... operate on stream...
)
(defun do-stuff ()
(with-open-file #'my-func "somefile" :direction :input))
One of the important differences is that MY-FUNC is lexically isolated
from the environment where WITH-OPEN-FILE appears. The macro version
does not suffer this; and it is often convenient for the code block
in the WITH-OPEN-FILE to access that environment.
On Wed, Oct 22, 2003 at 09:52:42AM -0700, Jock Cooper wrote:
> One of the important differences is that MY-FUNC is lexically isolated
> from the environment where WITH-OPEN-FILE appears. The macro version
> does not suffer this; and it is often convenient for the code block
> in the WITH-OPEN-FILE to access that environment.
(call-with-open-file
#'(lambda (stream)
...)
"somefile"
:direction :input)
WITH-OPEN-FILE happens to be one of those macros which doesn't require
compile-time computation, but rather provides a convenient interface to
the same functionality as above.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Wed, Oct 22, 2003 at 09:52:42AM -0700, Jock Cooper wrote:
> > One of the important differences is that MY-FUNC is lexically isolated
> > from the environment where WITH-OPEN-FILE appears. The macro version
> > does not suffer this; and it is often convenient for the code block
> > in the WITH-OPEN-FILE to access that environment.
>
> (call-with-open-file
> #'(lambda (stream)
> ...)
> "somefile"
> :direction :input)
>
> WITH-OPEN-FILE happens to be one of those macros which doesn't require
> compile-time computation, but rather provides a convenient interface to
> the same functionality as above.
>
> --
Right, if the function is specified as a lambda inside the call then it
*would* have access to the surrounding lexical space.
The recent thread on macros has got me thinking more carefully about
when I use macros, and if I could use functions instead.
Pascal Costanza wrote:
> BTW, macros are definitely more flexible and more succinct. The only
> claim that I recall being made by Pythonistas is that macros make code
> harder to read. The Python argument is that uniformity eases
> readability; the Lisp argument is that a better match to the problem
> domain eases readability. I think that...
>
> (with-open-file (f "...")
> ...
> (read f)
> ...)
>
> ...is much clearer than...
>
> try:
> f=open('...')
> ...
> f.read()
> ...
> finally:
> f.close()
>
> Why do I need to say "finally" here? Why should I even care about
> calling close? What does this have to do with the problem I am trying to
> solve? Do you really think it does not distract from the problem when
> you first encounter that code and try to see the forest from the trees?
Your two examples do completely different things and the second is
written rather poorly as f might might not exist in the finally block.
It certainly won't if the file doesn't exist.
A better comparison would (*might*, I haven't used lisp in a while) be:
(with-open-file (f filename :direction :output :if-exists :supersede)
(format f "Here are a couple~%of test data lines~%")) => NIL
if os.path.exists(filename):
f = open(filename, 'w')
print >> f, "Here are a couple of test data lines"
I think that the latter is easier to read and I don't have to worry
about f.close(), but that is just me. I don't know what with-open-file
does if filename actually can't be opened but you haven't specified what
to do in this case with your example so I won't dig deeper.
> BTW, this is one of the typical uses for macros: When designing APIs,
> you usually want to make sure that certain protocols are followed. For
> the typical uses of your library you can provide high-level macros that
> hide the details of your protocol.
I tend to use a model in this case. For example if I want to always
retrieve a writable stream even if a file isn't openable I just supply a
model function or method.
model.safeOpen(filename)
"""filename -> return a writable file if the file can be opened or a
StringIO buffer object otherwise"""
In this case what happens is explicit as it would be with a macro. Note
that I could have overloaded the built-in "open" function but I don't
really feel comfortable doing that. So far, I haven't been supplied an
urgent need to use macros.
> Here is an arbitrary example that I have just picked from the
> documentation for a Common Lisp library I have never used before:
>
> (with-transaction
> (insert-record :into [emp]
> :attributes '(x y z)
> :values '(a b c))
> (update-records [emp]
> :attributes [dept]
> :values 50
> :where [= [dept] 40])
> (delete-records :from [emp]
> :where [> [salary] 300000]))
>
> (see
> http://www.lispworks.com/reference/lw43/LWRM/html/lwref-460.htm#pgfId-889797
> )
>
> What do you think the with-transaction macro does? Do you need any more
> information than that to understand the code?
>
Yep. Where's the database? I have to look at the specification you
provided to realize that it is provided by *default-database*. I also
am not aware from this macro whether the transaction is actually
committed or not and whether it rolls back if anything goes wrong. I
can *assume* this at my own peril but I, of course, had to look at the
documentation to be sure. Now this might be lisp-centric but I, being a
lowly scientist, couldn't use this macro without that piece of
knowledge. Of course, now that I know what the macro does I am free to
use it in the future. And yet, if I actually want to *deal* with errors
that occur in the macro besides just rolling back the transaction I
still need to catch the exceptions ( or write another macro :) )
The macro's that you have supplied seem to deal with creating a standard
API for dealing with specific exceptions.
Again, I could create an explicit database model
model.transaction(commands)
"""(commands) Execute a list of sql commands in a transaction.
The transaction is rolled back if any of the commands fail
and the correspoding failed exception is raised"""
> BTW, note that the third line of this example is badly indented. Does
> this make reading the code more difficult?
This is a red herring. Someone had to format this code to bake it
suitably readable. I could add a red-herring of my own reformatting
this into an undreadable blob but that would be rather childish on my
part and completely irrelevant.
> Here is why I think that Python is successful: it's because it favors
> dynamic approaches over static approaches (wrt type system, and so on).
> I think this is why languages like Ruby, Perl and PHP are also
> successful. Languages like Java, C and C++ are very static, and I am
> convinced that static approaches create more problems than they solve.
We are in agreement here.
> It's clear that Python is a very successful language, but I think this
> fact is sometimes attributed to the wrong reasons. I don't think its
> success is based on prettier syntax or uniformity. Neither give you an
> objectively measurable advantage.
It all depends on your perspective. I think that I have limited brain
power for remembering certain operations. A case in point, I was
re-writing some documentation yesterday for the embedded metakit
database. Python uses a slice notation for list operations:
list[lo:hi] -> returns a list from index lo to index hi-1
The database had a function call select:
view.select(lo, hi) -> returns a list from index lo to index hi
While it seems minor, this caused me major grief in usage and I wish it
had been uniform with the way python selects ranges. Now I have two
things to remember. I can objectively measure the difference in this
case. The difference is two hours of debugging because of a lack of
uniformity. Now, I brought this on myself by not reading the
documentation closely enough and missing the word "(inclusive)" so I
can't gripe to much. I will just say that the documentation now clearly
shows this lack of uniformity from the standard pythonic way. Of course
we could talk about the "should indexed arrays start with 0 or 1?" but I
respect that there are different desired levels of uniformity. Mine is
probably a little higher than yours :)
Note, that I have had similar experiences in lisp where macros that I
expected to work a certain way, as they were based on common CLHS
macros, didn't. For example, you wouldn't expect (with-open-file ...)
to behave fundamentally different from (with-open-stream ...) and would
probably be annoyed if they did.
In case anyone made it this far, I'm not dissing lisp or trying to
promote python. Both languages are remarkably similar. Macros are one
of the constructs that make lisp lisp and indentation are one of the
things that make python python. Macros could be extremely useful in
python and perhaps to someone who uses them regularly, their ommision is
a huge wart. Having used macros in the past, all I can say is that for
*MY* programming style, I can't say that I miss them that much and have
given a couple of examples of why not.
> Pascal
Brian Kelley
Whitehead institute for Biomedical Research
On Wed, Oct 22, 2003 at 12:30:01PM -0400, Brian Kelley wrote:
> Your two examples do completely different things and the second is
> written rather poorly as f might might not exist in the finally block.
> It certainly won't if the file doesn't exist.
>
> A better comparison would (*might*, I haven't used lisp in a while) be:
>
> (with-open-file (f filename :direction :output :if-exists :supersede)
> (format f "Here are a couple~%of test data lines~%")) => NIL
>
> if os.path.exists(filename):
> f = open(filename, 'w')
> print >> f, "Here are a couple of test data lines"
How are these in any way equivalent? Pascal posted his example with
try...finally and f.close () for a specific reason. In your Python
example, the file is not closed until presumably the GC collects the
descriptor and runs some finalizer (if that is even the case). This is
much different from the Lisp example which guarantees the closing of the
file when the body of the WITH-OPEN-FILE is exited. In addition:
``When control leaves the body, either normally or abnormally (such as
by use of throw), the file is automatically closed. If a new output file
is being written, and control leaves abnormally, the file is aborted and
the file system is left, so far as possible, as if the file had never
been opened.''
http://www.lispworks.com/reference/HyperSpec/Body/m_w_open.htm#with-open-file
So in fact, you pointed out a bug in Pascal's Python example, and one
that is easy to make. All this error-prone code is abstracted away by
WITH-OPEN-FILE in Lisp.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Wed, Oct 22, 2003 at 12:30:01PM -0400, Brian Kelley wrote:
>
>>Your two examples do completely different things and the second is
>>written rather poorly as f might might not exist in the finally block.
>>It certainly won't if the file doesn't exist.
>>
>>A better comparison would (*might*, I haven't used lisp in a while) be:
>>
>>(with-open-file (f filename :direction :output :if-exists :supersede)
>> (format f "Here are a couple~%of test data lines~%")) => NIL
>>
>>if os.path.exists(filename):
>> f = open(filename, 'w')
>> print >> f, "Here are a couple of test data lines"
>
>
> How are these in any way equivalent? Pascal posted his example with
> try...finally and f.close () for a specific reason. In your Python
> example, the file is not closed until presumably the GC collects the
> descriptor and runs some finalizer (if that is even the case).
The file is closed when the reference count goes to zero, in this case
when it goes out of scope. This has nothing to do with the garbage
collector, just the reference counter. At least, that's the way I
understand, and I have been wrong before(tm). The upshot is that it has
worked in my experience 100% of the time and my code is structured to
use (abuse?) this. How is this more difficult?
The difference here, as I see it, is that if an exception happens then
the system has to wait for the garbage collector to close the file. In
both examples there was no exception handling after the fact (after the
file is closed). The macro, then, allows execution to continue with the
closed file while the python version stops execution in which case the
file is closed anyway. (unless it is in a another thread of execution
in which the file is closed when it goes out of scope)
In either case one still needs to write handling code to support the
failure as this is most likely application specific. Using macros as a
default handler seems very appropriate in lisp. In python, as I
mentioned in the model-centric view I would create a new file object to
support better handling of file-i/o and failures and hence abstract away
the "error-prone" styles you mentioned.
Now, macros really shine when they also use the local scope. However,
unless a macro is actually doing this I see no real difference between
creating a wrapper for an object and a macro:
f = FileSafeWrapper(open(...))
(with-file-open (f ...)
Except that the macros you are describing are part of the common
distribution. I have to write my own FileSafeWrapper for now...
> http://www.lispworks.com/reference/HyperSpec/Body/m_w_open.htm#with-open-file
>
> So in fact, you pointed out a bug in Pascal's Python example, and one
> that is easy to make. All this error-prone code is abstracted away by
> WITH-OPEN-FILE in Lisp.
This is a good thing, naturally. But the examples you have given are
completely do-able (in one form or another) in python as it currently
stands, either by creating a wrapper around a file object that can
properly close down on errors or what not. In fact, this might be a
better abstraction in some cases. Consider:
(with-file-that-also-outputs-to-gui ... )
(with-file-that-also-outputs-to-console ...)
to
(with-open-file (f ...
in this case, f is supplied by some constructor that wraps the file to
output to the gui or standard i/o and is passed around to various
functions. Which is the better solution?
I'm not saying that lisp can't do this, it obviously can, but macros
might not be the appropriate solution to this problem ( they certainly
aren't in python ;) )
p.s. I really do enjoy programming in lisp, it was my second programming
language after fortran 77.
Brian Kelley <·······@wi.mit.edu> wrote in message news:<·······················@senator-bedfellow.mit.edu>...
> The file is closed when the reference count goes to zero, in this case
> when it goes out of scope. This has nothing to do with the garbage
> collector, just the reference counter. At least, that's the way I
> understand, and I have been wrong before(tm). The upshot is that it has
> worked in my experience 100% of the time and my code is structured to
> use (abuse?) this. How is this more difficult?
As I understand, you're arguing that it's ok to let Python's
refcounter automagically close the file for you.
Please read this:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=3F1F5297.15D768EF%40alcyone.com
Erik Max Francis explains that expecting the system to close files
leads to brittle code. It's not safe or guaranteed.
After learning Python, people write this bug for months, until they
see some article or usenet post with the try/finally idiom. This
idiom isn't obvious from the docs; the tutorial doesn't say how
important closing a file is. (I was lucky enough to already know how
exceptions could bust out of code.)
Now, I love Python, but this really is a case where lots of people
write lots of potentially hard-to-reproduce bugs because the language
suddenly stopped holding their hands. This is where it really hurts
Python to make the tradeoff against having macros. The tradeoff may
be worth it, but ouch!
Tayss wrote:
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=3F1F5297.15D768EF%40alcyone.com
> Erik Max Francis explains that expecting the system to close files
> leads to brittle code. It's not safe or guaranteed.
>
> After learning Python, people write this bug for months, until they
> see some article or usenet post with the try/finally idiom.
Some more than most. Interestingly, I write proxies that close
resources on failure but tend to let files do what they want.
> Now, I love Python, but this really is a case where lots of people
> write lots of potentially hard-to-reproduce bugs because the language
> suddenly stopped holding their hands. This is where it really hurts
> Python to make the tradeoff against having macros. The tradeoff may
> be worth it, but ouch!
I choose a bad example on abusing the C-implementation. The main thrust
of my argument is that you don't need macros in this case, i.e. there
can be situations with very little tradeoff.
class SafeFileWrapper:
def __init__(self, f):
self.f = f
def write(self, data):
try: self.f.write(data)
except:
self.f.close()
self.f = None
raise
def close():
if self.f:
self.f.close()
...
Now the usage is:
f = SafeFileWrapper(open(...))
print >> f, "A couple of lines"
f.close()
So now I just grep through my code for open and replace it with
SafeFileWrapper(open...) and all is well again.
I still have to explicitly close the file though when I am done with it,
unless I don't care if it is open through the application run. But at
least I am guaranteed that the file is closed either when I tell it to
or on an error.
Brian Kelley
Brian Kelley <·······@wi.mit.edu> writes:
> I choose a bad example on abusing the C-implementation. The main
> thrust of my argument is that you don't need macros in this case,
> i.e. there can be situations with very little tradeoff.
>
> class SafeFileWrapper:
> def __init__(self, f):
> self.f = f
>
> def write(self, data):
> try: self.f.write(data)
> except:
> self.f.close()
> self.f = None
> raise
>
> def close():
> if self.f:
> self.f.close()
> ...
>
> Now the usage is:
>
> f = SafeFileWrapper(open(...))
> print >> f, "A couple of lines"
> f.close()
...
> I still have to explicitly close the file though when I am done with
It's just this sort of monotonous (yet important) book keeping (along
with all the exception protection, etc.) that something like
with-open-file ensures for you.
/Jon
Jon S. Anthony wrote:
> Brian Kelley <·······@wi.mit.edu> writes:
>> Now the usage is:
>>
>> f = SafeFileWrapper(open(...))
>> print >> f, "A couple of lines"
>> f.close()
> ...
>> I still have to explicitly close the file though when I am done with
>
> It's just this sort of monotonous (yet important) book keeping (along
> with all the exception protection, etc.) that something like
> with-open-file ensures for you.
Personally I'd prefer guaranteed immediate destructors over with-open-file.
More flexibility, less syntax, and it matches what the CPython
implementation already does.
--
Rainer Deyke - ·······@eldwood.com - http://eldwood.com
"Rainer Deyke" <·······@eldwood.com> writes:
> Jon S. Anthony wrote:
>> Brian Kelley <·······@wi.mit.edu> writes:
>>> Now the usage is:
>>>
>>> f = SafeFileWrapper(open(...))
>>> print >> f, "A couple of lines"
>>> f.close()
>> ...
>>> I still have to explicitly close the file though when I am done with
>>
>> It's just this sort of monotonous (yet important) book keeping (along
>> with all the exception protection, etc.) that something like
>> with-open-file ensures for you.
>
> Personally I'd prefer guaranteed immediate destructors over with-open-file.
> More flexibility, less syntax, and it matches what the CPython
> implementation already does.
Right... all along until CPython introduces a more elaborate
gc scheme.
Note that reference-counting has problems with cyclic
references; probably not something that will bite you in the case of
open files, but definitely a problem you need to be aware of.
--
Raymond Wiker Mail: ·············@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/
Raymond Wiker <·············@fast.no> wrote in
···················@raw.grenland.fast.no:
> "Rainer Deyke" <·······@eldwood.com> writes:
>
>> Jon S. Anthony wrote:
>>> Brian Kelley <·······@wi.mit.edu> writes:
>>>> Now the usage is:
>>>>
>>>> f = SafeFileWrapper(open(...))
>>>> print >> f, "A couple of lines"
>>>> f.close()
>>> ...
>>>> I still have to explicitly close the file though when I am done
>>>> with
>>>
>>> It's just this sort of monotonous (yet important) book keeping
>>> (along with all the exception protection, etc.) that something like
>>> with-open-file ensures for you.
>>
>> Personally I'd prefer guaranteed immediate destructors over
>> with-open-file. More flexibility, less syntax, and it matches what
>> the CPython implementation already does.
>
> Right... all along until CPython introduces a more elaborate
> gc scheme.
... which is highly unlikely to happen without preservation of reference
counting semantics for files... google if you're _really_ interested :-/
> Note that reference-counting has problems with cyclic
> references; probably not something that will bite you in the case of
> open files, but definitely a problem you need to be aware of.
(a) true (by definition of cycle/ref.counting?)
(b) no relevance to CPython (which uses a generational collector
to reclaim reference cycles [with the regular finalizer problems]).
(c) why are open file objects special (are you saying objects with no
internal references are less likely to be reachable from a cycle,
or that there is something intrinsically special about (open?) files)?
-- bjorn
Bjorn Pettersen <···············@comcast.net> writes:
> Raymond Wiker <·············@fast.no> wrote:
>
> > "Rainer Deyke" <·······@eldwood.com> writes:
> >
> > > Personally I'd prefer guaranteed immediate destructors over
> > > with-open-file. More flexibility, less syntax, and it matches what
> > > the CPython implementation already does.
> >
> > Right... all along until CPython introduces a more elaborate
> > gc scheme.
>
> ... which is highly unlikely to happen without preservation of reference
> counting semantics for files... google if you're _really_ interested :-/
I hope you put assertion in your code so that it won't run under
Jython, because that's the kind of insidious bug that would be
*aweful* to find the hard way.
(I really don't understand why you wouldn't just want at least real
closures, so you can just use call_with_open_file, and not have to
worry about what GC you're using when *opening* *files*)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in
····················@famine.OCF.Berkeley.EDU:
> Bjorn Pettersen <···············@comcast.net> writes:
>
>> Raymond Wiker <·············@fast.no> wrote:
>>
>> > "Rainer Deyke" <·······@eldwood.com> writes:
>> >
>> > > Personally I'd prefer guaranteed immediate destructors over
>> > > with-open-file. More flexibility, less syntax, and it matches
>> > > what the CPython implementation already does.
>> >
>> > Right... all along until CPython introduces a more
>> > elaborate
>> > gc scheme.
>>
>> ... which is highly unlikely to happen without preservation of
>> reference counting semantics for files... google if you're _really_
>> interested :-/
>
> I hope you put assertion in your code so that it won't run under
> Jython, because that's the kind of insidious bug that would be
> *aweful* to find the hard way.
I'm assuming the "import win32con" etc., will do :-) Seriously, this
would be a minor issue compared with everything else I want to connect
to (e.g. 950KLocs of legacy c++ -- somehow I don't think I'd get the go-
ahead to rewrite that in Java <smile>).
> (I really don't understand why you wouldn't just want at least real
> closures, so you can just use call_with_open_file, and not have to
> worry about what GC you're using when *opening* *files*)
I'm not the one worrying here <wink>. I know exactly what Python does
and it is no cognitive burden. How would you rewrite these without
obfuscating the real work with book-keeping tasks, or leaving the file
open longer than necessary?
timestamp = datetime.now().strftime('%Y%m%d%H%M%S\n')
file('log', 'a').write(timestamp)
file('output', 'w').write(file('template').read() % locals())
nwords = sum([len(line.split()) for line in file('input')])
for line in file('input'):
print line[:79]
-- bjorn
In comp.lang.lisp Bjorn Pettersen <···············@comcast.net> wrote:
> I'm not the one worrying here <wink>. I know exactly what Python does
> and it is no cognitive burden.
"To foil the maintenance engineer, you must understand how he thinks."
Cheers,
-- Nikodemus
Bjorn Pettersen <···············@comcast.net> writes:
>> Note that reference-counting has problems with cyclic
>> references; probably not something that will bite you in the case of
>> open files, but definitely a problem you need to be aware of.
>
> (a) true (by definition of cycle/ref.counting?)
> (b) no relevance to CPython (which uses a generational collector
> to reclaim reference cycles [with the regular finalizer problems]).
I didn't know that (obviously :-)
> (c) why are open file objects special (are you saying objects with no
> internal references are less likely to be reachable from a cycle,
> or that there is something intrinsically special about (open?) files)?
I cannot think of any scenarios where open files would be
involved in a cycle, that's all. That doesn't mean that it's impossible.
--
Raymond Wiker Mail: ·············@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/
Raymond Wiker <·············@fast.no> wrote in
···················@raw.grenland.fast.no:
> Bjorn Pettersen <···············@comcast.net> writes:
>
>> (c) why are open file objects special (are you saying objects with no
>> internal references are less likely to be reachable from a cycle,
>> or that there is something intrinsically special about (open?)
>> files)?
>
> I cannot think of any scenarios where open files would be
> involved in a cycle, that's all. That doesn't mean that it's
> impossible.
Ok. Btw., creating such a cycle is easy,
a = [open('foo')]
b = [a]
a.append(b)
(i.e. any file that's reachable from a cycle). IIRC, A commonly used
'markup' library up until recently kept open file handles for all inline
images as part of the internal object state -- although I'd perhaps call
that more of a bug than a scenario? <wink>
-- bjorn
Bjorn Pettersen <···············@comcast.net> writes:
> Raymond Wiker <·············@fast.no> wrote in
> ···················@raw.grenland.fast.no:
[ SNIP ]
> > Note that reference-counting has problems with cyclic
> > references; probably not something that will bite you in the case of
> > open files, but definitely a problem you need to be aware of.
>
> (a) true (by definition of cycle/ref.counting?)
> (b) no relevance to CPython (which uses a generational collector
> to reclaim reference cycles [with the regular finalizer problems]).
> (c) why are open file objects special (are you saying objects with no
> internal references are less likely to be reachable from a cycle,
> or that there is something intrinsically special about (open?) files)?
Open file handles is a "scarce resource". It wasn't uncommon to have
an upper limit of 32, including strin, stdout and stderr, in older
unix environments. These days, 256 or 1024 seems to be more common
(default) upper limits. usually not a problem, but if one does a lot
of "open, write" and leave it for the GC to clean up, one *may* hit
resource starvation problems one wouldn't have hit, had teh file
handles been clsoed in a timely fashion.
//Ingvar
--
A routing decision is made at every routing point, making local hacks
hard to permeate the network with.
Raymond Wiker wrote:
> "Rainer Deyke" <·······@eldwood.com> writes:
>> Personally I'd prefer guaranteed immediate destructors over
>> with-open-file. More flexibility, less syntax, and it matches what
>> the CPython implementation already does.
>
> Right... all along until CPython introduces a more elaborate
> gc scheme.
>
> Note that reference-counting has problems with cyclic
> references; probably not something that will bite you in the case of
> open files, but definitely a problem you need to be aware of.
I'm all for more elaborate gc schemes. In particular, I want one that gives
me guaranteed immediate destructors even in the presence of reference
cycles. And I want to language specification to guarantee it.
Having to explicitly close files is something I'd expect in C or assembly,
but it has no place in high-level languages. And "with-open-file" is too
limiting. Let the computer do the work, not the programmer.
--
Rainer Deyke - ·······@eldwood.com - http://eldwood.com
"Rainer Deyke" <·······@eldwood.com> writes:
> I'm all for more elaborate gc schemes. In particular, I want one
> that gives me guaranteed immediate destructors even in the presence
> of reference cycles. And I want to language specification to
> guarantee it.
It's difficult to even put a requirement for "gc" in a language
_specification_ let alone one that _guarantees_ this sort of thing.
> Having to explicitly close files is something I'd expect in C or
> assembly, but it has no place in high-level languages. And
> "with-open-file" is too limiting. Let the computer do the work, not
> the programmer.
What's limiting about it? Or are you saying you want the computer (or
I suppose the language spec) to somehow also open your files for you
as well? What would that even mean? If you don't require that, then
you have to explicitly ask for the file to be opened. Well, that's
what with-open-file is.
/Jon
Jon S. Anthony wrote:
> "Rainer Deyke" <·······@eldwood.com> writes:
>
>> I'm all for more elaborate gc schemes. In particular, I want one
>> that gives me guaranteed immediate destructors even in the presence
>> of reference cycles. And I want to language specification to
>> guarantee it.
>
> It's difficult to even put a requirement for "gc" in a language
> _specification_ let alone one that _guarantees_ this sort of thing.
>
>
>> Having to explicitly close files is something I'd expect in C or
>> assembly, but it has no place in high-level languages. And
>> "with-open-file" is too limiting. Let the computer do the work, not
>> the programmer.
>
> What's limiting about it?
Unless I've completely misunderstood the concept, "with-open-file" requires
me to structure my program such that the file is opened at the beginning and
closed at the end of a block of code. In the absence of coroutines or
threads (both of which would significantly complicate the structure of my
code), this implies that the lifetime of open files is strictly
hierarchical: if file 'a' is opened while file 'b' is open, then file 'b'
must be closed before file 'a' is closed. More generally, it implies that
the file is opened at the beginning of a natural code block (instead of, for
example, on first use) and is closed at the end of the same block (instead
of, for example, when it is no longer needed).
--
Rainer Deyke - ·······@eldwood.com - http://eldwood.com
"Rainer Deyke" <·······@eldwood.com> writes:
> Jon S. Anthony wrote:
> > "Rainer Deyke" <·······@eldwood.com> writes:
> >
> >> I'm all for more elaborate gc schemes. In particular, I want one
> >> that gives me guaranteed immediate destructors even in the presence
> >> of reference cycles. And I want to language specification to
> >> guarantee it.
> >
> > It's difficult to even put a requirement for "gc" in a language
> > _specification_ let alone one that _guarantees_ this sort of thing.
> >
> >
> >> Having to explicitly close files is something I'd expect in C or
> >> assembly, but it has no place in high-level languages. And
> >> "with-open-file" is too limiting. Let the computer do the work, not
> >> the programmer.
> >
> > What's limiting about it?
>
> Unless I've completely misunderstood the concept, "with-open-file" requires
> me to structure my program such that the file is opened at the beginning and
> closed at the end of a block of code.
No it does not require this - it is what you use when this is the
natural expression for what you would want.
> In the absence of coroutines or threads (both of which would
> significantly complicate the structure of my code), this implies
> that the lifetime of open files is strictly hierarchical: if file
> 'a' is opened while file 'b' is open, then file 'b' must be closed
> before file 'a' is closed.
No, even within the with-open-file of b you could close a whenever or
wherever you wanted. The with-open-file for a just guarantees certain
things when you leave the scope.
> More generally, it implies that the file is opened at the beginning
> of a natural code block
Well, the block that it itself opens.
> and is closed at the end of the same block .
Is guaranteed to be closed. You could close it before this if that
made sense.
> (instead of, for example, on first use) ... (instead of, for
> example, when it is no longer needed)
OK. If your code needs to be more flexible in this, you would use
OPEN and/or CLOSE. If you had a particular open/close paradigm in
mind you could then write an abstraction (macro) akin to
with-open-file which provides behavior like what you say here and it
would generate the calls to open and close. I'm sure there are
scenarios where this might not be "reasonably doable".
/Jon
On Fri, Oct 24, 2003 at 06:09:55PM +0000, Rainer Deyke wrote:
> [...] and is closed at the end of the same block (instead of, for
> example, when it is no longer needed).
The reasoning behind WITH-OPEN-FILE is that file streams are resources
that should be allocated with dynamic extent, not indefinite. To make
that more concrete, it means that file streams should be closed
immediately after they are no longer being used (much like local
variables in C are immediately destroyed when the function returns).
I have seen debates before that argue that memory should be the only
resource managed by GC, and the opposite view that every resource should
be managable by GC (I don't think this is quite as feasible, but you can
look up the discussions on google, a year ago on c.l.l or so).
But WITH-OPEN-FILE doesn't prevent you from, say, having a file open the
entire time your program is running. Some people pointed out that you
can use OPEN and CLOSE, but also this would work fine:
(defvar *log-stream*) ;; an unbound special variable
(defun log (fmt-control &rest args)
(apply 'format *log-stream* fmt-control args))
(defun start (&key (log-file "log"))
(with-open-file (*log-stream* log-file
:direction :output
:if-exists :append)
;; *log-stream* is bound until this body exits
(call-other-functions)))
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
"Rainer Deyke" <·······@eldwood.com> writes:
> Jon S. Anthony wrote:
> > "Rainer Deyke" <·······@eldwood.com> writes:
> >
> >> I'm all for more elaborate gc schemes. In particular, I want one
> >> that gives me guaranteed immediate destructors even in the presence
> >> of reference cycles. And I want to language specification to
> >> guarantee it.
> >
> > It's difficult to even put a requirement for "gc" in a language
> > _specification_ let alone one that _guarantees_ this sort of thing.
> >
> >
> >> Having to explicitly close files is something I'd expect in C or
> >> assembly, but it has no place in high-level languages. And
> >> "with-open-file" is too limiting. Let the computer do the work, not
> >> the programmer.
> >
> > What's limiting about it?
>
> Unless I've completely misunderstood the concept, "with-open-file"
> requires me to structure my program such that the file is opened at
> the beginning and closed at the end of a block of code.
I don't know about "completely" but you've certainly misunderstood an
important point. Yes, WITH-OPEN-FILE attempts to open a file, executes
a block of code with the open stream bound to a variable, and then
closes the stream when the block is exited, even if something goes
wrong such as a condition being signaled.
But--and this is the bit I think you may have missed--if that's *not*
what you want you don't use WITH-OPEN-FILE. Lisp also provides OPEN
and CLOSE, that act as you'd expect and allow you to explicitly
control the lifetime of the file stream.
Which gets us back to Pascal's original point--WITH-OPEN-FILE is a
macro that abstracts a set of operations in a concise way. (In
addition to ensuring that the file is closed, it also allows us to
easily express what to do in certain situations while trying to open
the file--what to do if the file already exists or doesn't exist,
etc.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> But--and this is the bit I think you may have missed--if that's *not*
> what you want you don't use WITH-OPEN-FILE. Lisp also provides OPEN
> and CLOSE, that act as you'd expect and allow you to explicitly
> control the lifetime of the file stream.
Which leads us back to having to manually close files.
I DON'T want to manually close files. I DON'T want to deal with the
limitations of with-open-file. And, here's the important bit, I DON'T WANT
TO COMBINE OR CHOOSE BETWEEN THESE TWO METHODS, BOTH OF WHICH ARE FLAWED.
What I want to open a file and have it close automatically when I am done
with it. I can do that in C++. Why can't I do it in Python?
--
Rainer Deyke - ·······@eldwood.com - http://eldwood.com
On Fri, Oct 24, 2003 at 08:00:23PM +0000, Rainer Deyke wrote:
> I DON'T want to manually close files. I DON'T want to deal with the
> limitations of with-open-file. And, here's the important bit, I DON'T WANT
> TO COMBINE OR CHOOSE BETWEEN THESE TWO METHODS, BOTH OF WHICH ARE FLAWED.
I already discussed this in another post.
> What I want to open a file and have it close automatically when I am done
> with it. I can do that in C++. Why can't I do it in Python?
One major difference between C++ and Lisp/Python is that C++ lacks
closures. This means that local variables do not have to be considered
for allocation on the heap. So saying
{
ofstream f;
f.open ("output");
...
// I presume ofstream dtor closes file? I'm a bit rusty
}
is okay in C++ to obtain a similar effect as WITH-OPEN-FILE, though
I am not sure how well it does when it comes to abnormal conditions.
In Common Lisp, and presumably now Python, lexical scope combined with
higher-order functions implies that variables may be captured in a
closure and have indefinite extent. In CL, also, the language does not
define memory management; leaving open the possibility for a better
solution than GC. CL's answer to the handling of dynamic-extent
resources is WITH-OPEN-FILE, and also the other operators from which
WITH-OPEN-FILE is defined (such as UNWIND-PROTECT).
One final question: do you expect C++ to clean up dynamically allocated
ofstream objects, automatically?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Joe Marshall
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <ad7qs78a.fsf@ccs.neu.edu>
"Rainer Deyke" <·······@eldwood.com> writes:
> Peter Seibel wrote:
>> But--and this is the bit I think you may have missed--if that's *not*
>> what you want you don't use WITH-OPEN-FILE. Lisp also provides OPEN
>> and CLOSE, that act as you'd expect and allow you to explicitly
>> control the lifetime of the file stream.
>
> Which leads us back to having to manually close files.
>
> I DON'T want to manually close files. I DON'T want to deal with the
> limitations of with-open-file. And, here's the important bit, I DON'T WANT
> TO COMBINE OR CHOOSE BETWEEN THESE TWO METHODS, BOTH OF WHICH ARE FLAWED.
Let me see if I get this:
1. You don't want to tell the computer when you are done with the
file.
2. But the computer shouldn't wait until it can prove you are done
to close the file.
3. And you definitely are opposed to the idea of letting the
computer figure it out in general, but giving it hints when
it is important that it be prompt.
Do you want to tell the computer the file name, or should it read your
mind on that as well?
Joe Marshall wrote:
> 2. But the computer shouldn't wait until it can prove you are done
> to close the file.
Wrong. The computer can prove that I am done with the file the moment my
last reference to the file is gone. I demand nothing more (or less).
--
Rainer Deyke - ·······@eldwood.com - http://eldwood.com
From: ·············@comcast.net
Subject: Re: Why don't people like lisp?
Date:
Message-ID: <oew6fct8.fsf@comcast.net>
"Rainer Deyke" <·······@eldwood.com> writes:
> Joe Marshall wrote:
>> 2. But the computer shouldn't wait until it can prove you are done
>> to close the file.
>
> Wrong. The computer can prove that I am done with the file the moment my
> last reference to the file is gone. I demand nothing more (or less).
If you don't care about performance, this is trivial.
"Rainer Deyke" <·······@eldwood.com> writes:
>
> Joe Marshall wrote:
> > 2. But the computer shouldn't wait until it can prove you are done
> > to close the file.
>
> Wrong. The computer can prove that I am done with the file the moment my
> last reference to the file is gone. I demand nothing more (or less).
But in practice, the computer will only prove you are done with the file
the next time it decides to check. This is different from "the moment
my last reference...is gone" because for very good preformance reasons,
the computer doesn't check at each unbinding. (And no, reference counts
aren't a good idea either.)
Common Lisp as currently formulated does not have finalizers, although
there have been over the years proposals to add them. There are still
some unresolved issues regarding how to limit what such finalizers can
do. In any case, that will also not give immediate results.
--
Thomas A. Russ, USC/Information Sciences Institute
On Fri, 24 Oct 2003 20:00:23 +0000, Rainer Deyke wrote:
> I DON'T want to manually close files. I DON'T want to deal with the
> limitations of with-open-file. And, here's the important bit, I DON'T WANT
> TO COMBINE OR CHOOSE BETWEEN THESE TWO METHODS, BOTH OF WHICH ARE FLAWED.
>
> What I want to open a file and have it close automatically when I am done
> with it. I can do that in C++. Why can't I do it in Python?
In C++ you must choose between a local variable for the stream (which is
equivalent to with-open-file) or dynamically allocated object (which is
equivalent to open & close, where close is spelled delete).
You can't say that you want the C++ way and you don't want explicit open &
close and with-open-file, because they are equivalent! They differ only in
syntax details, but the style of usage and limitations are the same.
The only Python's problem is that there is no nice way to pass an
anonymous function to with-open-file, and try:finally: doesn't look so
nice either. I'm not defending Python's lack of large anonymous functions
but the interface of open, close & with-open-file in general, irrespective
of the programming language.
In particular you shouldn't wish for GC to find unused files because it's
impossible without sacrificing other GC properties. No languages does that
except misused CPython (you shouldn't rely on that).
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> In C++ you must choose between a local variable for the stream (which
> is equivalent to with-open-file) or dynamically allocated object
> (which is equivalent to open & close, where close is spelled delete).
I can also choose to have the stream reference counted (through
boost::shared_ptr or similar), and I can make it a member variable of an
object (tying the lifetime of the stream to the lifetime of the owning
object).
Now, I *could* write my own reference counting stream wrapper in Python,
together with a with_reference_to_stream HOF. I could, but it would be
expensive, not only in terms of performnace, but also in terms of syntax and
mental overhead.
> You can't say that you want the C++ way and you don't want explicit
> open & close and with-open-file, because they are equivalent! They
> differ only in syntax details, but the style of usage and limitations
> are the same.
The syntax is actually very significant here. Python's lack of anonymous
code blocks hurts, but even without this, the C++ syntax is more lightweight
and therefore more managable. Compare the levels of indentation:
void f()
{
std::fstream a("a"), b("b");
do_something(a, b);
std::fstream c;
do_something_else(a, b, c);
}
def f():
with_open_file(a = open("a")):
with_open_file(b = open("b")):
do_something(a, b)
with_open_file(c = open("c")):
do_something_else(a, b, c)
--
Rainer Deyke - ·······@eldwood.com - http://eldwood.com
"Rainer Deyke" <·······@eldwood.com> writes:
> I'm all for more elaborate gc schemes. In particular, I want one
> that gives me guaranteed immediate destructors even in the presence
> of reference cycles. And I want to language specification to
> guarantee it.
>
> Having to explicitly close files is something I'd expect in C or
> assembly, but it has no place in high-level languages. And
> "with-open-file" is too limiting. Let the computer do the work, not
> the programmer.
This is the problem with languages that are part excellent and part
work in progress (read: crap). You learn to trust the language from
using the excellent parts (which tend to be the basic things you first
encounter), and when you eventually stumble upon the not-so-great
parts you trust those parts, too. It's extremely unfortunate, IMHO.
--
Frode Vatvedt Fjeld
Jon S. Anthony wrote:
> It's just this sort of monotonous (yet important) book keeping (along
> with all the exception protection, etc.) that something like
> with-open-file ensures for you.
I can't say that I am completely won over but this is an important
point. Thanks for the discussion.
Brian
Brian Kelley <·······@wi.mit.edu> writes:
> The file is closed when the reference count goes to zero, in this case
> when it goes out of scope. This has nothing to do with the garbage
> collector, just the reference counter.
There is nothing in the Python spec that says that. One particular
implementation (CPython) happens to work that way, but another one
(Jython) doesn't. A Lisp-based implementation might not either.
> At least, that's the way I
> understand, and I have been wrong before(tm). The upshot is that it
> has worked in my experience 100% of the time and my code is structured
> to use (abuse?) this. How is this more difficult?
Abuse is the correct term. If your code is relying on stuff being
gc'd as soon as it goes out of scope, it's depending on CPython
implementation details that are over and above what's spelled out in
the Python spec. If you run your code in Jython, it will fail.
On Thu, Oct 23, 2003 at 10:53:21AM -0400, Brian Kelley wrote:
> The file is closed when the reference count goes to zero, in this case
> when it goes out of scope. This has nothing to do with the garbage
> collector, just the reference counter. At least, that's the way I
> understand, and I have been wrong before(tm). The upshot is that it has
> worked in my experience 100% of the time and my code is structured to
> use (abuse?) this. How is this more difficult?
I would see this as a dependence on an implementation artifact. This
may not be regarded as an issue in the Python world, though. (Are you
sure refcounting is used in all Python implementations? It is not that
great of a memory management technique except in certain situations).
One of the arguments against using finalizers to deallocate resources is
that it is unpredictable: a stray reference can keep the resource (and
maybe lock) open indefinitely.
This is not to say that Python couldn't achieve a similar solution to
the Lisp one. In fact, it could get quite nearly there with a
functional solution, though I understand that it is not quite the same
since variable bindings caught in closures are immutable. And it would
probably be most awkward considering Python's lambda.
> The difference here, as I see it, is that if an exception happens then
> the system has to wait for the garbage collector to close the file. In
> both examples there was no exception handling after the fact (after the
> file is closed). The macro, then, allows execution to continue with the
> closed file while the python version stops execution in which case the
> file is closed anyway. (unless it is in a another thread of execution
> in which the file is closed when it goes out of scope)
I'm not sure I understand this paragraph. The macro only executes the
body code if the file is successfully opened. The failure mode can be
specified by a keyword argument. The usual HANDLER-CASE and
HANDLER-BIND can be used to handle conditions with or without unwinding
the stack (you could fix and continue from a disk full error, for
example). If the stack is unwound out of the macro, by a condition
(abnormally), then there is an attempt to restore the state of the
filesystem (method probably dependent on the :if-exists parameter). If
control exits normally, the file is closed normally.
> In either case one still needs to write handling code to support the
> failure as this is most likely application specific. Using macros as a
> default handler seems very appropriate in lisp.
Not sure what `using macros as a default handler' means.
> This is a good thing, naturally. But the examples you have given are
> completely do-able (in one form or another) in python as it currently
> stands, either by creating a wrapper around a file object that can
> properly close down on errors or what not. In fact, this might be a
> better abstraction in some cases. Consider:
>
> (with-file-that-also-outputs-to-gui ... )
> (with-file-that-also-outputs-to-console ...)
>
> to
>
> (with-open-file (f ...
>
> in this case, f is supplied by some constructor that wraps the file to
> output to the gui or standard i/o and is passed around to various
> functions. Which is the better solution?
>
> I'm not saying that lisp can't do this, it obviously can, but macros
> might not be the appropriate solution to this problem ( they certainly
> aren't in python ;) )
The WITH-OPEN-FILE macro is not really an example of a macro that
performs something unique. It is, I find, simply a handy syntactic
abstraction around something that is more complicated than it appears at
first. And, in fact, I find myself creating similar macros all the time
which guide the use of lower-level functions. However, that doesn't
mean, for example, that I would try to defeat polymorphism with macros
(WITH-OPEN-FILE happens to be a very often used special case). I would
write the macro to take advantage of that situation.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> I would see this as a dependence on an implementation artifact. This
> may not be regarded as an issue in the Python world, though.
As people have pointed out, I am abusing the C-implementation quite
roundly. That being said, I tend to write proxies/models (see
FileSafeWrapper) that do the appropriate action on failure modes and
don't leave it up the garbage collector. Refer to the "Do as I Do, not
as I Say" line of reasoning.
> This is not to say that Python couldn't achieve a similar solution to
> the Lisp one. In fact, it could get quite nearly there with a
> functional solution, though I understand that it is not quite the same
> since variable bindings caught in closures are immutable. And it would
> probably be most awkward considering Python's lambda.
I don't consider proxies as "functional" solutions, but that might just
be me. They are just another way of generating something other than the
default behavior.
Python's lambda is fairly awkward to start with, it is also slower than
writing a new function. I fully admit that I have often wanted lambda
to be able to look up variables in the calling frame.
foo = lambda x: object.insert(x)
object = OracleDatabase()
foo(x)
object = MySqlDatabase()
foo(x)
But in practice I never write lambda's this way. I always bind them to
a namespace (in this case a class).
class bar:
def some_fun(x):
foo = lambda self=self, x: self.object.insert(x)
foo(x)
Now I could use foo on another object as well.
foo(object, x)
> I'm not sure I understand this paragraph. The macro only executes the
> body code if the file is successfully opened. The failure mode can be
> specified by a keyword argument.
I can explain what I meant with an example: suppose you wanted to tell
the user what file failed to open/write and specify a new file to open.
You will have to write a handler for this and supply it to
(with-open-file ...) or catch the error some other way.
> Not sure what `using macros as a default handler' means.
Apologies, I meant to say that writing a macro to handle particular
exceptions in a default-application wide way is a good thing and
appropriate.
> The WITH-OPEN-FILE macro is not really an example of a macro that
> performs something unique. It is, I find, simply a handy syntactic
> abstraction around something that is more complicated than it appears at
> first. And, in fact, I find myself creating similar macros all the time
> which guide the use of lower-level functions.
Right. I'm was only trying to point out, rather lamely I might add,
that the macros I have been seeing I would solve in an object-oriented
manner. This might simply be because python doesn't have macros. But I
like the thought of "here is your fail-safe file object, use it however
you like". It is hard for me to say which is 'better' though, I tend to
use the language facilities available (and abuse them as pointedly
stated), in fact it took me a while to realize that (with-open-file) was
indeed a macro, it simply was "the way it was done(TM)" for a while.
Certainly, new (and old) users can forget to use their file I/O in the
appropriate macro as easily as forgetting to use try: finally:
In python I use my FileSafeWrapper(...) that ensures that the file is
properly closed on errors and the like. As I stated, this wasn't handed
to me by default though like I remember as (with-file-open ...) was from
my CHLS days.
So let me ask a lisp question. When is it appropriate to use a macro
and when is it appropriate to use a proxy or polymorphism? Perhaps
understanding this would break my macro stale-mate.
p.s. given some of the other posts, I am heartened by the civility of
this particular thread.
Brian Kelley wrote:
> class bar:
> def some_fun(x):
> foo = lambda self=self, x: self.object.insert(x)
> foo(x)
oops, that should be
foo = lambda x, self=self: self.object.insert(x)
On Thu, 23 Oct 2003 14:37:57 -0400, Brian Kelley wrote:
> Python's lambda is fairly awkward to start with, it is also slower than
> writing a new function. I fully admit that I have often wanted lambda
> to be able to look up variables in the calling frame.
They can since Python 2.1 (in 2.1 with from __future__ import nested_scopes,
in 2.2 and later by default). This applies to nested functions as well.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In comp.lang.python Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> On Thu, 23 Oct 2003 14:37:57 -0400, Brian Kelley wrote:
>> Python's lambda is fairly awkward to start with, it is also slower than
>> writing a new function. I fully admit that I have often wanted lambda
>> to be able to look up variables in the calling frame.
> They can since Python 2.1 (in 2.1 with from __future__ import nested_scopes,
> in 2.2 and later by default). This applies to nested functions as well.
Variables in lexically enclosing scopes will be visible, but not
variables in calling frames.
Alex Martelli <·····@aleax.it> writes:
> Pascal Costanza wrote:
> ...
> > In the case of Python, couldn't you rightfully regard it as driven by a
> > one-man commitee? ;-)
>
> Ah, what a wonderfully meaningful view that is.
>
> >> Specifically: when you want to ALTER SYNTAX...
> >
> > If it were only about making small alterations to the syntax, I wouldn't
>
> I didn't say SMALL. Small or large, it's about alteration to the
> syntax. Other lispers have posted (on several of this unending
> multitude of threads, many but not all of which I've killfiled)
> stating outright that there is no semantic you can only implement
> with macros: that macros are ONLY to "make things pretty" for
> given semantics. If you disagree with them, I suggest pistols at
> ten paces, but it's up to you lispers of course -- as long as
> you guys with your huge collective experience of macros stop saying
> a million completely contradictory things about them and chastising
> me because (due, you all keep claiming, to my lack of experience)
> I don't agree with all of them, I'll be glad to debate this again.
Why is this so surprising? Maybe different lispers use macros for
different things, or see different advantages to them? What all have
in common though, is that they all consider macros a valuable and
important part of a programming language. What I have seen in this
thread are your (Alex) lengthy posts where you reiterate the same
uniformed views of macros over and over again. You seem to have made
your mind up already, even though you don not seem to have fully
understood Common Lisp macros yet. Am I wrong?
> Till then, this is yet another thread that get killfiled.
Why do you bother to post if you are not even going to read the
responses?
<snip>
> But, until then -- bye. And now, to killfile this thread too....
What is the point in initiating a subthread by an almost 300-line,
very opinionated post just to immediately killfile it?
Bj�rn
From: Bengt Richter
Subject: class FLModule to translate/import foreign-source-lang modules? [Was: Re: Why don't people like lisp?]
Date:
Message-ID: <bn1mad$61i$0@216.39.172.122>
On Mon, 20 Oct 2003 21:25:55 +0200, Pascal Costanza <········@web.de> wrote:
>Alex Martelli wrote:
[...]
>> ...you can't "just alter Python's own syntax with your own changes":
>> you have plenty of choices (implement your chosen semantics within
>> Python's syntax, use any of N available parsers to parse your favourite
>> syntax -- user EITHER "program generators" OR interpreters at any
>> level on the parsed forms -- etc, etc). You just don't have the one
>> choice of *altering Python's own syntax wholly within Python itself*.
>
>Exactly. Lisp-style Macros make these things a breeze. The other
>alternatives you suggest are considerably more complicated. As I have
>said before, Lisp makes the simple things a little bit harder (-> syntax
>for beginners), so that the hard things become considerably simpler (->
>adding sophisticated abstractions in order to considerably reduce the
>amount of code for complex tasks).
>
>> Describing a situation of having 99 available strategies rather than
>> 100 as "doesn't give you a choice" can be charitably described as
>> "ridiculous", it seems to me.
>
>I know about these choices, I have tried them all. I have written
>compilers, interpreters, with and without parser generators, and have
>co-designed and used transformation frameworks. These things are
>considerably harder to build, and you need to spend a considerable
>amount of time on the technology itself which distracts you from solving
>the problem at hand. With Lisp-style macros, these things are much
>simpler to handle once you have gotten it.
>
>> But _in practice, people don't_, except for play and experiments
>> of various kinds. You can find a bazillion extremely varied
>> extensions to Python of all imaginable kinds, *BUT* they're ALL
>> *add-ons*, NEVER alteration of syntax or fundamental semantics
>
>You still have a wrong idea of how macros work. Macros are of course
>also only add-ons. You don't alter unrelated syntax or unrelated
>portions of source code, and you don't change fundamental semantics.
>
>Instead of spreading misconceptions you should really start to get to
>know the things better that you criticize.
>
Maybe we can put this thing to bed by a Python foreign-language-module-encapsulating class,
and a functionally equivalent lisp a macro for lispers, so we could write something like (sketch)
module_from_lisp = FLModule('lisp','lisp_file_path_or_remote_spec',
'interface spec string', 'make info string')
where the last args would have sensible defaults, but all would be expected to be passed
to a translation process selected by the language name (the first arg) unless a cached module
could be accessed without calling for any translation.
For C or C++ this could generate a DLL extension module and import that, assuming the
relevant tools are available. Otherwise an informative exception could be raised.
For other languages, a DLL that serves as an access proxy for whatever. Letting the source
be specified by a remote spec like an URL with some authentication requirement might open
some interesting uses (language name 'python' would be allowed ;-) (maybe even 'python1.5.2' ;-)
I know there are already pieces for integrating/accessing C, but the idea here is to
unify the concept into one standard general form expressed by a standard class which could
always have a presence in builtins.
Just an alpha idea at this point ;-)
Hm, think I'll switch the title, in case people aren't reading the old subject thread ;-)
Regards,
Bengt Richter
Alex Martelli <·····@aleax.it> writes:
> > The approach for Lisp is to write a domain-specific language for the
> > problem at hand, and then to write the program in that domain-specific
>
> Right. People who fancy themselves as language designers will surely
> be happier that way. People who prefer to use languages used by better
> language designers than themselves, such as me, will be happier with
> Python.
Any programmer writing a program is by necessity also a language
designer. The act of writing a program consists of designing a
language. Did you read Steele's "Growing a Language", which someone
posted a pointer to earlier in the thread? It is essentially about
Java, but is very enlightening on the "programming as language design"
issue.
There is nothing magical or special about syntactic abstraction. It is
just an abstraction mechanism like the rest of them.
Bj�rn
·········@yahoo.com (dan) writes:
> Google ate my long post, so I'll make it simple.
Thank God.
> Lisp failed (yes, it did) because of the parentheses.
I see. I must be imagining the (at least 4) successful
commercial vendors who are willing to sell me a lisp.
And this in the presence of several superb free alternatives!
One wonders if the successful Python language could support
even _one_ commercial vendor?
You have an interesting definition of the word "failed".
> Normal people can't parse 13 close-parens easily.
Ever heard of emacs?
> Functional notation is non-intuitive and hard to read.
Mathematical notation is similarly difficult. Yet mathematicians
do fine. Perhaps some people need to solve problems more difficult
than yours?
[To other pythonistas; my apologies; I have nothing but
admiration for Python, if for no other reasons that it
now gives us all an alternative to Perl. Good work!]
Francis Avila wrote:
> 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.
There is no such thing as "the" ordinary way of thinking, except in
the mind of people who have not enquired enough about the ways of thinking
of other people to discover this "astonishing" fact - but I will concede that
failure to enquire is more likely to occur among adepts of procedural and
imperative authority (authority - not thinking).
This said, I find it a bit ridiculous to oppose lisp and python along that
scale; compared to logic programming (eg Prolog), or even to reverse-polish
stack-based syntax like in PostScript - and given that both python and lisp
are dynamic and don't require types declarations - programming in python and
programming in lisp feel very similar (except for a few things you can do in
lisp but not in python).
...
> 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.
Everybody finds one's own mother's style of cooking more palatable, but that's
no excuse to reflect on things as if everybody had the same mother.
> 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.
Python and lisp imho compete for the status of easiest language to program in;
python differs from lisp in that in leaves you less freedom to shoot yourself
in the foot with meta-programming (having access to code as an easy data
structure, something Prolog has too). And python also has for itself a free
reference implementation running on all platforms, with an extensive standard
lib (that's why I use it rather than lisp).
> 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.
The real issue is what language gets taught to beginners and what language is
required by employers, and such choices are mostly historical accidents of fad
and fashion.
> 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")
This is not serious. Write down a piece of idiomatic python, and I'm sure some
lisper will show you how well lisp can mimic that.
>
> ...then lisp will take over the universe. Never mind that the symbolic
> logic version has more precision.
Lisp isn't symbolic logic. Symbolic logic isn't the example you gave.
> 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
I have started with Python because I needed a fast way to develop
solutions using OO. Python fullfiled my expectations.
The point is that I have started with Python because I was missing
something, not because I wanted to expand my knowledge.
Learning one programming language is a burden, because there is always to
little time for everything.
Lisp is probably cool, but what will I gain from Lisp ? What will
justify my investment, I mean spent time ?
DG
On Mon, 13 Oct 2003 16:23:46 -0700 (PDT), ·······@ziplip.com wrote:
> 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.
·······@ziplip.com wrote in message news:<········································@ziplip.com>...
> 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.)
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
On Tue, 14 Oct 2003 16:16:52 GMT, Wade Humeniuk <········@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)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad <··············@chello.no> writes:
> On Tue, 14 Oct 2003 16:16:52 GMT, Wade Humeniuk
> <········@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: ·············@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/
From: Andreas Hinze
Subject: Re: BIG successes of Lisp (was ...)
Date:
Message-ID: <3F8C2E3B.287FAAFE@smi.de>
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)
>
That new. But it may explain Peter Norvigs role there.
From where do you know that ?
Best
AHz
John Thingstad <··············@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.
--
Fred Gilham ······@csl.sri.com
The density of a textbook must be inversely proportional to the
density of the students using it. --- Dave Stringer-Calvert
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> John Thingstad <··············@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'.
<·······@ziplip.com> wrote in message
·············································@ziplip.com...
> 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. 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.
"Scott McKay" <···········@comcast.net> wrote in message
····························@sccrnsc01...
>
> <·······@ziplip.com> wrote in message
> ·············································@ziplip.com...
> > 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. 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.
Does Orbitz have anything to do with Python?
If not, please leave c.l.py off further discussion thereof.
> 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
E.N. Fan:
> 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
·····@dalkescientific.com
"Andrew Dalke" <······@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.
The ITA engine does a *vastly* more powerful search than either
Travelocity or Expedia.
>>>>> "Joe" == Joe Marshall <···@ccs.neu.edu> writes:
Joe> "Andrew Dalke" <······@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
Raymond Toy <···@rtp.ericsson.se> writes:
>>>>>> "Joe" == Joe Marshall <···@ccs.neu.edu> writes:
>
> 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.
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.
Scott McKay wrote:
> <·······@ziplip.com> wrote in message
> ·············································@ziplip.com...
>
>>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. 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.
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
·······@ziplip.com wrote:
> 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