The rate at which the number of python users has grown and is growing
is phenomenal. What caused this? Lisp has all the power Python has.
Python draws a lot from Lisp but its no way near Lisp. What is the
secret to its great PR ?
Comments?
Nikhil Ketkar
Nikhil Ketkar wrote:
> The rate at which the number of python users has grown and is growing
> is phenomenal. What caused this? Lisp has all the power Python has.
> Python draws a lot from Lisp but its no way near Lisp. What is the
> secret to its great PR ?
Because popularity has little to do with power. Popularity of a
programming language is determined to a great extent by its convenience
for relatively simple everyday programming tasks; with acceptable
performance of the program.
Python is a language that offers most of benefits of lisp for most of
everyday programming without forcing the programmer into the Lisp Way
(which is perversive for most programmers). Lisp will never be popular
in masses, it requires the level of abstract reasoning most human
beings are uncapable of.
Another thing to note is any tools cuts at two edges: a more powerful
language makes it possible to write both better and worse programs.
Python is just write for the majority; but Common Lisp goes too far --
bad programs are much easier to write than they should be.
And, as a consequence of the two points above, a chance that a program
written in Common Lisp is unreadable by anyone else is so much greater
than if it were written in Python, that Common Lisp is unpopular just
for this reason -- you normally don't want average programmers to write
their junk code in Common Lisp. When they write it in Python, you at
least can understand what they meant and fix it.
David
On Tue, 26 Apr 2005 22:32:32 -0700, Nikhil Ketkar wrote:
> The rate at which the number of python users has grown and is growing
> is phenomenal. What caused this? Lisp has all the power Python has.
> Python draws a lot from Lisp but its no way near Lisp. What is the
> secret to its great PR ?
>
> Comments?
Python is, for the masses of programmers (and managers!) familiar with
C-like syntax, much more approachable than Lisp; and for lots of things
it's good enough - I programmed in Python for a few years, before hitting
the ceiling and (re)discovering Lisp not so long ago. Also, Lisp is old,
and Python is (though older than Java) shiny and new.
--
Christopher
It might also be that Lisp hasn't fully lost its reputation of being
horribly slow...
A theory is that managers do whatever other managers do, since that's
the safest path. I'm just glad that there is a trend towards more
"lispy" languages. :-)
You might find Paul Graham's essays interesting. The following essays
touch this matter:
"The Python Paradox" (http://www.paulgraham.com/pypar.html),
"If Lisp is So Great" (http://www.paulgraham.com/iflisp.html),
"The Hundred-Year Language" (http://www.paulgraham.com/hundred.html),
and "Beating the Averages" (http://www.paulgraham.com/avg.html).
Enjoy!
"Toki" <··········@gmail.com> writes:
> It might also be that Lisp hasn't fully lost its reputation of being
> horribly slow...
That doesn't make much sense... compiled Common Lisp is easily
10-100 times faster than Python, for operations that are not
implemented in C in Python.
On the other hand, perception and reality do not always overlap :-)
> A theory is that managers do whatever other managers do, since that's
> the safest path. I'm just glad that there is a trend towards more
> "lispy" languages. :-)
--
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
> That doesn't make much sense... compiled Common Lisp is easily
>10-100 times faster than Python, for operations that are not
>implemented in C in Python.
I didn't say that it was sensible, just that it's still one of the most
popular (and in many cases, the most faulty one) reason for not using
it.
Besides, who want to use a strange AI-language with bizarre syntax,
anyway? In the eternal wisdom of the middle management we trust! Give
us Java! Java, we chant! ;-)
> On the other hand, perception and reality do not always
overlap :-)
No, not always. :-)
Although it's sad to see people ignore such a wonderful language as
lisp...
Raymond Wiker wrote:
> "Toki" <··········@gmail.com> writes:
>
>
>>It might also be that Lisp hasn't fully lost its reputation of being
>>horribly slow...
>
>
> That doesn't make much sense... compiled Common Lisp is easily
> 10-100 times faster than Python, for operations that are not
> implemented in C in Python.
Yeah, but Common Lisp makes it really easy (for me) to write
really slow code. :) For someone coming from Python to
Common Lisp, as I have, it will appear that CL is much slower
than Python, simply because translated Python seems so often
to be slower in CL than it was in Python. Eventually it can
be faster, but the result won't look much like the original
algorithm, in my experience. Perhaps this is a result of using
mostly CMUCL?
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
On Sun, 01 May 2005 20:14:54 -0400, Randall Randall wrote:
> Raymond Wiker wrote:
>> "Toki" <··········@gmail.com> writes:
>>
>>
>>>It might also be that Lisp hasn't fully lost its reputation of being
>>>horribly slow...
>>
>>
>> That doesn't make much sense... compiled Common Lisp is easily
>> 10-100 times faster than Python, for operations that are not
>> implemented in C in Python.
>
> Yeah, but Common Lisp makes it really easy (for me) to write
> really slow code. :) For someone coming from Python to
> Common Lisp, as I have, it will appear that CL is much slower
> than Python, simply because translated Python seems so often
> to be slower in CL than it was in Python. Eventually it can
> be faster, but the result won't look much like the original
> algorithm, in my experience. Perhaps this is a result of using
> mostly CMUCL?
In my experience, directly translating nontrivial code (and often even
trivial code) from one language/implementation to another will often
result in degraded performance. Every language has its own techniques and
idioms that produce faster code. I find it easier to get there in CL than
in Python though, despite the "one obvious way to do it" of Python mostly
getting special attention wrt optimization..
--
Christopher
Randall Randall wrote:
> Raymond Wiker wrote:
>
>> "Toki" <··········@gmail.com> writes:
>>
>>
>>> It might also be that Lisp hasn't fully lost its reputation of being
>>> horribly slow...
>>
>>
>>
>> That doesn't make much sense... compiled Common Lisp is easily
>> 10-100 times faster than Python, for operations that are not
>> implemented in C in Python.
>
>
> Yeah, but Common Lisp makes it really easy (for me) to write
> really slow code. :) For someone coming from Python to
> Common Lisp, as I have, it will appear that CL is much slower
> than Python, simply because translated Python seems so often
> to be slower in CL than it was in Python. Eventually it can
> be faster, but the result won't look much like the original
> algorithm, in my experience. Perhaps this is a result of using
> mostly CMUCL?
Well, the CL algorithm usually looks better, doesn't it? :) And it
will always be faster, BTW. :)
Apart from that there is the usual problem of people comparing apples to
oranges. The "file read" example is a case in point. The `read' method
of Python is equivalent to READ-SEQUENCE in CL, not READ. Hence the
mismatch in expectations.
All in all, translating algorithms line by line is not a very good way
of doing things.
Cheers
--
marco
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d55463$gtj$1@ulric.tng.de>
Randall Randall schrieb:
> Raymond Wiker wrote:
>
>> "Toki" <··········@gmail.com> writes:
>>
>>
>>> It might also be that Lisp hasn't fully lost its reputation of being
>>> horribly slow...
>>
>>
>>
>> That doesn't make much sense... compiled Common Lisp is easily
>> 10-100 times faster than Python, for operations that are not
>> implemented in C in Python.
>
>
> Yeah, but Common Lisp makes it really easy (for me) to write
> really slow code. :) For someone coming from Python to
> Common Lisp, as I have, it will appear that CL is much slower
> than Python, simply because translated Python seems so often
> to be slower in CL than it was in Python. Eventually it can
> be faster, but the result won't look much like the original
> algorithm, in my experience. Perhaps this is a result of using
> mostly CMUCL?
I personally can't second that. In fact I usually saw a good speedup. I
suppose you compiled your code ;-)
Andr�
--
Randall Randall wrote:
> Yeah, but Common Lisp makes it really easy (for me) to write
> really slow code. :) For someone coming from Python to
> Common Lisp, as I have, it will appear that CL is much slower
> than Python, simply because translated Python seems so often
> to be slower in CL than it was in Python.
What sort of code? Some Python programs spend all their
time in library code implemented in C; there's no particular
reason to expect a translation into CL to do better.
And which CL implementation? If you're moving from Python
to CLISP then you'll find that a lot of the things that
are slow in Python are pretty slow in CLISP too; CLISP
is bytecode-based, just like (the dominant implementation
of) Python.
(Which is not to knock CLISP; it's a fine piece of
software.)
--
Gareth McCaughan
.sig under construc
This is a consolidated reply.
Christopher Koppler wrote:
> In my experience, directly translating nontrivial code (and often even
> trivial code) from one language/implementation to another will often
> result in degraded performance. Every language has its own techniques and
> idioms that produce faster code. I find it easier to get there in CL than
> in Python though, despite the "one obvious way to do it" of Python mostly
> getting special attention wrt optimization..
I find it easier to get there in Common Lisp for some
kinds of things, but those things are usually things I
haven't done before in any language, like writing a
database access library for SQLite. In Common Lisp, I
can actually do things like that; in Python, I wouldn't
even try. But things that I do a whole lot of in Python,
such as string mangling, seem harder to figure out in
Common Lisp.
Andr� Thieme wrote:
> I personally can't second that. In fact I usually saw a good speedup. I suppose you compiled your code ;-)
Indeed. :)
Marco Antoniotti wrote:
> All in all, translating algorithms line by line is not a very good way of doing things.
Nor was I doing that. It's more a reimplementation of
the same overarching solution. I'm not referencing my
Python code function by function, but building something
that does the same job. Sorry if I misled you. :)
Gareth McCaughan wrote:
> Randall Randall wrote:
>>Yeah, but Common Lisp makes it really easy (for me) to write
>>really slow code. :) For someone coming from Python to
>>Common Lisp, as I have, it will appear that CL is much slower
>>than Python, simply because translated Python seems so often
>>to be slower in CL than it was in Python.
>
>
> What sort of code? Some Python programs spend all their
> time in library code implemented in C; there's no particular
> reason to expect a translation into CL to do better.
It's virtually all manipulating strings and doing database
queries, since my business is mostly web applications. I
viewed the move to CL as an opportunity to build a web
applications framework that did things just the way I like,
and while I'm not there yet, I'm close. However, I haven't
done a lot of profiling yet, and so the application server
usually takes about 1/3 second to deliver a page, which is
fine for the moment, but will be a problem when I need to
serve pages faster than that. I did knock off some of the
low-hanging fruit, and when I finished, there no longer
seemed to be anything with a really outstanding figure in
the time or memory used. I'll get back to it in the future.
For comparison, however, the web application framework I
use in Python, Webware for Python, serves pages in about
1/50 second, with the same setup (actually, the same running
instance of Apache) and roughly the same complexity level.
I've chalked this up to my own inexperience at writing
Common Lisp, of course. I've only been doing this for a
year. :)
> And which CL implementation? If you're moving from Python
> to CLISP then you'll find that a lot of the things that
> are slow in Python are pretty slow in CLISP too; CLISP
> is bytecode-based, just like (the dominant implementation
> of) Python.
>
> (Which is not to knock CLISP; it's a fine piece of
> software.)
CMUCL. I'm using CMUCL because it's the only implemenation
that works on both my Mac development box and my Gentoo server.
Before you object, I know that other implementations *should*
work on both, including CLISP, SBCL, and some non-Free ones --
it's just that my server install is somewhat flaky, and I'd
rather not troubleshoot it, since only compiling very large
programs shows any problem. As I move to Mac servers instead,
I'll probably switch to OpenMCL.
--
Randall Randall <·······@randallsquared.com>
"Lisp will give you a kazillion ways to solve a problem.
But (1- kazillion) are wrong." - Kenny Tilton
"Toki" <··········@gmail.com> writes:
> It might also be that Lisp hasn't fully lost its reputation of being
> horribly slow...
> A theory is that managers do whatever other managers do, since that's
> the safest path. I'm just glad that there is a trend towards more
> "lispy" languages. :-)
>
WARNING - I'm a manager :-(
Yes, the 'managers do what other managers do' is a real problem. To
some extent I blame the notion of "Best Practice" which is what gets
thrown at me all the time. It seems most managers want to take the
safe route - if I do what others are doing, I can't be blamed when it
all goes wrong attitude. What I find interesting is that at the same
time, I'm often told that we need to be creative and "puch above our
weight" or get in front of the competition etc. To me the irony here
is that my experience has been you only get in front by
differentiating yourself from the rest and by taking a few chances -
the opposite of the twisted interpretation of "best practice" which I
come across.
WRT the python v lisp question. I've been teaching myself lisp to help
keep my sanity and as a break from the 'management' stuff I now have
to do (I'm really just a frustrated programmer!). I originally thought
of learning python and started to do that. But to be honest, for me,
python just wasn't 'new' or 'interesting' enough to keep my
attention. I'd always liked Lisp from the small (and badly taught)
exposure I had at Uni, but hadn't returned to it since completing my
degree - instead I concentrated on what would get me a job ie. C/C++,
Java, Perl, databases and SQL etc.
The reason I originally thought of learning python was because I'd
heard it was similar in its functionality to using perl, but with a
better structure and more consistent syntax - meaning you could do
largeer projects that would be more manageable than doing it in
perl. Although I quite like perl for small sys admin type chores, I've
found it a pain to maintain when its used in a large project with lots
of different people codeing in their own unique perl style etc. Python
also has better exposure in that many Linux distributions are using
perl for various utilities and for things which were previously done
in perl. I've yet to see a general purpose CL utility used on a Linux
distribution (though you do have things like the sawfish window
manager - which although written in rep and more scheme like than lisp
is more lispy than anything else and of course there is emacs and
guile).
In general, CL still hasn't been able to get past the old criticisms
of being slow, being for AI or being no good because its 'old'. Python
has not had to contend with any of this and to some extent has been
able to claim it has the advantages of Lisp and none of the
disadvantages (mainly misconceptions!).
I think CL could probably improve its perception and acceptance if we
had some good 'killer apps' for Linux and more books like Peter's
Practicle common Lisp. Of course, that assumes we want the masses to
know about our secret little advantage :-).
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
> WARNING - I'm a manager :-(
>
> Yes, the 'managers do what other managers do' is a real problem.
> [...]
Oh, I'm sorry. I didn't mean to hurt anyone's feelings. What I mean is
that, as you say, there are many doughy, puppet-type managers out there
that do whatever all the others do. I sincerely hope that there are
more of your kind out there. :-)
> WRT the python v lisp question.
I've tried Python, and liked it. However, I've not found a place of use
for it. The problems I can solve with Python, I use Ruby instead.
I'm not sure, though, that CL suits very well for the problem-domain
scripting languages fit in. Small-scale system administration with Lisp
tend to be like shooting pigeons with a cannon: the language is far too
powerful.
As for application-development, I see no real obstackle more than the
lack of standarized, implementation-independant libraries.
(Please don't flame me, as yet I'm merely a curious spectator.)
Tim X <····@spamto.devnul.com> writes:
> [...]
> The reason I originally thought of learning python was because I'd
> heard it was similar in its functionality to using perl, but with a
> better structure and more consistent syntax - meaning you could do
> largeer projects that would be more manageable than doing it in
> perl.
Which gives me an idea for someone who would want to have Common-Lisp
compete with perl:
Take each feature of perl, and implement a layer on Common Lisp to
make it as easy or easier to use in Common Lisp than in perl.
Name the package PERCL.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
On 26 Apr 2005 22:32:32 -0700, "Nikhil Ketkar"
<············@gmail.com> wrote:
>The rate at which the number of python users has grown and is growing
>is phenomenal. What caused this? Lisp has all the power Python has.
>Python draws a lot from Lisp but its no way near Lisp. What is the
>secret to its great PR ?
Probably because Python solves (or helps to solve) some problems
that Lisp doesn't...
A.L.
On Wed, 27 Apr 2005 12:00:19 -0400, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
>
>
>A.L. wrote:
>> On 26 Apr 2005 22:32:32 -0700, "Nikhil Ketkar"
>> <············@gmail.com> wrote:
>>
>>
>>>The rate at which the number of python users has grown and is growing
>>>is phenomenal. What caused this? Lisp has all the power Python has.
>>>Python draws a lot from Lisp but its no way near Lisp. What is the
>>>secret to its great PR ?
>>
>>
>> Probably because Python solves (or helps to solve) some problems
>> that Lisp doesn't...
>
>Like what?
>
Ask people who are using Python but not Lisp...
A.L.
A.L. wrote:
> On Wed, 27 Apr 2005 12:00:19 -0400, Marco Antoniotti
> <·······@cs.nyu.edu> wrote:
>
>
>>
>>A.L. wrote:
>>
>>>On 26 Apr 2005 22:32:32 -0700, "Nikhil Ketkar"
>>><············@gmail.com> wrote:
>>>
>>>
>>>
>>>>The rate at which the number of python users has grown and is growing
>>>>is phenomenal. What caused this? Lisp has all the power Python has.
>>>>Python draws a lot from Lisp but its no way near Lisp. What is the
>>>>secret to its great PR ?
>>>
>>>
>>>Probably because Python solves (or helps to solve) some problems
>>>that Lisp doesn't...
>>
>>Like what?
>>
>
>
> Ask people who are using Python but not Lisp...
Usually these people do not know Common Lisp.
The canonical example is http://www.strout.net/python/pythonvslisp.html,
which demonstrates the point, even factoring out the time since the page
was published. Note that the page still pops up in the first googling
of "python lisp".
There are exceptions, of course, like Norvig, who obviously knows what
he is talking about, but the rule holds. After all one the cosmic
truths is Greenspun's Tenth Rule of Programming. :)
My personal experience, anecdotical as it is, has oftes shown this
pattern of conversation with most Pythonistas.
Pythonista: you should look at how this is done in Python, it is really
cool.
Common Lisper: <says nothing and just shows how the same thing is done
in a cooler, more general and more elegant way in CL>
Pyhtonista: That is Lisp, I don't want to/I don't have time to/why
should I learn it.
Common Lisper: Let's continue like this, let's hurt ourselves! :)
Cheers
--
Marco
From: Karl A. Krueger
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rbis$9i5$1@baldur.whoi.edu>
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> Usually these people do not know Common Lisp.
> The canonical example is http://www.strout.net/python/pythonvslisp.html,
> which demonstrates the point, even factoring out the time since the page
> was published. Note that the page still pops up in the first googling
> of "python lisp".
There are some pretty embarrassing errors on that page:
WRONG: LISP's most-used datatype is the list, but strings are also a
basic type, and dictionaries are supported to some degree
through association lists.
WRONG: LISP can achieve a limited sort of exception handling through
"catch" and related operators
WRONG: LISP uses CLOS, which is a fairly (but not completely) standard
object extension to LISP.
SILLY: A high-level language is especially valuable when it can be
easily extended with high-performance code written in C or C++.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
"Karl A. Krueger" <········@example.edu> writes:
>
>SILLY: A high-level language is especially valuable when it can be
> easily extended with high-performance code written in C or C++.
SILLY: It derides Lisp's syntax (need for QUOTE) and totally ignores
the imho totally moronic way of deriving block structure from
whitespace indentation in Python. That alone is a show-stopper
for me in that language ("we're to kewL for an `end'
keyword"?).
mkb.
From: Karl A. Krueger
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4s374$hkq$1@baldur.whoi.edu>
Matthias Buelow <···@incubus.de> wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>>SILLY: A high-level language is especially valuable when it can be
>> easily extended with high-performance code written in C or C++.
>
> SILLY: It derides Lisp's syntax (need for QUOTE) and totally ignores
> the imho totally moronic way of deriving block structure from
> whitespace indentation in Python. That alone is a show-stopper
> for me in that language ("we're to kewL for an `end'
> keyword"?).
Knocking Python for the whitespace thing is the equivalent of parroting
the "Lots of Irritating Silly Parentheses" joke. It means you aren't
looking in far enough to see the bits that actually cause pain.
The absence of mutable strings (ow, the consing!); 1/2 == 0; the macro-
phobia; the lack of a working lambda; the lack of continuable errors;
the global interpreter lock ....
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
"Karl A. Krueger" <········@example.edu> writes:
>Knocking Python for the whitespace thing is the equivalent of parroting
>the "Lots of Irritating Silly Parentheses" joke. It means you aren't
I don't think it's the same. S-Expressions (without CL macros and
read-macros, of course) are context free. I don't think Python is.
With that whitespace stuff, it looks at least context-sensitive to me.
If it is, then it's a huge deviation from existing practice for
the syntax of virtually all "normal" programming languages.
mkb.
Matthias Buelow wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>
>> Knocking Python for the whitespace thing is the equivalent of parroting
>> the "Lots of Irritating Silly Parentheses" joke. It means you aren't
>
> I don't think it's the same. S-Expressions (without CL macros and
> read-macros, of course) are context free. I don't think Python is.
> With that whitespace stuff, it looks at least context-sensitive to me.
> If it is, then it's a huge deviation from existing practice for
> the syntax of virtually all "normal" programming languages.
Not so very huge. Make the lexer return INDENT and OUTDENT
tokens when the indentation level changes; then the grammar
the parser actually works with is context-free.
The whitespace thing turns out to work quite well in practice.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
>Not so very huge. Make the lexer return INDENT and OUTDENT
>tokens when the indentation level changes; then the grammar
>the parser actually works with is context-free.
Yes, that could be done of course, although that still does not make
the _language_ Python context-free (since the INDENT and OUTDENT
generating itself is not context free either). ;-)
mkb.
Matthias Buelow wrote:
> Gareth McCaughan <················@pobox.com> writes:
>
>> Not so very huge. Make the lexer return INDENT and OUTDENT
>> tokens when the indentation level changes; then the grammar
>> the parser actually works with is context-free.
>
> Yes, that could be done of course, although that still does not make
> the _language_ Python context-free (since the INDENT and OUTDENT
> generating itself is not context free either). ;-)
Yeah, but who cares?
- As far as the computer is concerned, the lack of
context-free-ness isn't a problem, because the
lexer can deal with it.
- As far as the human is concerned, the lack of
context-free-ness isn't a problem, because humans
can also think in terms of indents and outdents.
(Empirically, there isn't a problem here.)
- As far as purely theoretical elegance is concerned,
no really practical language is likely to be
much good. If you want the lambda calculus,
you know where to find it :-).
--
Gareth McCaughan
.sig under construc
From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4s6tm$912$1@ulric.tng.de>
Karl A. Krueger schrieb:
> Matthias Buelow <···@incubus.de> wrote:
>
>>"Karl A. Krueger" <········@example.edu> writes:
>>
>>>SILLY: A high-level language is especially valuable when it can be
>>> easily extended with high-performance code written in C or C++.
>>
>>SILLY: It derides Lisp's syntax (need for QUOTE) and totally ignores
>> the imho totally moronic way of deriving block structure from
>> whitespace indentation in Python. That alone is a show-stopper
>> for me in that language ("we're to kewL for an `end'
>> keyword"?).
>
>
> Knocking Python for the whitespace thing is the equivalent of parroting
> the "Lots of Irritating Silly Parentheses" joke. It means you aren't
> looking in far enough to see the bits that actually cause pain.
>
> The absence of mutable strings (ow, the consing!); 1/2 == 0; the macro-
> phobia; the lack of a working lambda; the lack of continuable errors;
> the global interpreter lock ....
>
Or the absence of a construct like "new" to differentiate between
creating a new variable or changing the value of a variable. If you make
a typo this could lead to well hidden bugs.
Andr�
--
Matthias Buelow <···@incubus.de> wrote:
> SILLY: It derides Lisp's syntax (need for QUOTE) and totally ignores
> the imho totally moronic way of deriving block structure from
> whitespace indentation in Python. That alone is a show-stopper
> for me in that language ("we're to kewL for an `end'
> keyword"?).
That page is completely silly and most of the times wrong.
But your comment about whitespace indentation is of the same breed. It's
like saying that parenthesis is a show-stopper for Lisp. Pretty silly,
after 20 minutes you don't notice that anymore since Emacs takes care of
everything.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
>But your comment about whitespace indentation is of the same breed. It's
>like saying that parenthesis is a show-stopper for Lisp. Pretty silly,
>after 20 minutes you don't notice that anymore since Emacs takes care of
>everything.
So you don't care if the code is messed up because someone is using a
different editor? Or a code snippet is pasted into a mail message and
gets "massaged" a bit by the mailer?
But apart from these practical considerations, I simply find it
horribly inelegant and a breach with common programming language
design. A program is a stream of characters, not a 2-dimensional
construct of some sort.
Especially when it could have been avoided with a simple `end' keyword.
mkb.
Matthias Buelow <···@incubus.de> wrote:
> So you don't care if the code is messed up because someone is using a
> different editor? Or a code snippet is pasted into a mail message and
Never happened in 7 years of python development. And the Emacs'
python-mode can adapt itself to the most used indentation type in the
current source file.
> gets "massaged" a bit by the mailer?
usually mailers don't scramble your mail. At least the mailers I use
(and that people who mail me use).
> But apart from these practical considerations, I simply find it
> horribly inelegant and a breach with common programming language
> design. A program is a stream of characters, not a 2-dimensional
> construct of some sort.
This is just your personal consideration. Some people may agree with you
and somebody else might not. Surely enough you are giving credit to
those people that complain about Lisp's parenthesis.
Doing some things in a different way than the others might be a win, and
this is exactly the case. Python great readability is largely gained
thanks to meaningful indentation.
> Especially when it could have been avoided with a simple `end' keyword.
Python proved, in over 14 years of life, that a language can grow
powerful and with many fantastic libraries and frameworks even without
an end keyword. After all nobody is forcing you to python, just don't
start with the same FUD that Lispers hate when it is about their
language.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
>This is just your personal consideration. Some people may agree with you
>and somebody else might not. Surely enough you are giving credit to
>those people that complain about Lisp's parenthesis.
IMHO that's on a different level. One might set Lisp's
prefix-notation (and parens) against a different language's infix and
begin+end. Ah well, I don't think you care, anyways.
mkb.
Matthias Buelow <···@incubus.de> wrote:
> IMHO that's on a different level. One might set Lisp's
> prefix-notation (and parens) against a different language's infix and
> begin+end. Ah well, I don't think you care, anyways.
It's not that I don't care. It's just that I like both Lisp's
prefix-notation and Python's indentation based notation :).
They both have strengths and no downsides ;).
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
>It's not that I don't care. It's just that I like both Lisp's
>prefix-notation and Python's indentation based notation :).
>They both have strengths and no downsides ;).
You will regret your words in 500 years, when Imperator Ming will have
banished superfluous whitespace, and Lisp will rule the Universe..
mkb.
Ingvar <······@hexapodia.net> writes:
> At the moment, I'm actually down to a single pet hate with Python,
> from roughly four, this time last year.
What happened to the other three?
Ingvar <······@hexapodia.net> wrote:
> For what it's worth, the remaining pet hate is the incongruence
> between defining a class without (explicit?) superclasses and a
> function without parameters. one takes a parenthese pair, the other
> doesn't (and it's a syntax violation to have them).
Already fixed in python-cvs for Python 2.5. And they will probably add
anonymous blocks too (PEP-340).
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> Ingvar <······@hexapodia.net> wrote:
>
>
>>For what it's worth, the remaining pet hate is the incongruence
>>between defining a class without (explicit?) superclasses and a
>>function without parameters. one takes a parenthese pair, the other
>>doesn't (and it's a syntax violation to have them).
>
>
> Already fixed in python-cvs for Python 2.5. And they will probably add
> anonymous blocks too (PEP-340).
>
Fundamental theorem of Programming Languages evolution:
Given your programming language X:
\limit_{\mathrm{y} \rightarrow \mathrm{today} + \epsilon}{X}(y)
= \mathrm{Common-Lisp}(1994) + \mathrm{"type inference"}
For $y$ being the year and $\epsilon$ strictly greater than 0.
:)
Cheers
--
Marco
Ingvar wrote:
> ····························@gmail.com (Valentino Volonghi aka Dialtone) writes:
>
>
>>Ingvar <······@hexapodia.net> wrote:
>>
>>
>>>For what it's worth, the remaining pet hate is the incongruence
>>>between defining a class without (explicit?) superclasses and a
>>>function without parameters. one takes a parenthese pair, the other
>>>doesn't (and it's a syntax violation to have them).
>>
>>Already fixed in python-cvs for Python 2.5. And they will probably add
>>anonymous blocks too (PEP-340).
>
>
> That is handy, having all the things that bugs me about a language
> fixed...
What about using a language that has had all these things fixed for
(more than) a decade already :)
Cheers
--
Marco
"Karl A. Krueger" <········@example.edu> writes:
>
>SILLY: A high-level language is especially valuable when it can be
> easily extended with high-performance code written in C or C++.
SILLY:
It derides Lisp's syntax (need for QUOTE) and totally ignores
the imho totally moronic way of deriving block structure from
whitespace indentation in Python. That alone is a show-stopper
for me in that language ("we're to kewL for an `end'
keyword"?).
mkb.
I wrote:
[...]
oops.. double one (almost).. this one ended up in drafts somehow.
*scratch*
mkb.
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4pd2j$r4d$1@ulric.tng.de>
Marco Antoniotti schrieb:
>
>
> A.L. wrote:
>
>> On 26 Apr 2005 22:32:32 -0700, "Nikhil Ketkar"
>> <············@gmail.com> wrote:
>>
>>
>>> The rate at which the number of python users has grown and is growing
>>> is phenomenal. What caused this? Lisp has all the power Python has.
>>> Python draws a lot from Lisp but its no way near Lisp. What is the
>>> secret to its great PR ?
>>
>>
>>
>> Probably because Python solves (or helps to solve) some problems
>> that Lisp doesn't...
>
>
> Like what?
I once wrote a program (in Python) that reads a file and counts how
often each byte between 0 and 255 occurs. It then printed the results
like that:
0: 417
1: 120
...
254: 595
255: 326
With this tool I wanted to get an evidence how compressed a file is.
This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
Andr�
--
Andr� Thieme wrote:
>
>
> I once wrote a program (in Python) that reads a file and counts how
> often each byte between 0 and 255 occurs. It then printed the results
> like that:
> 0: 417
> 1: 120
> ...
> 254: 595
> 255: 326
>
> With this tool I wanted to get an evidence how compressed a file is.
> This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
>
Here's my go :
(with-open-file (s "/home/drewc/TIM_BEACHY.txt" :element-type
'unsigned-byte)
(loop for byte = (read-byte s nil)
until (eql byte nil)
with count-plist = (list)
do (setf (getf count-plist byte)
(1+ (or (getf count-plist byte) 0)))
finally (return count-plist)))
it could be 3 'lines' by removing a few '\n's (can you do *that* in
python? :) )...
It also has the advantage of returning a plist of bytes and counts
rather than printing the results, which means i could then perform
further analysis.
A LOOP guru could probably do it better, but i thought i'd give it a
go... i love loop :)
drewc
~
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc <·····@rift.com> writes:
> Andr� Thieme wrote:
>> I once wrote a program (in Python) that reads a file and counts how
>> often each byte between 0 and 255 occurs. It then printed the
>> results like that:
>> 0: 417
>> 1: 120
>> ...
>> 254: 595
>> 255: 326
>> With this tool I wanted to get an evidence how compressed a file
>> is. This "program" was a 3-liner. How can I do it in max. 3 lines in
>> Lisp?
>>
>
> Here's my go :
>
> (with-open-file (s "/home/drewc/TIM_BEACHY.txt" :element-type
> unsigned-byte)
> (loop for byte = (read-byte s nil)
> until (eql byte nil)
> with count-plist = (list)
> do (setf (getf count-plist byte)
> (1+ (or (getf count-plist byte) 0)))
> finally (return count-plist)))
I need only two lines:
(format t "~:{~3D: ~4D~%~}" (mapcar (lambda (c) (list (car c) (cdr c)))
(make-histogram (coerce (BINARY-FILE-CONTENTS "tmp/misc/wang.accented") 'list))))
Of course, I used some library functions, all previously written, loaded with:
(use-package :com.informatimago.common-lisp.package)
(load-package :com.informatimago.common-lisp.list)
(use-package :com.informatimago.common-lisp.list)
(load-package :com.informatimago.common-lisp.file)
(use-package :com.informatimago.common-lisp.file)
(load "~/src/lisp/encours/word-count.lisp")
But I bet in Python too you have to load libraries to do it, no?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rdep$ipl$2@ulric.tng.de>
Pascal Bourguignon schrieb:
> drewc <·····@rift.com> writes:
>
>
>>Andr� Thieme wrote:
>>
>>>I once wrote a program (in Python) that reads a file and counts how
>>>often each byte between 0 and 255 occurs. It then printed the
>>>results like that:
>>>0: 417
>>>1: 120
>>>...
>>>254: 595
>>>255: 326
>>>With this tool I wanted to get an evidence how compressed a file
>>>is. This "program" was a 3-liner. How can I do it in max. 3 lines in
>>>Lisp?
>>>
>>
>>Here's my go :
>>
>>(with-open-file (s "/home/drewc/TIM_BEACHY.txt" :element-type
>>unsigned-byte)
>> (loop for byte = (read-byte s nil)
>> until (eql byte nil)
>> with count-plist = (list)
>> do (setf (getf count-plist byte)
>> (1+ (or (getf count-plist byte) 0)))
>> finally (return count-plist)))
>
>
>
> I need only two lines:
>
> (format t "~:{~3D: ~4D~%~}" (mapcar (lambda (c) (list (car c) (cdr c)))
> (make-histogram (coerce (BINARY-FILE-CONTENTS "tmp/misc/wang.accented") 'list))))
>
> Of course, I used some library functions, all previously written, loaded with:
>
> (use-package :com.informatimago.common-lisp.package)
> (load-package :com.informatimago.common-lisp.list)
> (use-package :com.informatimago.common-lisp.list)
> (load-package :com.informatimago.common-lisp.file)
> (use-package :com.informatimago.common-lisp.file)
> (load "~/src/lisp/encours/word-count.lisp")
>
> But I bet in Python too you have to load libraries to do it, no?
Nope, you don't need to load libraries. See Gareths code for that.
One could add
from sys import argv
counts = [0]*256
for char in open(argv[1]).read(): counts[ord(char)] += 1
for i in range(256): print i, counts[i]
This way you can start it from the command line with any file
python analyser.py /home/user/file.zip
Andr�
--
From: Karl A. Krueger
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rkmd$cu3$1@baldur.whoi.edu>
Andr? Thieme <······························@justmail.de> wrote:
> counts = [0]*256
> for char in open(argv[1]).read(): counts[ord(char)] += 1
> for i in range(256): print i, counts[i]
I modified the specification a little so we aren't timing printing:
def bytecount(f):
counts = [0] * 256
for char in open(f).read():
counts[ord(char)] += 1
return counts
Here's my Lisp version:
(defun byte-count-iter (filename)
(let ((counts (make-array 256 :element-type 'integer :initial-element 0)))
(with-open-file (file filename :element-type 'unsigned-byte)
(iterate (for byte = (read-byte file nil nil))
(until (eq byte nil))
(incf (aref counts byte))
(finally (return counts))))))
Let's have a race!
On my system, in Python 2.3, the Python function above can count all the
bytes in a compiled Linux 2.6.9 kernel in ... 0.770 seconds.
On my system, in SBCL 0.8.14, the Lisp function above can count the same
file in ... hey! 0.795 seconds.
So Python is exactly 0.025 seconds faster than SBCL. :)
But, you say, this isn't a fair race. Python, as we all know, is a
BYTEcode-compiled language. SBCL compiles to NATIVE code. Since the
job at hand is to count bytes rather than to count natives, it is only
fair fo compare Python to another BYTEcode-compiled language.
So ... let's load up GNU CLISP. To give it a fair shot, let's turn on
some optimizations:
(proclaim '(optimize (speed 3) (safety 1) (debug 0) (compilation-speed 0)))
And to make sure it compiles our BYTE-counting function to nice fast
BYTE-code, let's:
(compile 'byte-count-iter)
And this time, we can read the same file in ... wow! 0.463055 seconds.
And CLISP, unlike SBCL, uses hardly any memory: 5928 bytes, compared to
SBCL's 112,140,288 bytes.
And to *jump( to a conclusion: CLISP is almost twice as fast as SBCL or
Python, and uses a teeny tiny fraction of the memory that SBCL does.
Your mileage may vary. :)
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rmi2$r7a$1@ulric.tng.de>
Karl A. Krueger schrieb:
> Andr? Thieme <······························@justmail.de> wrote:
>
>>counts = [0]*256
>>for char in open(argv[1]).read(): counts[ord(char)] += 1
>>for i in range(256): print i, counts[i]
>
>
> I modified the specification a little so we aren't timing printing:
>
> def bytecount(f):
> counts = [0] * 256
> for char in open(f).read():
> counts[ord(char)] += 1
> return counts
>
> Here's my Lisp version:
>
> (defun byte-count-iter (filename)
> (let ((counts (make-array 256 :element-type 'integer :initial-element 0)))
> (with-open-file (file filename :element-type 'unsigned-byte)
> (iterate (for byte = (read-byte file nil nil))
> (until (eq byte nil))
> (incf (aref counts byte))
> (finally (return counts))))))
>
> Let's have a race!
I don't know what "iterate" is doing, but please try Rob Warnocks
version too:
(defun counter1 (filename)
(with-open-file (s filename :element-type '(unsigned-byte 8))
(let ((counts (make-array 256 :initial-element 0)))
(loop for b = (read-byte s nil) while b do (incf (aref counts b))))))
I think it could be even faster... and perhaps you could also try to add
some declarations to it as it might help to improve speed even more.
> And this time, we can read the same file in ... wow! 0.463055 seconds.
>
> And CLISP, unlike SBCL, uses hardly any memory: 5928 bytes, compared to
> SBCL's 112,140,288 bytes.
>
> And to *jump( to a conclusion: CLISP is almost twice as fast as SBCL or
> Python, and uses a teeny tiny fraction of the memory that SBCL does.
This shows that one should never underestimate CLISP. I did this too often.
Andr�
--
From: Karl A. Krueger
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rt5f$ff9$1@baldur.whoi.edu>
Andr? Thieme <······························@justmail.de> wrote:
> Karl A. Krueger schrieb:
>> Let's have a race!
>
> I don't know what "iterate" is doing, but please try Rob Warnocks
> version too:
ITERATE is being spiffier than LOOP, that's what it's doing. :)
> (defun counter1 (filename)
> (with-open-file (s filename :element-type '(unsigned-byte 8))
> (let ((counts (make-array 256 :initial-element 0)))
> (loop for b = (read-byte s nil) while b do (incf (aref counts b))))))
Within delta of the ITERATE version on both CLISP and SBCL. (There's
more difference between two runs of the same version than there is
between the two versions.) My guess is these compile to very, very
similar code.
(I had another version that used IGNORE-ERRORS and primitive LOOP ...
it just fell off the end of the file. It was slower. So was the
version that used an ITERATE extension macro.)
> I think it could be even faster... and perhaps you could also try to add
> some declarations to it as it might help to improve speed even more.
I tried adding declarations to mine -- it didn't help. I think both
systems can figure out that everything READ-BYTE returns is a byte.
>> And CLISP, unlike SBCL, uses hardly any memory: 5928 bytes, compared to
>> SBCL's 112,140,288 bytes.
>
> This shows that one should never underestimate CLISP. I did this too often.
Yup. What does it take to make CLISP cons unnecessarily? :)
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Karl A. Krueger <········@example.edu> wrote:
> Let's have a race!
Try with this python version:
def main(f):
counts = dict([(chr(x), 0) for x in xrange(256)])
for ch in open(f).read():
counts[ch] += 1
return counts
This should be faster (at least on my ibook it is) because avoids tons
of calls to ord() and prefers just 255 calls to chr().
On my machine, on a 660K zipfile the first version takes:
0.65s
while my new version takes:
0.51s
(both using Python 2.4.1 which is a bit faster than Python 2.3)
> Your mileage may vary. :)
ehe.. benchmarks ;)
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
From: Karl A. Krueger
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4sfu7$lur$1@baldur.whoi.edu>
Valentino Volonghi aka Dialtone <························@gmail.com> wrote:
> Karl A. Krueger <········@example.edu> wrote:
>> Let's have a race!
>
> Try with this python version:
>
> def main(f):
> counts = dict([(chr(x), 0) for x in xrange(256)])
> for ch in open(f).read():
> counts[ch] += 1
> return counts
Yes, it's faster (0.65 sec on the same Linux kernel) but doesn't do the
same job -- it returns an unordered mapping from byte to count, not an
ordered collection of byte, count pairs. The ordered case can be done
as quickly, though, by avoiding xrange:
rng = range(256)
def rangybytes(f):
counts = dict([(chr(x), 0) for x in rng])
for ch in open(f).read():
counts[ch] += 1
return [counts[chr(x)] for x in rng]
Still doesn't beat CLISP, by the way: 0.65 seconds to process a Linux
kernel on my box vs. CLISP's 0.46 seconds. Going from Python 2.3 (what
I used before) to Python 2.4 takes it down to 0.57 seconds on the same
data set and machine.
Ah, but elsewhere in the thread Paul Foley has posted this:
(defun main (pathname)
(with-open-file (stream pathname)
(let ((counts (make-array 256 :initial-element 0))
(string (make-string (file-length stream))))
(dotimes (i (read-sequence string stream) counts)
(incf (aref counts (char-code (char string i))))))))
... which doesn't run at all for me in CLISP, but crunches that kernel
in in 0.2 seconds in SBCL.
Past that is just code bumming. :)
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Karl A. Krueger <········@example.edu> wrote:
> Yes, it's faster (0.65 sec on the same Linux kernel) but doesn't do the
> same job -- it returns an unordered mapping from byte to count, not an
> ordered collection of byte, count pairs. The ordered case can be done
> as quickly, though, by avoiding xrange:
I think this would be better to print the ordered list
for char in sorted(counts.keys()):
print char, counts.get(char)
> rng = range(256)
> def rangybytes(f):
> counts = dict([(chr(x), 0) for x in rng])
> for ch in open(f).read():
> counts[ch] += 1
> return [counts[chr(x)] for x in rng]
> ... which doesn't run at all for me in CLISP, but crunches that kernel
> in in 0.2 seconds in SBCL.
>
> Past that is just code bumming. :)
Ehe :). I think that they are both fast enough.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rdao$ipl$1@ulric.tng.de>
drewc schrieb:
> Andr� Thieme wrote:
>
>>
>>
>> I once wrote a program (in Python) that reads a file and counts how
>> often each byte between 0 and 255 occurs. It then printed the results
>> like that:
>> 0: 417
>> 1: 120
>> ...
>> 254: 595
>> 255: 326
>>
>> With this tool I wanted to get an evidence how compressed a file is.
>> This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
>>
>
> Here's my go :
>
> (with-open-file (s "/home/drewc/TIM_BEACHY.txt" :element-type
> 'unsigned-byte)
> (loop for byte = (read-byte s nil)
> until (eql byte nil)
> with count-plist = (list)
> do (setf (getf count-plist byte)
> (1+ (or (getf count-plist byte) 0)))
> finally (return count-plist)))
>
> it could be 3 'lines' by removing a few '\n's (can you do *that* in
> python? :) )...
>
> It also has the advantage of returning a plist of bytes and counts
> rather than printing the results, which means i could then perform
> further analysis.
>
> A LOOP guru could probably do it better, but i thought i'd give it a
> go... i love loop :)
Loop is nice, but the python version runs faster than your code when I
compiled it with cmucl.
Andr�
--
Andr� Thieme wrote:
> drewc schrieb:
>
>> Andr� Thieme wrote:
>>
>>>
>>>
>>> I once wrote a program (in Python) that reads a file and counts how
>>> often each byte between 0 and 255 occurs. It then printed the results
>>> like that:
>>> 0: 417
>>> 1: 120
>>> ...
>>> 254: 595
>>> 255: 326
>>>
>>> With this tool I wanted to get an evidence how compressed a file is.
>>> This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
>>>
>>
>> Here's my go :
>>
>> (with-open-file (s "/home/drewc/TIM_BEACHY.txt" :element-type
>> 'unsigned-byte)
>> (loop for byte = (read-byte s nil)
>> until (eql byte nil)
>> with count-plist = (list)
>> do (setf (getf count-plist byte)
>> (1+ (or (getf count-plist byte) 0)))
>> finally (return count-plist)))
>>
>> it could be 3 'lines' by removing a few '\n's (can you do *that* in
>> python? :) )...
>>
>> It also has the advantage of returning a plist of bytes and counts
>> rather than printing the results, which means i could then perform
>> further analysis.
>>
>> A LOOP guru could probably do it better, but i thought i'd give it a
>> go... i love loop :)
>
>
> Loop is nice, but the python version runs faster than your code when I
> compiled it with cmucl.
That is because in Python you are reading the file all at once. The CL
version does a READ-BYTE on the stream. You need a READ-SEQUENCE based
loop to do exactly what the Python code does.
Cheers
--
Marco
Andr� Thieme <······························@justmail.de> writes:
>Loop is nice, but the python version runs faster than your code when I
>compiled it with cmucl.
That's probably because his snippet is using O(n) property lists,
instead of an O(1) array, actually he traverses the list twice, even.
Just a suboptimal choice of algorithm.
mkb.
[And I do not agree with the "loop is nice", just for the records.]
Andr� Thieme wrote:
> I once wrote a program (in Python) that reads a file and counts how
> often each byte between 0 and 255 occurs. It then printed the results
> like that:
> 0: 417
> 1: 120
> ...
> 254: 595
> 255: 326
>
> With this tool I wanted to get an evidence how compressed a file is.
> This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
The following 1-liner Lisp program does it (from a file named "foo").
The algorithm is basically the same straightforward one you would use in
any language with iterative looping constructs and mutable arrays. For
your reading convenience (and to fulfill Usenet conventions), I have
split the 1-liner into several lines, syntactically indented. Of
course, this would not be possible with every Python program, which
depend on indenting for block structuring.
(with-open-file (f "foo"
:direction :input
:element-type 'unsigned-byte)
(let ((a (make-array '(256) :initial-element 0)))
(do ((b (read-byte f nil -1)
(read-byte f nil -1)))
((minusp b))
(incf (aref a b)))
(do ((i 0 (1+ i)))
((= i 256))
(when (plusp (aref a i))
(format t "~A: ~A~%" i (aref a i))))))
mkb.
I wrote:
> The following 1-liner Lisp program does it (from a file named "foo").
> (with-open-file (f "foo"
...
Of course I'm intentionally misinterpreting your constraints here.
You're possibly right that such simple tasks can be done faster in a
scripting language like Python (or also Perl), which have been optimized
for such tasks. At least, there are quite a lot of examples that can be
found for {Perl, Python, sh/awk, ...} which require more code in Lisp,
C, Java, Pascal, than in that particular language.
The point is, this particular Lisp program doesn't look much different
than how one would do it in C, Java, Pascal, or any of the "ordinary"
programming languages. So, even if you do not exploit the
particularities of Lisp, you can often transcribe any algorithm
straightly from these programming languages.
mkb.
Matthias Buelow <···@incubus.de> wrote:
> Of course I'm intentionally misinterpreting your constraints here.
> You're possibly right that such simple tasks can be done faster in a
> scripting language like Python (or also Perl), which have been optimized
> for such tasks.
but you can tweak Lisp to be optimized for such tasks. For example if you
add:
(defmacro file-byte-iterate (file byte &body body)
(let ((s (gensym)))
`(with-open-file (,s ,file :element-type 'unsigned-byte)
(loop for ,byte = (read-byte ,s nil)
until (eql ,byte nil)
do ,@body))))
(defun print-vector (vector)
(loop for count across vector
for i = 0 then (1+ i) do
(format t "~a: ~a~%" i count)))
then the code is three lines:
(let ((counts (make-array 256 :initial-element 0)))
(file-byte-iterate "my-file" byte (incf (aref counts byte)))
(print-vector counts)))
@Andr� Thieme: how does it look like in Python? Could be useful to
implement some Python constructs in Lisp, too.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> @Andr� Thieme: how does it look like in Python? Could be useful to
> implement some Python constructs in Lisp, too.
counts = [0]*256
for char in open("foo.dat").read(): counts[ord(char)] += 1
for i in range(256): print i, counts[i]
This has the drawback of reading the entire file into
memory, but these days a file has to be pretty big
before that's a real problem.
In CL this would be
(let ((counts (make-array 256 :initial-element 0)))
(with-open-file (f "foo.dat")
(loop for byte = (read-char f nil) while byte do (incf (aref counts (char-code byte)))))
(loop for i from 0 below 256 do (format t "~&~A ~A~%" i (aref counts i))))
Things Python does more concisely:
- constructing an array o' zeros
- reading every byte of a file ("every line" is easier, too)
- really simple output
If you need to do a lot of this sort of thing in CL,
you can say
(defun vector-of (n value) (make-array n :initial-element value))
(defmacro for-each-stream-char ((char-var stream) &body body)
(let ((stream-var (gensym)))
`(let ((,stream-var ,stream))
(loop for ,char-var = (read-char ,stream-var nil) while ,char-var do . ,body))))
(defmacro for-each-file-char ((char-var name) &body body)
(let ((stream-var (gensym)))
`(with-open-file (,stream-var ,name)
(for-each-stream-char (,char-var ,stream-var)
. ,body))))
(defun print-line (&rest objects)
(format "~{~^ ~}" objects))
and then
(let ((counts (vector-of 256 0)))
(for-each-file-char (c "foo.dat") (incf (aref counts (char-code char))))
(loop for i below 256 do (print-line i (aref counts i))))
The Python code is still shorter, but Lisp was never designed
for source-code-size optimization at this scale.
--
Gareth McCaughan
.sig under construc
From: Edi Weitz
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <upswfoyxq.fsf@agharta.de>
On Thu, 28 Apr 2005 10:31:46 GMT, Gareth McCaughan <················@pobox.com> wrote:
> counts = [0]*256
> for char in open("foo.dat").read(): counts[ord(char)] += 1
> for i in range(256): print i, counts[i]
Does this code snippet also have the semantics of Lisp's
WITH-OPEN-FILE in that it'll make sure the file is closed afterwards
no matter what happens? If it doesn't then I think that the one
additional line you need in Lisp is a very good investment... :)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Gareth McCaughan <················@pobox.com> wrote:
> The Python code is still shorter, but Lisp was never designed
> for source-code-size optimization at this scale.
In J you can write it like this:
+/f=(($(f=:a.i.1!:1<'yourfile.txt')),256)$i.256
but it is bad J, because I don't know it enough for better code and it
returns only the 256 counts, not the index, because I don't know how to
format in J.
It works like this: First it reads the file to a string, converts it to
integer bytes, creates file-length * 256 arrays with the values from 0 to
255 and for the n-th byte b it sets the b-th value in the n-th array to 1
and all others to 0 and finally sums all arrays to one 256 element long
array, which is the result.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> Gareth McCaughan <················@pobox.com> wrote:
>
>> The Python code is still shorter, but Lisp was never designed
>> for source-code-size optimization at this scale.
>
> In J you can write it like this:
>
> +/f=(($(f=:a.i.1!:1<'yourfile.txt')),256)$i.256
> but it is bad J, because I don't know it enough for better code and it
> returns only the 256 counts, not the index, because I don't know how to
> format in J.
How about
(;"0~ ··@#)<:+/"1=(i.256),a.i.1!:1<'yourfile.txt'
?
'as
Alexander Schmolck <··········@gmx.net> wrote:
> How about
>
> (;"0~ ··@#)<:+/"1=(i.256),a.i.1!:1<'yourfile.txt'
that's nice, with boxed output. For all Lispers here I'll try to explain
it, perhaps some ideas can be used in Lisp, too:
1!:1<'yourfile.txt'
returns the contents of the file "yourfile.txt" as a string
a.i.string
converts "string" to a list of ASCII values (0-255). It is interesting
how it works: "a." is a 256 element long vector with the alphabet, for
example the length and element at index 65th:
$a.
256
65{a.
A
The "i." function has two meanings, one for monadic and one for dyadic.
The monadic version takes arguments on the right side, only, and returns
the numbers from 0 below the argument:
i. 10
0 1 2 3 4 5 6 7 8 9
The dyadic function returns the index in the left array of all elements
in the right array:
1 2 3 i. 3
2
1 2 3 4 5 i. 2 3
1 2
The next construct is very tricky. "i.256" simply returns an array from 0
to 255 and the "," prepends it to the read file string. But the "=" is
not used as the normal dyadic function, but as the monadic one, which is
described as "Self-Classify" in the manual. This function first creates
the nub of its argument (which is like "remove-duplicates" for one
dimensional arrays in Lisp) and compares each element with all elements
of the original array, which results in an boolean two dimensional array:
1 2
test =: 1 2 3
~. test
1 2 3
= test
1 0 0
0 1 0
0 0 1
test2 =: 1 2 2 1
~. test2
1 2
= test2
1 0 0 1
0 1 1 0
When you prepend 0..256 to the file and use the monadic "=" on it, you'll
get an array with 256 lines (because the nub of this array has always the
length 256), where each line is an array of the length of the file +256.
A simpler example:
test =: (i.10),(1 2 2 1 7)
test
0 1 2 3 4 5 6 7 8 9 1 2 2 1 7
~.test
0 1 2 3 4 5 6 7 8 9
= test
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 1 0 0 0 0 0 0 0 0 1 0 0 1 0
0 0 1 0 0 0 0 0 0 0 0 1 1 0 0
0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 1 0 0 0 0 0
As you can see, only all rows have to be added to get the number of each
unique element in the original array. Using the +/ would add the columns:
+/ (= test)
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
To add the rows, we need the rank conjunction '"'. To quote the manual:
"The rank conjunction " is used in the phrase f"k to apply a function f
to each of the k-cells of its argument.". With "k-cell" the axes are
meant: 0-cell are the single atoms, 1-cell are one-dimensional vectors
(this are our rows in the example), 2-cells are two-dimensional array for
example in an 3-dimensional array etc. So we need the rank 1:
+/ " 1 (= test)
1 3 3 1 1 1 1 2 1 1
Now we need to know only the rest:
(;"0~ ··@#)<:
Let's try it:
(;"0~ ··@#)<: (4 2 9)
+-+-+
|0|3|
+-+-+
|1|1|
+-+-+
|2|8|
+-+-+
It returns a boxed two-dimensional array with the index in the first
column and 1- each element of the argument in the second column. The 1-
is easy: "<:" is used as the monadic version and decrements all elements
by 1:
<: 10
9
<: 1 2 3
0 1 2
But I don't understand the rest :-)
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> (;"0~ ··@#)<: (4 2 9)
> +-+-+
> |0|3|
> +-+-+
> |1|1|
> +-+-+
> |2|8|
> +-+-+
>
> It returns a boxed two-dimensional array with the index in the first
> column and 1- each element of the argument in the second column. The 1-
> is easy: "<:" is used as the monadic version and decrements all elements
> by 1:
>
> <: 10
> 9
> <: 1 2 3
> 0 1 2
>
> But I don't understand the rest :-)
way OT but I guess most regulars have killed this thread already:
··@# <=> (compose i. array-size)
a ;"0 b <=> (boxed-array)-append individual items ("0) of a and b
~ <=> reverse order of arguments i.e. (lambda (f x y) (funcall f y x))
(f g) x <=> (funcall f x (funcall g x))
'as
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4reqh$ke5$1@ulric.tng.de>
Frank Buss schrieb:
> Matthias Buelow <···@incubus.de> wrote:
>
>
>>Of course I'm intentionally misinterpreting your constraints here.
>>You're possibly right that such simple tasks can be done faster in a
>>scripting language like Python (or also Perl), which have been optimized
>>for such tasks.
>
>
> but you can tweak Lisp to be optimized for such tasks. For example if you
> add:
>
> (defmacro file-byte-iterate (file byte &body body)
> (let ((s (gensym)))
> `(with-open-file (,s ,file :element-type 'unsigned-byte)
> (loop for ,byte = (read-byte ,s nil)
> until (eql ,byte nil)
> do ,@body))))
>
> (defun print-vector (vector)
> (loop for count across vector
> for i = 0 then (1+ i) do
> (format t "~a: ~a~%" i count)))
>
> then the code is three lines:
>
> (let ((counts (make-array 256 :initial-element 0)))
> (file-byte-iterate "my-file" byte (incf (aref counts byte)))
> (print-vector counts)))
>
> @Andr� Thieme: how does it look like in Python? Could be useful to
> implement some Python constructs in Lisp, too.
>
Hi Frank, nice solution, danke.
There are two python versions flying around here: the threeliner of
Gareth which is nearly the same as what I wrote (over one year ago) and
the 1-liner from me that I wrote today, but which is extremly slow as it
traverses the file 256 times.
I don't see much use to implement Python constructs in Lisp. If I want
them I can use Python. For the same reason I don't think that Python
should get macros. I like it as a scripting language and in my opinion
Python should be exactly that. A real good scripting language. If I want
to write applications or really complicated stuff I have Lisp.
Andr�
--
Andr� Thieme <······························@justmail.de> wrote:
> I don't see much use to implement Python constructs in Lisp. If I want
> them I can use Python.
why writing more code than necessary? If you need to read files all the
time, then something like the open/read combination in Python would be
useful:
(defun read-file (name)
(with-open-file (s name :element-type '(unsigned-byte 8))
(loop for b = (read-byte s nil)
with content = (make-array 0
:element-type '(unsigned-byte 8)
:adjustable t
:fill-pointer t)
finally (return content)
while b do (vector-push-extend b content))))
Then you can use this in your programs as easy as in Python.
This is true for the other construct as well, like [..]*x, which can be
implemented in Lisp, too.
A bit more difficult is "range", because unfortunately you can't implement
your own sequence-types in Lisp.
BTW: That's nice in J ( http://www.jsoftware.com ) : There is anything an
array, atoms are treated as arrays with dimension 0 and nearly all
functions can be applied to all arguments (more orthogonal than Lisp). In
Lisp you have to think about if it is a sequence or a list, like in "loop",
where you have to use "in" or "across", depending on the type.
Hm, perhaps J is the best language programming language out there :-)
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rog6$svd$1@ulric.tng.de>
Frank Buss schrieb:
> Andr� Thieme <······························@justmail.de> wrote:
>
>
>>I don't see much use to implement Python constructs in Lisp. If I want
>>them I can use Python.
>
>
> why writing more code than necessary? If you need to read files all the
> time, then something like the open/read combination in Python would be
> useful:
>
> (defun read-file (name)
> (with-open-file (s name :element-type '(unsigned-byte 8))
> (loop for b = (read-byte s nil)
> with content = (make-array 0
> :element-type '(unsigned-byte 8)
> :adjustable t
> :fill-pointer t)
> finally (return content)
> while b do (vector-push-extend b content))))
>
> Then you can use this in your programs as easy as in Python.
>
> This is true for the other construct as well, like [..]*x, which can be
> implemented in Lisp, too.
>
> A bit more difficult is "range", because unfortunately you can't implement
> your own sequence-types in Lisp.
Python:
range(10) => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Lisp:
(loop for i upto 10 collect i) => (0 1 2 3 4 5 6 7 8 9)
Not soo difficult. And what do you mean with "you can't implement your
own sequence-types"?
> BTW: That's nice in J ( http://www.jsoftware.com ) : There is anything an
> array, atoms are treated as arrays with dimension 0 and nearly all
> functions can be applied to all arguments (more orthogonal than Lisp).
What exactly do you mean with that?
> In Lisp you have to think about if it is a sequence or a list, like in "loop",
> where you have to use "in" or "across", depending on the type.
Don't you think that this was done for readability and other practical
reasons? Do you really think it would be impossible to write something
like loop that allows to say
(for x in sequence (body..)) that would work with lists, strings,
arrays, hashtables?
> Hm, perhaps J is the best language programming language out there :-)
Probably it is. But if I only see something like
(;"0~ ··@#)<:+/"1=(i.256),a.i.1!:1<'yourfile.txt'
blood flows out of my eyes.
Andr�
--
Andr� Thieme <······························@justmail.de> wrote:
>> A bit more difficult is "range", because unfortunately you can't
>> implement your own sequence-types in Lisp.
>
> Python:
> range(10) => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
> Lisp:
> (loop for i upto 10 collect i) => (0 1 2 3 4 5 6 7 8 9)
>
> Not soo difficult.
I don't know Python in detail, but I assume the range function returns an
object and doesn't construct an list from 0 below n, because this could
be very inefficient for large n.
> And what do you mean with "you can't implement your
> own sequence-types"?
There are many function in Lisp, which operates on sequences. But I can't
create a Lisp type, which is a sequence, for example a class which
represents a range, and which can be used with these functions.
>> BTW: That's nice in J ( http://www.jsoftware.com ) : There is
>> anything an array, atoms are treated as arrays with dimension 0 and
>> nearly all functions can be applied to all arguments (more orthogonal
>> than Lisp).
>
> What exactly do you mean with that?
just a little example:
J:
0{1
1
0{1 2
1
1{1 2
2
CL:
CL-USER > (elt 1 0)
Error: In a call to ELT: 1 is not of type SEQUENCE.
1 (abort) Return to level 0.
2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other
options
CL-USER : 1 > :a
CL-USER > (elt '(1 2) 0)
1
CL-USER > (elt '(1 2) 1)
2
>> In Lisp you have to think about if it is a sequence or a list, like
>> in "loop", where you have to use "in" or "across", depending on the
>> type.
>
> Don't you think that this was done for readability and other practical
> reasons? Do you really think it would be impossible to write something
> like loop that allows to say
> (for x in sequence (body..)) that would work with lists, strings,
> arrays, hashtables?
yes, this is possible, but would be slower, because it has to check for
the type at runtime. And speed might be the main reason, otherwise you
could use lists all the time.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> wrote:
> I don't know Python in detail, but I assume the range function returns an
> object and doesn't construct an list from 0 below n, because this could
> be very inefficient for large n.
range does that and it's pretty inefficient.
But range was left with this semantics to preserve backwards
compatibility.
There is a new function in Python >= 2.1 (IIRC) that is xrange() which
uses generators and avoids creating a list but allows iteration with a
for loop (or using the iterator protocol).
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Frank Buss wrote:
> Andr� Thieme <······························@justmail.de> wrote:
>
>
>>>A bit more difficult is "range", because unfortunately you can't
>>>implement your own sequence-types in Lisp.
>>
>>Python:
>>range(10) => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>
>>Lisp:
>>(loop for i upto 10 collect i) => (0 1 2 3 4 5 6 7 8 9)
>>
>>Not soo difficult.
>
>
> I don't know Python in detail, but I assume the range function returns an
> object and doesn't construct an list from 0 below n, because this could
> be very inefficient for large n.
>
That is the differenc ebetween `range' and `xrange' in Python.
>>And what do you mean with "you can't implement your
>>own sequence-types"?
>
>
> There are many function in Lisp, which operates on sequences. But I can't
> create a Lisp type, which is a sequence, for example a class which
> represents a range, and which can be used with these functions.
Nobody forbids you to do
(defpackage "MYCL" (:use "CL")
(:shadow "DELETE" "REMOVE" "SEARCH" #|etc etc|#)
(:export #|all of the above|#))
(in-package "MYCL")
(defgeneric remove (item my-sequence &key))
;;; etc etc
>
>
>>>BTW: That's nice in J ( http://www.jsoftware.com ) : There is
>>>anything an array, atoms are treated as arrays with dimension 0 and
>>>nearly all functions can be applied to all arguments (more orthogonal
>>>than Lisp).
>>
>>What exactly do you mean with that?
>
>
> just a little example:
>
> J:
>
> 0{1
> 1
> 0{1 2
> 1
> 1{1 2
> 2
That's because in J (as in APL and - almost - in Matlab) everything
boils down to a matrix of some kind. I am no familiar with J, but I bet
that the dyadic operator '{' essentially works for "vectors". What would
1 1 { 1 2 3 4 5 6 7 8
do?
Cheers
--
Marco
Paul Foley (http://public.xdi.org/=pf) wrote:
> On Fri, 29 Apr 2005 00:20:27 +0000 (UTC), Frank Buss wrote:
>
>
>>Andr� Thieme <······························@justmail.de> wrote:
>>
>>>>A bit more difficult is "range", because unfortunately you can't
>>>>implement your own sequence-types in Lisp.
>>>
>>>Python:
>>>range(10) => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>>
>>>Lisp:
>>>(loop for i upto 10 collect i) => (0 1 2 3 4 5 6 7 8 9)
>>>
>>>Not soo difficult.
>
>
>>I don't know Python in detail, but I assume the range function returns an
>>object and doesn't construct an list from 0 below n, because this could
>>be very inefficient for large n.
>
>
> It does, though. There's also an xrange() that returns something more
> efficient -- the Lisp equivalent would be SERIES:SCAN-RANGE
>
Or ENUM:RANGE (shameless plug: CL-ENUMERATION on common-lisp.net)
Cheers
--
Marco
Frank Buss <··@frank-buss.de> wrote:
+---------------
| Andr� Thieme <······························@justmail.de> wrote:
| > I don't see much use to implement Python constructs in Lisp.
| > If I want them I can use Python.
|
| why writing more code than necessary? If you need to read files all the
| time, then something like the open/read combination in Python would be
| useful:
|
| (defun read-file (name) ... )
+---------------
Heh. I actually have *three* of those in my personal "utils.lisp": ;-}
file-string ; Suck up a whole file into a string.
file-lines ; ...into a list of strings (lines).
file-forms ; ...into a list of forms (s-exprs).
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Frank Buss wrote:
> Andr� Thieme <······························@justmail.de> wrote:
>
>
>>I don't see much use to implement Python constructs in Lisp. If I want
>>them I can use Python.
>
>
> why writing more code than necessary? If you need to read files all the
> time, then something like the open/read combination in Python would be
> useful:
>
> (defun read-file (name)
> (with-open-file (s name :element-type '(unsigned-byte 8))
> (loop for b = (read-byte s nil)
> with content = (make-array 0
> :element-type '(unsigned-byte 8)
> :adjustable t
> :fill-pointer t)
> finally (return content)
> while b do (vector-push-extend b content))))
Except that, as Paul Foley rightly noted.....
(defun read-file (filename &key (element-type '(unsigned-byte 8)))
(with-open-file (fs filename :element-type element-type)
(read-sequence (make-array (file-length fs)
:element-type element-type)
fs))))
>
> Then you can use this in your programs as easy as in Python.
>
> This is true for the other construct as well, like [..]*x, which can be
> implemented in Lisp, too.
>
> A bit more difficult is "range", because unfortunately you can't implement
> your own sequence-types in Lisp.
CL-ENUMERATIONS at common-lisp.net comes handy :) (Shameless plug)
Note that RANGE is simply IOTA
(defun RANGE (start end &optional (step 1))
(loop for i from start below end by step collect i))
> BTW: That's nice in J ( http://www.jsoftware.com ) : There is anything an
> array, atoms are treated as arrays with dimension 0 and nearly all
> functions can be applied to all arguments (more orthogonal than Lisp). In
> Lisp you have to think about if it is a sequence or a list, like in "loop",
> where you have to use "in" or "across", depending on the type.
>
> Hm, perhaps J is the best language programming language out there :-)
>
Wrong. The best is INTERCAL.
Cheers
--
Marco
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rei6$k89$1@ulric.tng.de>
Matthias Buelow schrieb:
> I wrote:
>
>
>>The following 1-liner Lisp program does it (from a file named "foo").
>>(with-open-file (f "foo"
>
> ...
>
> Of course I'm intentionally misinterpreting your constraints here.
> You're possibly right that such simple tasks can be done faster in a
> scripting language like Python (or also Perl), which have been optimized
> for such tasks.
That is my message. I don't remember the creators of Lisp saying they
wanted to optimize it for toy-examples. They mainly created Lisp to do
complicated things, like controlling space-missions, software for
nuclear power plants, AI, etc..
I will soon begin to write a learning application with Lisp that is not
soo trivial anymore that I would use a scripting language.
> At least, there are quite a lot of examples that can be
> found for {Perl, Python, sh/awk, ...} which require more code in Lisp,
> C, Java, Pascal, than in that particular language.
I agree. Scripting languages are usually very good in the domain of -
writing scripts.
> The point is, this particular Lisp program doesn't look much different
> than how one would do it in C, Java, Pascal, or any of the "ordinary"
> programming languages. So, even if you do not exploit the
> particularities of Lisp, you can often transcribe any algorithm
> straightly from these programming languages.
Right, the Lisp solutions are not bad. Noone said it. But lets forget
all this elitism for a moment and just accept that some languages are
working better in their domain as Lisp does. This does not make Lisp
bad. It still is the best programming language out there.
Andr�
--
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rdju$ipl$3@ulric.tng.de>
Matthias Buelow schrieb:
> Andr� Thieme wrote:
>
>
>>I once wrote a program (in Python) that reads a file and counts how
>>often each byte between 0 and 255 occurs. It then printed the results
>>like that:
>>0: 417
>>1: 120
>>...
>>254: 595
>>255: 326
>>
>>With this tool I wanted to get an evidence how compressed a file is.
>>This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
>
>
> The following 1-liner Lisp program does it (from a file named "foo").
>
> The algorithm is basically the same straightforward one you would use in
> any language with iterative looping constructs and mutable arrays. For
> your reading convenience (and to fulfill Usenet conventions), I have
> split the 1-liner into several lines, syntactically indented. Of
> course, this would not be possible with every Python program, which
> depend on indenting for block structuring.
>
> (with-open-file (f "foo"
> :direction :input
> :element-type 'unsigned-byte)
> (let ((a (make-array '(256) :initial-element 0)))
> (do ((b (read-byte f nil -1)
> (read-byte f nil -1)))
> ((minusp b))
> (incf (aref a b)))
> (do ((i 0 (1+ i)))
> ((= i 256))
> (when (plusp (aref a i))
> (format t "~A: ~A~%" i (aref a i))))))
Well, calling this a 1-liner is a bit too generous.
I would say it is something between 7 and 12 lines.
But look at this 1-liner of Python code:
for i in xrange(256): print str(i)+": "+str([ord(x) for x in
open("file.dat").read()].count(i))
(in my newsreader I can see it as one line)
One could break it up into two:
for i in xrange(256):
print str(i)+": "+str([ord(x) for x in open("file.dat").read()].count(i))
Andr�
--
Andr� Thieme <······························@justmail.de> wrote:
+---------------
| I once wrote a program (in Python) that reads a file and counts how
| often each byte between 0 and 255 occurs. It then printed the results
| like that:
| 0: 417
| 1: 120
...
| With this tool I wanted to get an evidence how compressed a file is.
| This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
+---------------
It's quite easy in 4 lines of CL; is that good enough?
(with-open-file (s "file.name" :element-type '(unsigned-byte 8))
(let ((counts (make-array 256 :initial-element 0)))
(loop for b = (read-byte s nil) while b do (incf (aref counts b)))
(loop for b below 256 do (format t "~d: ~d~%" b (aref counts b)))))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rf0m$ke5$2@ulric.tng.de>
Rob Warnock schrieb:
> Andr� Thieme <······························@justmail.de> wrote:
> +---------------
> | I once wrote a program (in Python) that reads a file and counts how
> | often each byte between 0 and 255 occurs. It then printed the results
> | like that:
> | 0: 417
> | 1: 120
> ...
> | With this tool I wanted to get an evidence how compressed a file is.
> | This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
> +---------------
>
> It's quite easy in 4 lines of CL; is that good enough?
>
> (with-open-file (s "file.name" :element-type '(unsigned-byte 8))
> (let ((counts (make-array 256 :initial-element 0)))
> (loop for b = (read-byte s nil) while b do (incf (aref counts b)))
> (loop for b below 256 do (format t "~d: ~d~%" b (aref counts b)))))
I really like this code. Nice thing is: it also runs pretty fast (when
compiled).
Andr�
--
Andr� Thieme wrote:
> Marco Antoniotti schrieb:
>
>>
>>
>> A.L. wrote:
>>
>>> On 26 Apr 2005 22:32:32 -0700, "Nikhil Ketkar"
>>> <············@gmail.com> wrote:
>>>
>>>
>>>> The rate at which the number of python users has grown and is growing
>>>> is phenomenal. What caused this? Lisp has all the power Python has.
>>>> Python draws a lot from Lisp but its no way near Lisp. What is the
>>>> secret to its great PR ?
>>>
>>>
>>>
>>>
>>> Probably because Python solves (or helps to solve) some problems
>>> that Lisp doesn't...
>>
>>
>>
>> Like what?
>
>
> I once wrote a program (in Python) that reads a file and counts how
> often each byte between 0 and 255 occurs. It then printed the results
> like that:
> 0: 417
> 1: 120
> ...
> 254: 595
> 255: 326
>
> With this tool I wanted to get an evidence how compressed a file is.
> This "program" was a 3-liner. How can I do it in max. 3 lines in Lisp?
Yes, I can. And other people have already shown you how to do that.
Cheers
--
Marco
Andr� Thieme <······························@justmail.de> writes:
> With this tool I wanted to get an evidence how compressed a file
> is. This "program" was a 3-liner. How can I do it in max. 3 lines in
> Lisp?
What will it prove if it can't be expressed in 3 lines of lisp?
Why the fixation on this minimal line count? A lisper would
probably write your program as
(producing-histogram
(with-open-file (stream path)
(loop as entry = (read-entry stream)
while entry)))
Is that "cheating"? Isn't it clear enough for you?
Lispers are more interested in _expressiveness_ and _clarity_.
That's what lets you write a million LOC programs which are
still debuggable, understandable, and maintainable. This code
bumming machismo is just plain stupid and detracts from the job
at hand: writing interesting, real world programs.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
"Nikhil Ketkar" <············@gmail.com> wrote:
> The rate at which the number of python users has grown and is growing
> is phenomenal. What caused this? Lisp has all the power Python has.
> Python draws a lot from Lisp but its no way near Lisp. What is the
> secret to its great PR ?
Perhaps another reason is that you have one standard implementation for
Windows and Linux with many useful libraries, like multithreading, socket,
web, ftp, smtp, xml, GUI etc. You can get this for Lisp, too, but you have
to search for it and there are problems, if you want to use it on different
operating systems or different Lisp implementations. With Python you'll get
one standard package of useful libraries and your programs works on Linux
and Windows nearly without problems. And the Lisp syntax looks strange for
newcomers, so you have to master theses two problems first, before you can
be productive in Lisp.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> "Nikhil Ketkar" <············@gmail.com> wrote:
>
>> The rate at which the number of python users has grown and is growing
>> is phenomenal. What caused this? Lisp has all the power Python has.
>> Python draws a lot from Lisp but its no way near Lisp. What is the
>> secret to its great PR ?
>
> Perhaps another reason is that you have one standard implementation for
> Windows and Linux with many useful libraries, like multithreading, socket,
> web, ftp, smtp, xml, GUI etc. You can get this for Lisp, too, but you have
> to search for it and there are problems, if you want to use it on different
> operating systems or different Lisp implementations. With Python you'll get
> one standard package of useful libraries and your programs works on Linux
> and Windows nearly without problems. And the Lisp syntax looks strange for
> newcomers, so you have to master theses two problems first, before you can
> be productive in Lisp.
Ever tried to write robust Python code that uses
subprocesses/pipes that runs on both Windows and Un*xy platforms?
Note also that the Python "standard" libraries frequently
contain multiple implementations of the same idea, with useful
functionality missing from all of these.
--
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
> Ever tried to write robust Python code that uses
> subprocesses/pipes that runs on both Windows and Un*xy platforms?
http://www.python.org/dev/doc/devel/lib/module-subprocess.html
·············@gmail.com" <············@gmail.com> writes:
>> Ever tried to write robust Python code that uses
>> subprocesses/pipes that runs on both Windows and Un*xy platforms?
>
> http://www.python.org/dev/doc/devel/lib/module-subprocess.html
I've looked at this before, and it was nowhere near to
fulfilling my requirements. Part of this is because of problems with
Windows APIs - for example, I cannot do non-blocking reads from a
pipe, or use select on it.
... Or at least, I couldn't with Python 2.3.
--
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
·············@gmail.com" <············@gmail.com> writes:
>> ... Or at least, I couldn't with Python 2.3.
>
> So, the problem has been solved in the course of Python development.
> Good news for any tool.
Note that I haven't tested that this[1] works in Python 2.4. My
guess is that it doesn't.
Footnotes:
[1] select() or non-blocking i/o on pipes under Windows.
--
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
Raymond Wiker <·············@fast.no> wrote:
> I've looked at this before, and it was nowhere near to
> fulfilling my requirements. Part of this is because of problems with
> Windows APIs - for example, I cannot do non-blocking reads from a
> pipe, or use select on it.
>
> ... Or at least, I couldn't with Python 2.3.
Twisted Matrix has been able to do this since (at least) Python 2.2, and
in fact it is select'ing on sockets and spawining new processes to give
them some work to do. All in a portable way.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> Raymond Wiker <·············@fast.no> wrote:
>
>> I've looked at this before, and it was nowhere near to
>> fulfilling my requirements. Part of this is because of problems with
>> Windows APIs - for example, I cannot do non-blocking reads from a
>> pipe, or use select on it.
>>
>> ... Or at least, I couldn't with Python 2.3.
>
> Twisted Matrix has been able to do this since (at least) Python 2.2, and
> in fact it is select'ing on sockets and spawining new processes to give
> them some work to do. All in a portable way.
On Windows, sockets, pipes and file descriptors are very
different with regards to what operations work on them. I was talking
about pipes. It is entirely possible that Twisted Matrix manages to
work around these limitations; I'll have a closer look at it.
Thanks for the pointer!
--
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
Raymond Wiker <·············@fast.no> wrote:
> about pipes. It is entirely possible that Twisted Matrix manages to
> work around these limitations; I'll have a closer look at it.
yup. Twisted abstracts the pywin32 API in the specialized win32reactor.
This enables portability of your application from posix systems to
non-posix systems like windows.
> Thanks for the pointer!
no problem :).
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4pck0$qgm$2@ulric.tng.de>
Ulrich Hobelmann schrieb:
> Raymond Wiker wrote:
>
>> Note also that the Python "standard" libraries frequently
>> contain multiple implementations of the same idea, with useful
>> functionality missing from all of these.
>>
>
> "There's more than one way to do it"...
>
> oh wait, that wasn't Python, was it?
I find this so stupid.. as if there was only one way to solve problems
in Python. I can't believe that people really buy this marketing blabber.
Andr�
PS: I find this "There is only one way to do it" stupid (not you),
because it is not true.
--
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4nst8$hpn$1@ulric.tng.de>
Nikhil Ketkar schrieb:
> The rate at which the number of python users has grown and is growing
> is phenomenal. What caused this? Lisp has all the power Python has.
> Python draws a lot from Lisp but its no way near Lisp. What is the
> secret to its great PR ?
Oh my, why is it so popular to ask why Lisp is not popular? Since a few
weeks this newsgroup constantly gets this same question.
Maybe the posters want to become famous? They recognized that this kind
of question will get them maaany answers?
Anyway, I think most of the answers have some true parts. Typical things
we heared are
a) ai winter
b) under windows there is no freeware Lisp that could compete with one
of the two big commercial Lisps (Lispworks and Allegro), which
themselves "only" offer some trial versions
c) too many parentheses
while f(x, foo(18), bar()) is fine (f x (foo 18) (bar)) isn't ;-)
[btw, xml rockz0rs]
d) emacs is too hard to learn
e) Lisp is only interpreted, too slow, consumes to much memory, can't be
executed as a standalone file
f) the trust into the masses: the idea of Lisp not beeing "good" cause
if it would be good then more people would use it
g) students either never see it or they see it only in the first
semester to solve interesting tasks like "fibonacci", "faculty",
"traversing a tree", etc.. while the interesting stuff is done in Java,
like "programming a raytracer", "dynamic websites", etc.
Recently I read an article about chaos-theory. In it the author
explained that the c-t is not only working on some simple objects but
also in behaviour of humans. It seems as if our will is driven by some
invisible force. The author explained that nearly noone is using a
DVORAK-keyboard (I do btw, see http://www.fingerworks.com/ ) and he sees
that one of the reasons is c-t. In our behaviour some patters developed
that affect the masses. From that perspective I would say that Lisp is
not so popular because /it has to be/ unpopular.
What we are experiencing is some strange effect of physics, a pattern
that automagically adjusts/alligns/assembles itself. In this universe of
chaos (people using Java or C++) we can find a few spots of order
(people using Lisp). Perhaps one day some other strange effect begins
and Lisp becomes one of the most popular languages for a decade or two.
We'll see.
Andr�
--
> Oh my, why is it so popular to ask why Lisp is not popular? Since a
few
> weeks this newsgroup constantly gets this same question.
> Maybe the posters want to become famous? They recognized that this
kind
> of question will get them maaany answers?
Mr.Thieme
I dont particularly enjoy discussing why Lisp is unpopular.
This is because I think it is tragic. I need to convince some
people whome I take orders from about Lisp. I would like advice
form people whome I consider to be a lot more talented and experienced
than I am. Even though they are cynical and think that people post
because
they want to be popular.
Thanks,
Nikhil Ketkar
André Thieme wrote:
> Nikhil Ketkar schrieb:
> > The rate at which the number of python users has grown and is
growing
> > is phenomenal. What caused this? Lisp has all the power Python has.
> > Python draws a lot from Lisp but its no way near Lisp. What is the
> > secret to its great PR ?
>
> Oh my, why is it so popular to ask why Lisp is not popular? Since a
few
> weeks this newsgroup constantly gets this same question.
> Maybe the posters want to become famous? They recognized that this
kind
> of question will get them maaany answers?
>
> Anyway, I think most of the answers have some true parts. Typical
things
> we heared are
>
> a) ai winter
>
> b) under windows there is no freeware Lisp that could compete with
one
> of the two big commercial Lisps (Lispworks and Allegro), which
> themselves "only" offer some trial versions
>
> c) too many parentheses
> while f(x, foo(18), bar()) is fine (f x (foo 18) (bar)) isn't ;-)
> [btw, xml rockz0rs]
>
> d) emacs is too hard to learn
>
> e) Lisp is only interpreted, too slow, consumes to much memory, can't
be
> executed as a standalone file
>
> f) the trust into the masses: the idea of Lisp not beeing "good"
cause
> if it would be good then more people would use it
>
> g) students either never see it or they see it only in the first
> semester to solve interesting tasks like "fibonacci", "faculty",
> "traversing a tree", etc.. while the interesting stuff is done in
Java,
> like "programming a raytracer", "dynamic websites", etc.
>
>
> Recently I read an article about chaos-theory. In it the author
> explained that the c-t is not only working on some simple objects but
> also in behaviour of humans. It seems as if our will is driven by
some
> invisible force. The author explained that nearly noone is using a
> DVORAK-keyboard (I do btw, see http://www.fingerworks.com/ ) and he
sees
> that one of the reasons is c-t. In our behaviour some patters
developed
> that affect the masses. From that perspective I would say that Lisp
is
> not so popular because /it has to be/ unpopular.
> What we are experiencing is some strange effect of physics, a pattern
> that automagically adjusts/alligns/assembles itself. In this universe
of
> chaos (people using Java or C++) we can find a few spots of order
> (people using Lisp). Perhaps one day some other strange effect begins
> and Lisp becomes one of the most popular languages for a decade or
two.
> We'll see.
>
>
> André
> --
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4pcee$qgm$1@ulric.tng.de>
Nikhil Ketkar schrieb:
> Mr.Thieme
> I dont particularly enjoy discussing why Lisp is unpopular.
> This is because I think it is tragic. I need to convince some
> people whome I take orders from about Lisp. I would like advice
> form people whome I consider to be a lot more talented and experienced
> than I am. Even though they are cynical and think that people post
> because they want to be popular.
The thing is, and you will see it too, that every few days someone jumps
in and starts a thread similar to yours. For this person who is new to
comp.lang.lisp it might seem that this issue was never discussed before.
In fact you can surf through the archives of this newsgroup and find
thousands and thousands of postings about this issue. You could read
many days without a break (not eating, sleeping (hey, I don't suggest
that)) - it is so much stuff to read.
Especially in the last two/three weeks there were many of these
Lisp-popular-postings. I think I should start to post on a dayly basis a
link to websites that allow you to search through the archives of this
newsgroup...
Andr�
--
From: Christopher C. Stacy
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <usm1bk7cp.fsf@news.dtpq.com>
Andr� Thieme <······························@justmail.de> writes:
> Especially in the last two/three weeks there were many of these
> Lisp-popular-postings. I think I should start to post on a dayly basis
> a link to websites that allow you to search through the archives of
> this newsgroup...
It's an organized conspiracy of people who are reacting
negatively to the release of Peter Seibel's book.
Probably just s small group, and sock puppets.
Christopher C. Stacy wrote:
> Andr� Thieme <······························@justmail.de> writes:
>
>
>>Especially in the last two/three weeks there were many of these
>>Lisp-popular-postings. I think I should start to post on a dayly basis
>>a link to websites that allow you to search through the archives of
>>this newsgroup...
I wonder if it's really that hard to skim through the 500 newest
articles when subscribing to a newsgroup. Maybe it's those rotten
web-interfaces.
Still, there's nothing wrong with googling first.
>
> It's an organized conspiracy of people who are reacting
> negatively to the release of Peter Seibel's book.
> Probably just s small group, and sock puppets.
Pssst, O'Reilly have their ears everywhere! ;)
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Andr� Thieme <······························@justmail.de> writes:
> Nikhil Ketkar schrieb:
> > The rate at which the number of python users has grown and is growing
> > is phenomenal. What caused this? Lisp has all the power Python has.
> > Python draws a lot from Lisp but its no way near Lisp. What is the
> > secret to its great PR ?
>
> Oh my, why is it so popular to ask why Lisp is not popular?
> Since a few weeks this newsgroup constantly gets this same question.
Does anyone know if the question is answered in some Lisp-FAQ?
(To the OP: The secret to Python's great PR is that it comes with
documented, tested libraries that just work most of the time. Second
secret is that you can learn most of the language pretty much in an
afternoon.)
"Nikhil Ketkar" <············@gmail.com> writes:
> I just wrote some code generates relational learning datasets controled
> by 10 parameters for comparing relational learners. Thats fancy
> according to me. I send this code out to some people in the lab. and
> the 'why lisp?' song begins. My only solace is discussing it with
> people here and trying to figure out if I am wrong or they are.
Challenge them to do it better in Python or whatever.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
On 27 Apr 2005 06:59:19 -0700, "Nikhil Ketkar"
<············@gmail.com> wrote:
>No. I am not spreading Python PR. I dont just get how a 'glue' language
>can become so popular.
Well, here's a theory: Most programmers in industry write a lot of
'glue', with small amounts of business logic in between. Something
like Python serves that need while having a similar enough syntax for
average programmers to rapidly become comfortable with it.
The fact that Python comes with a large and effective library also
helps. Too many things that current programmers want are non-standard
in Lisp. Sure, they exist, but tracking down the right version that
will work on your platform with your version of Lisp adds to the
initial hassle -- just enough to encourage an alternate solution. This
is an area where Java succeeds.
I think dynamic languages are making a comeback, and it may help lisp
(I hope so, at any rate), but Lisp does not excel and small, quick
wins for inexperienced programmers. Nor is it (as yet) the perceived
favorite of "hackers". So it gets ignored.
--
adamnospamaustin.rr.com
s/nospam/c\./
Adam Connor <···@nospam.com> writes:
> On 27 Apr 2005 06:59:19 -0700, "Nikhil Ketkar"
> <············@gmail.com> wrote:
>
>>No. I am not spreading Python PR. I dont just get how a 'glue' language
>>can become so popular.
> Well, here's a theory: Most programmers in industry write a lot of
> 'glue', with small amounts of business logic in between. Something
> like Python serves that need while having a similar enough syntax for
> average programmers to rapidly become comfortable with it.
>
> The fact that Python comes with a large and effective library also
> helps. Too many things that current programmers want are non-standard
> in Lisp. Sure, they exist, but tracking down the right version that
> will work on your platform with your version of Lisp adds to the
> initial hassle -- just enough to encourage an alternate solution. This
> is an area where Java succeeds.
>
Thats interesting. I think I agree and to some extent can see how
Python has grown so quickly and the number of ex-perl programmers I've
seen who have switched to python. I agree that a lot of what people
are 'programming' these days is glue. I use to do this with Perl and I
have to say that while you could nearly always find a perl
package/module to help you out with some problem, one of the
frustrations I use to run into was selecting the correct module from
the many available via CPAN and the fact that often a new version
would come out which broke what you were using it for. If Python has
got a more 'standardised' approach and a large API base like Java,
then a lot of people would be attracted to it. I believe that the
large number of defined APIs put out by Sun for Java is one of the
reasons Java has grown to be so popular.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
On Wed, 27 Apr 2005 10:22:42 -0400, Jonathan Bartlett
<·······@eskimo.com> wrote:
>Nikhil Ketkar wrote:
>> The rate at which the number of python users has grown and is growing
>> is phenomenal. What caused this? Lisp has all the power Python has.
>> Python draws a lot from Lisp but its no way near Lisp. What is the
>> secret to its great PR ?
>
>I think most of it is community-related:
>
>1) Popular presses publishing books
>2) python.org website containing pretty much everything you need for
>every platform
>3) Better-documented methods of doing common network-oriented things
>4) Many more tutorials in many more places
5) Possibility to write program that is readable by average human
and doesn't look like garbage produced by random character
generator.
A.L.
A.L. wrote:
> On Wed, 27 Apr 2005 10:22:42 -0400, Jonathan Bartlett
> <·······@eskimo.com> wrote:
>
>
>>Nikhil Ketkar wrote:
>>
>>>The rate at which the number of python users has grown and is growing
>>>is phenomenal. What caused this? Lisp has all the power Python has.
>>>Python draws a lot from Lisp but its no way near Lisp. What is the
>>>secret to its great PR ?
>>
>>I think most of it is community-related:
>>
>>1) Popular presses publishing books
>>2) python.org website containing pretty much everything you need for
>>every platform
>>3) Better-documented methods of doing common network-oriented things
>>4) Many more tutorials in many more places
>
>
> 5) Possibility to write program that is readable by average human
> and doesn't look like garbage produced by random character
> generator.
They were talking about Lisp vs Python, not *Perl* vs Python.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Jonathan Bartlett <·······@eskimo.com> writes:
> Nikhil Ketkar wrote:
>> The rate at which the number of python users has grown and is growing
>> is phenomenal. What caused this? Lisp has all the power Python has.
>> Python draws a lot from Lisp but its no way near Lisp. What is the
>> secret to its great PR ?
>
> I think most of it is community-related:
>
> 1) Popular presses publishing books
> 2) python.org website containing pretty much everything you need for
> every platform
> 3) Better-documented methods of doing common network-oriented things
> 4) Many more tutorials in many more places
>
> Is there anyplace which has documentation for how to do (a)
> networking, (b) CGI, (c) database access (using a db-independent API),
> (d) string manipulation, (e) GUI Programming in Common Lisp? And
> then, does it work on Linux and Windows? There may be (and please
> post if you know one), but it's certainly not nearly as well-known as
> python.org, php.net, or cpan.org.
http://www.cliki.net
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4pdr6$rp3$1@ulric.tng.de>
Wade Humeniuk schrieb:
> If want an example of an even funnier app try my Time Is Money
> Clock. (Windows, but probably portable to Linux and the Mac)
>
> Source and Executable @
>
> http://www3.telus.net/public/whumeniu/time-is-money.zip
Hey, cool idea! Thanks ;-)
Andr�
--
From: Markus Grueneis
Subject: Lisp is becoming mainstream language (and python does not grow) [Was: Why is Lisp not as popular as Python?]
Date:
Message-ID: <3dcn0rF6qks6mU1@individual.net>
Nikhil Ketkar wrote:
> The rate at which the number of python users has grown and is growing
> is phenomenal. What caused this? Lisp has all the power Python has.
> Python draws a lot from Lisp but its no way near Lisp. What is the
> secret to its great PR ?
> [...]
>
Though I cannot answer any questions, at least your statement about the
growing of the Python-userbase seems to be questionable:
<http://www.tiobe.com/tiobe_index/index.htm>
A (also questionable!) statistic, which mentions Lisp as A-- (mainstream
language for the 1st month), btw :)
The next question would be, why the hell Fortran is getting so much
attention?
best regards
Markus
From: Karl A. Krueger
Subject: Re: Lisp is becoming mainstream language (and python does not grow) [Was: Why is Lisp not as popular as Python?]
Date:
Message-ID: <d4rdm3$ahl$1@baldur.whoi.edu>
Markus Grueneis <··········@gmx.net> wrote:
> The next question would be, why the hell Fortran is getting so much
> attention?
Fortran is to scientific programming what I'm told COBOL is to business
programming, only more so. There is not only a lot of existing Fortran
code still being used in science, but plenty of new Fortran code is
still being written.
High-performance Fortran compilers are still being marketed for new
architectures (such as AMD64) and there is substantial interest in them.
So one source of increased attention to Fortran right now would likely
be porting of software to AMD64.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
From: =?UTF-8?B?SmVucyBBeGVsIFPDuGdhYXJk?=
Subject: Re: Lisp is becoming mainstream language (and python does not grow) [Was: Why is Lisp not as popular as Python?]
Date:
Message-ID: <42712ea7$0$204$edfadb0f@dread12.news.tele.dk>
> Though I cannot answer any questions, at least your statement about the
> growing of the Python-userbase seems to be questionable:
>
> <http://www.tiobe.com/tiobe_index/index.htm>
>
> A (also questionable!) statistic, which mentions Lisp as A-- (mainstream
> language for the 1st month), btw :)
They count the number of occurences of the phrase "<language> programming"
in various search engines including Google groups. A few blogs and some
usenet postings mentioning lisp programming and scheme programming ought to
affect the results. E.g. searching for "Fortran ..." on Google and Google
Groups turns up only 48.900 and 4390 results respectively. For "lisp
programming" the results are 64.000 and 3.180.
--
Jens Axel Søgaard
From: Stefan Scholl
Subject: Re: Lisp is becoming mainstream language (and python does not grow) [Was: Why is Lisp not as popular as Python?]
Date:
Message-ID: <12lpk4xqlqv6w$.dlg@parsec.no-spoon.de>
On 2005-04-28 20:06:18, Markus Grueneis wrote:
> The next question would be, why the hell Fortran is getting so much
> attention?
GCC 4.0 and talk about fortress.
From: Geoffrey Summerhayes
Subject: Re: Lisp is becoming mainstream language (and python does not grow) [Was: Why is Lisp not as popular as Python?]
Date:
Message-ID: <_%uce.13978$gA5.793782@news20.bellglobal.com>
"Markus Grueneis" <··········@gmx.net> wrote in message
····················@individual.net...
>
> The next question would be, why the hell Fortran is getting so much
> attention?
>
All the 'Real Programmers' are retiring and leaving tons of spaghetti
behind?
--
Geoff
From: Lars Rune Nøstdal
Subject: Re: Lisp is becoming mainstream language (and python does not grow) [Was: Why is Lisp not as popular as Python?]
Date:
Message-ID: <pan.2005.04.30.10.56.25.190262@gmail.com>
On Fri, 29 Apr 2005 14:26:57 -0400, Geoffrey Summerhayes wrote:
>
> "Markus Grueneis" <··········@gmx.net> wrote in message
> ····················@individual.net...
>>
>> The next question would be, why the hell Fortran is getting so much
>> attention?
>>
>
> All the 'Real Programmers' are retiring and leaving tons of spaghetti
> behind?
This is also known as the "Spaghetti Incident?"
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
From: Stefan Scholl
Subject: Re: Lisp is becoming mainstream language (and python does not grow) [Was: Why is Lisp not as popular as Python?]
Date:
Message-ID: <hiohw5j7lhs2.dlg@parsec.no-spoon.de>
On 2005-04-30 12:56:27, Lars Rune N�stdal wrote:
> On Fri, 29 Apr 2005 14:26:57 -0400, Geoffrey Summerhayes wrote:
>> "Markus Grueneis" <··········@gmx.net> wrote in message
>> ····················@individual.net...
>>>
>>> The next question would be, why the hell Fortran is getting so much
>>> attention?
>>>
>>
>> All the 'Real Programmers' are retiring and leaving tons of spaghetti
>> behind?
>
> This is also known as the "Spaghetti Incident?"
"Fortran Fall" :-)
From: Lars Rune Nøstdal
Subject: Re: Lisp is becoming mainstream language (and python does not grow) [Was: Why is Lisp not as popular as Python?]
Date:
Message-ID: <pan.2005.04.30.14.48.32.257119@gmail.com>
On Sat, 30 Apr 2005 13:01:48 +0200, Stefan Scholl wrote:
> On 2005-04-30 12:56:27, Lars Rune Nøstdal wrote:
>> On Fri, 29 Apr 2005 14:26:57 -0400, Geoffrey Summerhayes wrote:
>>> "Markus Grueneis" <··········@gmx.net> wrote in message
>>> ····················@individual.net...
>>>>
>>>> The next question would be, why the hell Fortran is getting so much
>>>> attention?
>>>>
>>>
>>> All the 'Real Programmers' are retiring and leaving tons of spaghetti
>>> behind?
>>
>> This is also known as the "Spaghetti Incident?"
>
> "Fortran Fall" :-)
..let's hope it takes python and everything on the "evil branch" with it:
http://www.levenez.com/lang/history.html
hehe
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
From: Espen Vestre
Subject: Re: Lisp is becoming mainstream language (and python does not grow)
Date:
Message-ID: <kwhdhm5970.fsf@merced.netfonds.no>
"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> All the 'Real Programmers' are retiring and leaving tons of spaghetti
> behind?
LOL :) However, it has been possible to write pretty good-looking
fortran code for quite a few years now. The first time I got paid for
programming, in 1984, I translated really old Fortran IV code (talk
about obfuscated code!) to a newer DEC Fortran version and it (gosh!)
even had WHILE!
--
(espen)
"Espen Vestre" <·····@vestre.net> wrote in message ···················@merced.netfonds.no...
> "Geoffrey Summerhayes" <·············@hotmail.com> writes:
>
>> All the 'Real Programmers' are retiring and leaving tons of spaghetti
>> behind?
>
> LOL :) However, it has been possible to write pretty good-looking
> fortran code for quite a few years now. The first time I got paid for
> programming, in 1984, I translated really old Fortran IV code (talk
> about obfuscated code!) to a newer DEC Fortran version and it (gosh!)
> even had WHILE!
Oh sure, I was using WATFIV-S in the late 70's, but I imagine there's
still some arithmetic IFs still running out there somewhere...
--
Geoff
From: Espen Vestre
Subject: Re: Lisp is becoming mainstream language (and python does not grow)
Date:
Message-ID: <kwd5sa58zn.fsf@merced.netfonds.no>
Markus Grueneis <··········@gmx.net> writes:
> A (also questionable!) statistic, which mentions Lisp as A--
> (mainstream language for the 1st month), btw :)
Hmm, I was also suprised to see Prolog at rank 22 and Smalltalk
as low as down at 45 (but while lisp is on the rise again, companies
seem to have been running away from Smalltalk for 10 years now).
I've heard stories that there are Smalltalk shops that moved to lisp
when they found out what they'd lose by moving to java.
Maybe the most interesting about these numbers (if they say anything at
all?) is that they show that Java and C++ World Domination is a myth
- they are both declining.
--
(espen)
From: alex goldman
Subject: Re: Lisp is becoming mainstream language (and python does not grow)
Date:
Message-ID: <2056119.eFuCjacXg6@yahoo.com>
Espen Vestre wrote:
> Hmm, I was also suprised to see Prolog at rank 22 and Smalltalk
> as low as down at 45 (but while lisp is on the rise again, companies
> seem to have been running away from Smalltalk for 10 years now).
There must be something seriously wrong with their ratings scale, if Felix
is above Postscript, ML and Smalltalk. Nothing against it, but AFAIK, Felix
is just a 1-man language.
Nikhil Ketkar wrote:
> The rate at which the number of python users has grown and is growing
> is phenomenal. What caused this? Lisp has all the power Python has.
> Python draws a lot from Lisp but its no way near Lisp. What is the
> secret to its great PR ?
>
> Comments?
*WARNING*: Sometimes I am not very serious, and I hope those whom I
quoted won't be angry with me.
Why is Lisp not as popular as Python?
Lisp really isn't nearly as popular as Python. So, why? If postings
here reflect the opinions that dominate through the people that use
and develop Lisp, maybe these opinions could be the reason, too.
It was said that others think about Lisp as of old and slow language
with bad reputation and strange syntax. Also it is 'ai winter' now,
so Lisp is in hibernation. Also it forces all to be done 'The Lisp
Way' and requires abstract reasoning most human beings are uncapable
of. So it is only for a very, very outstandingly smart people. There
is only one of those on every ten thousand of ordinary dumb
programmers doomed to haul Java[1] code for the rest of their days.
Finally, the theological theory was introduced that 'Lisp *has* to be
unpopular'. It is due to some invisible force that drives human will
and averses it from Lisp. One day it will change, and Lisp will become
popular in itself. So, it all happens without any respect to our will
and our efforts, and all we can do is console ourselves: Lisp is our
secret weapon.
I can't stop wondering whether that all was said seriously, or maybe
I just understood everything wrong.
How does Lisp force a programmer to do things in a Lisp way? I know
from my sad experience how Java does, but in Lisp things can be done
the way you think, aren't they? In Lisp, "there's more than one way to
do it", too -- and nothing wrong with it, while the way is chosen
sanely, and preceding experience is taken into account. For example,
in nature, in life, even in mathematics there are often many good ways
of achieving the result. Is it wrong?
How can "AI winter" influence the ability of Lisp to be used
in solving our problems? Does Lisp have such a strong relation to AI?
Maybe our problems do? Of course, they probably could be solved in
a some fancy way with AI, but who now thinks about them in such terms?
And does Lisp have an ability to solve problems without AI?
What about slowness, it is not an issue when comparing Lisp and
Python. On Windows, I had an impression that CLISP (2002) in any task
I used it for was at least 1/3 faster than Python (2.4). And syntax
really doesn't matter that much even when learning a language.
Assembler and Fortran have weird syntax after learning C and vice
versa. C has weird syntax after using Basic. Did that stop anybody
if they really liked the language? And the best reason to like the
language is that it lets you succeed more and more in solving your
problems while you learn it.
That was about attracting newbies. Why many people who know Lisp
do not use it so often as many people who know Python use it?
From hotfuck.com[2] a voice of truth (by A.L.) was: because Python
solves (or helps to solve) some problems that Lisp doesn't. I want
to emphasize that A.L. said "Lisp doesn't", not "Lisp cannot".
So there is a question: what are those problems?
Instead of some metaphysical reasoning, I'd like to tell you a story.
I needed to write a program which works with DBMS, which
is concurrently accessed from several workstations. This program had
to have a GUI, because users needed a usable interface for entering
information and frequently getting reports on-the-fly. Finally, it had
to be in touch with another system working under win32, and the one
suitable interface for that system was COM. These are technical
requirements. I also needed as free licenses as possible for all
components I will use. So, neither Allegro, nor Lispworks meet this
requirement. $99 is too much, but what is worse, I would be dependent
on their proprietary code. And I definitely have no experience with
it and have no idea about the quality of that code. I frightened
to use GCL, because some of computers where this program needed to be
run had only 32Mb of RAM, and the version of GCL I had did allocate
70Mb on start by some strange reason. Also I didn't know if there are
any packages available for GCL at all. So, CLISP remained. I had no
luck finding packages for COM and DBMS I used. Several hours
of crawling the internet gave me an idea that packages like that
exist, but for commercial or incompatible Lisp versions. For GUI,
I choose GTK. So I needed to write wrappers for another two
components. But I had no time to do that, and, saying sincerely,
no experience.
As for Python, less for an hour, I got pyGTK, kinterbasdb, and
pywin32. All documented, free, and installable with couple of clicks.
So, do you still think that strange syntax and bad understanding how
to use it for real tasks are the main reasons why Lisp is not so
popular?
Having ability to be compiled to fast native code, and be the system
programming language, Lisp yields even a position of a 'glue' language
to Python. It is really sad because conceptually Lisp is absolutely
brilliant and by sum of it's features, it completely excels any
language I know. I would like to program in this language as much
as possible. For now, for leisure only. Lisp is a secret weapon,
so secret, that one is unable to find enough shells to charge and use
it.
Maybe I'm just too stupid to make it work right. Maybe for someone
it could even take noticeably less time and effort. Then I wish all of
you, smart people, a better luck using Lisp.
[1] My personal language of choice. For purpose of hate, of course.
[2] ... which, I believe, is the next impressive web-application
in Lisp, which will convince people to use that language.
On Thu, 28 Apr 2005 21:50:59 +0400, Revzala Haelmic <··@fck.org>
wrote:
>Instead of some metaphysical reasoning, I'd like to tell you a story.
>I needed to write a program which works with DBMS, which
>is concurrently accessed from several workstations. This program had
>to have a GUI, because users needed a usable interface for entering
>information and frequently getting reports on-the-fly. Finally, it had
>to be in touch with another system working under win32, and the one
>suitable interface for that system was COM. These are technical
>requirements. I also needed as free licenses as possible for all
>components I will use. So, neither Allegro, nor Lispworks meet this
>requirement. $99 is too much, but what is worse, I would be dependent
>on their proprietary code. And I definitely have no experience with
>it and have no idea about the quality of that code. I frightened
>to use GCL, because some of computers where this program needed to be
>run had only 32Mb of RAM, and the version of GCL I had did allocate
>70Mb on start by some strange reason. Also I didn't know if there are
>any packages available for GCL at all. So, CLISP remained. I had no
>luck finding packages for COM and DBMS I used. Several hours
>of crawling the internet gave me an idea that packages like that
>exist, but for commercial or incompatible Lisp versions. For GUI,
>I choose GTK. So I needed to write wrappers for another two
>components. But I had no time to do that, and, saying sincerely,
>no experience.
Good story, that gets to the heart of the kinds of tasks many
real-world programmers need to get done -- gluing together disparate
pieces that you cannot change or specify. A programmer would find that
he can do this in Python may choose Python for his next task, and
gradually become an evangelist within his organization. Initial
impressions matter; most programmers are working under time pressure
and are unlikely to pick their tools for theoretical advantages.
Of course, much of this amounts to having the right libraries
available. The interesting question is why they are easier to find in
Python and not lisp? Does it come down to the communities having
different interests? Or is Python easier to produce libraries for? Or
what?
--
adamnospamaustin.rr.com
s/nospam/c\./
From: André Thieme
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <d4rg8e$lpa$1@ulric.tng.de>
Revzala Haelmic schrieb:
> Finally, the theological theory was introduced that 'Lisp *has* to be
> unpopular'. It is due to some invisible force that drives human will
> and averses it from Lisp. One day it will change, and Lisp will become
> popular in itself. So, it all happens without any respect to our will
> and our efforts, and all we can do is console ourselves: Lisp is our
> secret weapon.
It's not a theological theory. Theory is okay, but it is based on a
scientific background. And to call it an "invisible force" is nonsense.
When looking at the behaviour of the masses one can find patterns that
are found elsewere. For example network effects.
Terror networks are similar to the railroad network in india, SARS
follows the same pattern as company takeovers in germany and the
physician Mark Newman found out that the social relation-ship network of
members of a karate club has mathematical similarities with the
ecosystem of plankton, bluefish and anchovy at the eastcoast of the US.
Read Albert-L�szl� Barab�si.
There is no magic involved. It "simply" that matter and systems (also
living "things") reorganize themselve in patterns, following some
universal laws.
Andr�
--
On Tue, 26 Apr 2005 22:32:32 -0700, Nikhil Ketkar wrote:
> The rate at which the number of python users has grown and is growing
> is phenomenal. What caused this? Lisp has all the power Python has.
> Python draws a lot from Lisp but its no way near Lisp. What is the
> secret to its great PR ?
>
> Comments?
> Nikhil Ketkar
I think all this is called 'The Britney Spears-effect', it's like a
recursive loop of some kind - like on the TV when the (N)sync is all wrong
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
I believe that one reason is how incredibly accessible python is to
both people who have c/c++/java experience and people who are
completely new to programming. The documentation on python.org is
superb; the tutorial is enough to get anyone writing a useful
application (which is easily distributable and cross-platform) after a
few hours of study; and the documentation for the extensive (which is
another plus) standard library leaves nothing to be desired. Another
great plus is the availability of good gui toolkit bindings; if I'm
writing something for which a gui is necessary I immediately reach for
pygtk.
I personally prefer programming in cl, I find it more enjoyable, but I
don't program for the sake of programming; I do it to solve problems;
often with python it is simpler to write a small to medium sized
cross-platform gui and network application and distribute it than with
cl.
-d
> 3.3 weakref -- Weak references
all common lisp implementations these days
> 3.14 pickle -- Python object serialization
> 3.17 shelve -- Python object persistence
prin1 and read are your friends.
> 4.2 re -- Regular expression operations
cl-ppre are asdf-install'able.
> 4.3 struct -- Interpret strings as packed binary data
read-from-string
> 4.4 difflib -- Helpers for computing deltas
http://www.cliki.net/diff
> 4.9 codecs -- Codec registry and base classes
it's not an advantage. It's deficiency. Common Lisp, Java, and any
other sane language handle encoding translations transparently. A
mechanism similar to codecs, but much better designed,
is present in all common lisp unicode-aware implementations
(acl,lispworks,clisp, probably others).
> 5.3 unittest -- Unit testing framework
> 5.4 test -- Regression tests package for Python
Never used it under either Python or CL,
(eval-when (:load-toplevel :execute) (test))
or
if __debug__: _test()
is just as good
> 5.6 decimal -- Decimal floating point arithmetic
imagine, it's standard in any common lisp.
> 7.5 threading -- Higher-level threading interface
most common lisp implementations these days (except for one of the five
I use)
> 7.20 readline -- GNU readline interface [*]
It's a stone edge technology, in fact. No one would use readline;
either a full-screen shell that allows editing and copy-paste, or runs
it in Emacs.
> 6.15 curses -- Terminal handling for character-cell displays
see above. You don't want to write applications for character-cell
displays. Most network cards have a web browser inside.
> 6.29 logging -- Logging facility for Python
This is only required because of lack of specials and restarts; the
module is to fix a deficiency in Python. All common lisps have specials
and restarts.
The rest, I believe, SHOULD NOT be in an implementation. Those are
special purpose libraries, and are in the base distribution because it
is hard to write them in Python, in fact. Some of them are written in
C, or wrappers around C, just because python too bad to implement them.
·············@gmail.com" wrote:
>> 3.14 pickle -- Python object serialization
>> 3.17 shelve -- Python object persistence
>
> prin1 and read are your friends.
They are not, unfortunately, a suitable substitute for
Python's "pickling"; too many things have no readable
external representation. In particular, class instances
don't.
>> 4.3 struct -- Interpret strings as packed binary data
>
> read-from-string
That doesn't do what the struct module does.
>> 5.3 unittest -- Unit testing framework
>> 5.4 test -- Regression tests package for Python
>
> Never used it under either Python or CL,
>
> (eval-when (:load-toplevel :execute) (test))
>
> or
>
> if __debug__: _test()
>
> is just as good
Not true.
>> 5.6 decimal -- Decimal floating point arithmetic
>
> imagine, it's standard in any common lisp.
It isn't standard in any Common Lisp. Have you actually
looked at what it does?
>> 6.15 curses -- Terminal handling for character-cell displays
>
> see above. You don't want to write applications for character-cell
> displays. Most network cards have a web browser inside.
If you prefer to look at support for GUIs, you won't
find the Python-versus-Lisp situation much better.
(Although CLIM is amazingly cool and Python has nothing
like it.)
>> 6.29 logging -- Logging facility for Python
>
> This is only required because of lack of specials and restarts; the
> module is to fix a deficiency in Python. All common lisps have specials
> and restarts.
Eh?
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> ·············@gmail.com" wrote:
>
>
>>> 3.14 pickle -- Python object serialization
>>> 3.17 shelve -- Python object persistence
>>
>>prin1 and read are your friends.
>
>
> They are not, unfortunately, a suitable substitute for
> Python's "pickling"; too many things have no readable
> external representation. In particular, class instances
> don't.
Write a method for the class to dump itself. That's just what you
have to do for Java's Serializable.
I don't know if Python's pickle has some automagic.
Maybe you could have an extra macro in Lisp that defines a class
and a dump and reread method for it? That should be rather easy
in fact.
>>> 5.3 unittest -- Unit testing framework
>>> 5.4 test -- Regression tests package for Python
The PCL book describes some unit testing ;)
It's surely possible to write more advanced stuff in Lisp;
probably most people and companies have already done that for
themselves.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
From: Edi Weitz
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <uu0lnthdx.fsf@agharta.de>
On Sat, 30 Apr 2005 20:06:27 -0500, Ulrich Hobelmann <···········@web.de> wrote:
> Write a method for the class to dump itself. That's just what you
> have to do for Java's Serializable.
>
> Maybe you could have an extra macro in Lisp that defines a class and
> a dump and reread method for it? That should be rather easy in
> fact.
<http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_ld_.htm>
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Ulrich Hobelmann <···········@web.de> writes:
> Gareth McCaughan wrote:
> > They are not, unfortunately, a suitable substitute for
> > Python's "pickling"; too many things have no readable
> > external representation. In particular, class instances
> > don't.
>
> Write a method for the class to dump itself. That's just what you
> have to do for Java's Serializable.
In Java, there is enough "magic" present to marshall and unmarshall an
object of a class marked as "Serializable" without further ado,
including all objects reachable via references.
Of course, mechanisms for finer control [1] exist.
Mike
[1] serialVersionUID, serialPersistentFields, {write,read}Object, ...
--
If you don't breathe, there is no air. DI Michael Wildpaner
If you don't walk, there is no earth. Ph.D. Student
If you don't speak, there is no world.
-- Navajo (Dineh) wisdom
From: Russell McManus
Subject: Re: Why is Lisp not as popular as Python?
Date:
Message-ID: <871x8qx1da.fsf@cl-user.org>
Michael Wildpaner <····@rainbow.studorg.tuwien.ac.at> writes:
> In Java, there is enough "magic" present to marshall and unmarshall an
> object of a class marked as "Serializable" without further ado,
> including all objects reachable via references.
How can this work automatically for an instance of a class that holds
a handle to an external resource acquired via an intermediate object
which is no longer accessible to the instance?
I think that you pretty quickly need the generality of make-load-form.
Note that lisp handles the easy cases pretty well with
make-load-form-saving-slots.
-russ
Russell McManus <···············@yahoo.com> writes:
> Michael Wildpaner <····@rainbow.studorg.tuwien.ac.at> writes:
>
> > In Java, there is enough "magic" present to marshall and unmarshall an
> > object of a class marked as "Serializable" without further ado,
> > including all objects reachable via references.
>
> How can this work automatically for an instance of a class that holds
> a handle to an external resource acquired via an intermediate object
> which is no longer accessible to the instance?
This also cannot be done (to my knowledge, and for the general case)
with pickle in python, to remind you of the original context of my
posting.
> I think that you pretty quickly need the generality of make-load-form.
> Note that lisp handles the easy cases pretty well with
> make-load-form-saving-slots.
It is true that in Java serialized objects mostly consist of data, not
code, which, for security reasons, might be construed as a feature in
certain classes of applications. E.g. in networking, the effort to
limit the Lisp reader to "safe" forms when evaluating code received
over the network to construct objects should be taken into
consideration.
The elegance of built-in mechanisms like make-load-form is not present
in Java, but nothing prevents you from storing an expression in any of
the myriad of JVM-based scripting languages with writeObject, and then
having it eval'ed on readObject by the proper scripting library, even
yielding a proper Java object (graph).
(tongue-in-cheek) Implementing make-load-form-saving-slots using Java
reflection is left as an exercise to the reader.
Mike
--
If you don't breathe, there is no air. DI Michael Wildpaner
If you don't walk, there is no earth. Ph.D. Student
If you don't speak, there is no world.
-- Navajo (Dineh) wisdom
Ulrich Hobelmann wrote:
> Gareth McCaughan wrote:
>> ·············@gmail.com" wrote:
>>
>>>> 3.14 pickle -- Python object serialization
>>>> 3.17 shelve -- Python object persistence
>>>
>>> prin1 and read are your friends.
>> They are not, unfortunately, a suitable substitute for
>> Python's "pickling"; too many things have no readable
>> external representation. In particular, class instances
>> don't.
>
> Write a method for the class to dump itself. That's just what you
> have to do for Java's Serializable.
>
> I don't know if Python's pickle has some automagic.
Yep.
> Maybe you could have an extra macro in Lisp that defines a class and a
> dump and reread method for it? That should be rather easy in fact.
That might be a useful thing to do. A standard readable representation
for classes would be neat, too.
--
Gareth McCaughan
.sig under construc
> In particular, class instances don't.
Write a macro.
>
> >> 4.3 struct -- Interpret strings as packed binary data
> >
> > read-from-string
>
> That doesn't do what the struct module does.
I've just tried to say that lisp didn't need that; python has it
because a significant part of python implementation cannot be written
in python.
> > if __debug__: _test()
> >
> > is just as good
>
> Not true.
It's what works for me much better than unittest/test; I have
self-testing code executing on each startup, no hassle.
>
> >> 5.6 decimal -- Decimal floating point arithmetic
> >
> > imagine, it's standard in any common lisp.
>
> It isn't standard in any Common Lisp. Have you actually
> looked at what it does?
Yes. It does exact decimal arithmetics. The rest is sugar.
> (/ 1 3)
1/3
* (rationalize 3.141592592)
51808/16491
> >> 6.15 curses -- Terminal handling for character-cell displays
> >
> > see above. You don't want to write applications for character-cell
> > displays. Most network cards have a web browser inside.
>
> If you prefer to look at support for GUIs, you won't
> find the Python-versus-Lisp situation much better.
> (Although CLIM is amazingly cool and Python has nothing
> like it.)
The GUIs don't come built-in. And there are many GUI libraries for
both.
>
> >> 6.29 logging -- Logging facility for Python
> >
> > This is only required because of lack of specials and restarts; the
> > module is to fix a deficiency in Python. All common lisps have
specials
> > and restarts.
>
> Eh?
That callback crap is only necessary because you need to pass a
stateful object with a few methods to report various conditions about.
A normal programming language makes it so much easier without callbacks
that eliminates the need for logging facilities such as that. I am both
CL and Python programmer; I know what I am talking about.
David
·············@gmail.com" wrote:
>> In particular, class instances don't.
>
> Write a macro.
Well, duh, yes. I'm not saying "you can't do these things
in Lisp"; obviously you can. (You can do just about anything
in Lisp.) I'm saying that it isn't true that Lisp already
has all those things you said it already has. That's all.
>>>> 4.3 struct -- Interpret strings as packed binary data
>>>
>>> read-from-string
>>
>> That doesn't do what the struct module does.
>
> I've just tried to say that lisp didn't need that; python has it
> because a significant part of python implementation cannot be written
> in python.
No. It has it because in various situations you want to
be able to unpack binary data you've read from a file
or a network socket or the internals of a core dump or
whatever.
>>> if __debug__: _test()
>>>
>>> is just as good
>>
>> Not true.
>
> It's what works for me much better than unittest/test; I have
> self-testing code executing on each startup, no hassle.
That's nice for you, but it doesn't do the same thing
that the unittest and test modules do, and those who
find those modules useful will not be helped by your
suggestion that "if __debug__: _test()" is just as good.
>>>> 5.6 decimal -- Decimal floating point arithmetic
>>>
>>> imagine, it's standard in any common lisp.
>>
>> It isn't standard in any Common Lisp. Have you actually
>> looked at what it does?
>
> Yes. It does exact decimal arithmetics. The rest is sugar.
Do you understand what is meant by "decimal arithmetic"
here? It *doesn't* mean the same thing as "arithmetic
with rationals having bignum numerator and denominator".
>> (/ 1 3)
> 1/3
>
> * (rationalize 3.141592592)
> 51808/16491
Do you imagine that I am unaware of CL's support for
rationals and the RATIONALIZE function? (I'm not.)
>>>> 6.29 logging -- Logging facility for Python
>>>
>>> This is only required because of lack of specials and restarts; the
>>> module is to fix a deficiency in Python. All common lisps have
>>> specials and restarts.
>>
>> Eh?
>
> That callback crap is only necessary because you need to pass a
> stateful object with a few methods to report various conditions about.
> A normal programming language makes it so much easier without callbacks
> that eliminates the need for logging facilities such as that.
I would guess that most users of the logging module
don't make any use of "that callback crap" but still
find the module useful. Sure, it's not hard to
implement something very like it in CL. The claim
wasn't "this can't be implemented in CL" but "this
comes with your basic Python installation and not
with its CL counterpart, and it's useful to some
people". Which is clearly true.
It's not quite clear to me what your argument is here;
are you saying that in a better programming language
there is no need for logging facilities at all? I don't
see how that could be, but I'm ready to be enlightened.
> I am both
> CL and Python programmer; I know what I am talking about.
I am both a CL and a Python programmer too, and your grasp of
the facts differs somewhat from mine.
--
Gareth McCaughan
.sig under construc
> Do you understand what is meant by "decimal arithmetic"
> here? It *doesn't* mean the same thing as "arithmetic
> with rationals having bignum numerator and denominator".
>
What's the difference? Rounding? Not a big deal, it's just integer
division by a power of 10.
Anything else?
The whole matter of having Decimal() in Python is the fact that
division on bignums in Python produces inexact result.
·················@gmail.com wrote:
> http://www.python.org/peps/pep-0327.html
> http://www.python.org/dev/doc/devel/lib/module-decimal.html
>
> Michele Simionato
I had read both the PEP and the module documentation. Decimals in
Python are both slower and more space-consuming than rationals in any
decent Common Lisp (CMUCL, LispWorks, for example). Overall, the PEP
seems to having been written by someone who does not understand much
about exact numbers arithmetic.
The important thing is that the Decimal module is conform
to the ANSI standards for decimal arithmetic, you don't
have to study them and to implement them yourself.
You should have seen the faces of people doing accounting software
with Python when the Decimal
module was announced.
And who cares about space and speed in
accounting software? Remember this was done in
COBOL! All that matters is conformity to published
standards.
The addition of the Decimal module was for great for
the marketing of Python in business applications.
Even if the implementation was ten times slower
and ten times more space inefficient than it is,
still it would have been a good thing.
Michele Simionato
·················@gmail.com writes:
> The important thing is that the Decimal module is conform
> to the ANSI standards for decimal arithmetic, you don't
> have to study them and to implement them yourself.
It's absolutely important to get the right answers, yes.
But that's not the only important thing by a long shot.
> You should have seen the faces of people doing accounting software
> with Python when the Decimal module was announced.
I take it that they were surprised. I can only speculate
that this was because they had previously been using
languages that didn't have support for decimal.
This leads me to wonder why they made that choice.
> And who cares about space and speed in accounting software?
> Remember this was done in COBOL! All that matters is conformity to
> published standards.
Is there some reason to believe that "COBOL is slow"?
Space and speed have always been major issues in
business software, such as accounting, payroll, etc.
Accounting is indeed heavily based on standardized practices.
Aren't most things?
·············@gmail.com" wrote:
>> Do you understand what is meant by "decimal arithmetic"
>> here? It *doesn't* mean the same thing as "arithmetic
>> with rationals having bignum numerator and denominator".
>
> What's the difference? Rounding? Not a big deal, it's just integer
> division by a power of 10.
> Anything else?
Rounding *is* a big deal even though conceptually it's
simple enough, and once again I need to remind you that
the complaint wasn't "you can't do this in Lisp" but
"Python comes with this, straight out of the box".
> The whole matter of having Decimal() in Python is the fact that
> division on bignums in Python produces inexact result.
Once again you oversimplify. If Python had had exact rationals
then implementing the Decimal type would have been less effort;
it still wouldn't have been zero, or close to zero.
--
Gareth McCaughan
.sig under construc
From: Marco Antoniotti
Subject: Decimal Arithmetic (Re: Why is Lisp not as popular as Python?)
Date:
Message-ID: <zisde.17$mi7.55076@typhoon.nyu.edu>
············@gmail.com wrote:
>
>> 5.6 decimal -- Decimal floating point arithmetic
>
>
> imagine, it's standard in any common lisp.
Sorry, but this is not the case. CL does not have Decimal floating
point arithmetic as intended in the PEP and as described in the
references in it. Java has Decimal arithmetic.
Now, what we could have in Common Lisp, is a much much much nicer way to
handle decimal numbers by introducing a #D macro (which, I believe is
still unclaimed) Then you could end up writing
(decarith:plus #D123.4 42.33)
==> #D165.73
Which I find much better than packing and unpacking strings as you need
in C/C++/Python/Java etc etc. Of course
(defmethod decarith:plus ((dn decimal-number) (n number)) ...)
is what gets called above.
Any takers? Note that linking in the C library floating around is a
no-no. Only a 100% CL implementation would do.
http://www2.hursley.ibm.com/decimal/
Cheers
--
marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ············@gmail.com wrote:
>>
>>> 5.6 decimal -- Decimal floating point arithmetic
>> imagine, it's standard in any common lisp.
>
> Sorry, but this is not the case. CL does not have Decimal floating
> point arithmetic as intended in the PEP and as described in the
> references in it. Java has Decimal arithmetic.
>
> Now, what we could have in Common Lisp, is a much much much nicer way
> to handle decimal numbers by introducing a #D macro (which, I believe
> is still unclaimed) Then you could end up writing
>
> (decarith:plus #D123.4 42.33)
> ==> #D165.73
>
> Which I find much better than packing and unpacking strings as you
> need in C/C++/Python/Java etc etc. Of course
>
> (defmethod decarith:plus ((dn decimal-number) (n number)) ...)
>
> is what gets called above.
>
> Any takers? Note that linking in the C library floating around is a
> no-no. Only a 100% CL implementation would do.
See the beginning of:
cvs -z3 -d ··················@cvs.informatimago.com:/usr/local/cvs/public/chrooted-cvs/cvs co common/common-lisp/invoice.lisp
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.