Re: merits of Lisp vs Python

[a2htray . yuen]

在 2006年12月8日星期五 UTC+8下午7:07:09，Mark Tarver写道：
> How do you compare Python to Lisp?  What specific advantages do you
> think that one has over the other?
> 
> Note I'm not a Python person and I have no axes to grind here.  This is
> just a question for my general education.
> 
> Mark

12 years ago.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Stephan Houben]

Op 2017-09-30, Marko Rauhamaa schreef :
> Robert L. is only trolling. He uses fake technical comments to spread
> white supremacy in his signatures.

My apologies.

Stephan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[breamoreboy]

On Saturday, September 30, 2017 at 9:03:32 PM UTC+1, Stephan Houben wrote:
> Op 2017-09-27, Robert L. schreef :
> > (sequence-fold + 0 #(2 3 4))
> > ===>
> > 9
> >
> > In Python?
> 
> >>> sum([2, 3, 4])
> 9

Dow you have to keep replying to this out and out racist, as none of his posts 
have any relevance to Python?

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Marko Rauhamaa]

Stephan Houben :

> Op 2017-09-27, Robert L. schreef :
>> (sequence-fold + 0 #(2 3 4))
>> ===>
>> 9
>>
>> In Python?
>
 sum([2, 3, 4])
> 9

Robert L. is only trolling. He uses fake technical comments to spread
white supremacy in his signatures.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Stephan Houben]

Op 2017-09-27, Robert L. schreef :
> (sequence-fold + 0 #(2 3 4))
> ===>
> 9
>
> In Python?

>>> sum([2, 3, 4])
9
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John J. Lee]

Jorge Godoy [EMAIL PROTECTED] writes:

 [EMAIL PROTECTED] (John J. Lee) writes:
 
  John Nagle [EMAIL PROTECTED] writes:
 
  John J. Lee wrote:
   Graham Dumpleton [EMAIL PROTECTED] writes:
  
  On Mar 11, 12:31 pm, [EMAIL PROTECTED] (John J. Lee) wrote:
  
   Is it possible to ask mod_python to start separate processes to serve
   requests, rather than separate interpreters?  We couldn't see a way.
  
  That's what CGI does.
 
  I meant long running processes, as I hoped was obvious from context...
 
 Maybe FastCGI should help, then.  It can run forever after a request has
 finished so it is suitable for long running processes. 

Yes, we've used FastCGI too.  My question was specifically about
mod_python.


John
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John J. Lee]

Graham Dumpleton [EMAIL PROTECTED] writes:
 On Mar 11, 12:31 pm, [EMAIL PROTECTED] (John J. Lee) wrote:
[...]
  mod_python relies on an unsupported feature of Python, namely
  multiple interpreters -- risk of more pain with C extensions.
 
 As usual, those bashing up on mod_python tend not to really know what
 they are talking about. :-(
 
 Although multiple Python interpreters cannot be manipulated directly
 from within a Python script, they can from the Python C API and it is
 very much a feature of Python and has been for a long time.

I didn't dispute that multiple interpreters are a feature of Python.
I said that they are an unsupported feature -- at least, Martin
v. Loewis says they're just broken, which is close enough for me:

http://groups.google.co.uk/group/comp.lang.python/browse_thread/thread/1ba97b5e088eb171/674accc133afbc96?rnum=2#674accc133afbc96


In any case, it looks like that the multiple interpreters feature of
Python is just broken.


[...]
 Even so, to get such a C extension module working in the context of
 mod_python simply means telling mod_python to run that particular
 application in the first interpreter instance by specifying the
 mod_python directive:
 
   PythonInterpreter main_interpreter
[...]

Is it possible to ask mod_python to start separate processes to serve
requests, rather than separate interpreters?  We couldn't see a way.


John
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Graham Dumpleton]

On Mar 15, 7:22 am, [EMAIL PROTECTED] (John J. Lee) wrote:
 Graham Dumpleton [EMAIL PROTECTED] writes:
  On Mar 11, 12:31 pm, [EMAIL PROTECTED] (John J. Lee) wrote:
 [...]
  mod_pythonrelies on an unsupported feature of Python, namely
   multiple interpreters -- risk of more pain with C extensions.

  As usual, those bashing up onmod_pythontend not to really know what
  they are talking about. :-(

  Although multiple Python interpreters cannot be manipulated directly
  from within a Python script, they can from the Python C API and it is
  very much a feature of Python and has been for a long time.

 I didn't dispute that multiple interpreters are a feature of Python.
 I said that they are an unsupported feature -- at least, Martin
 v. Loewis says they're just broken, which is close enough for me:

 http://groups.google.co.uk/group/comp.lang.python/browse_thread/threa...

 
 In any case, it looks like that the multiple interpreters feature of
 Python is just broken.
 

For mod_python at least, the issues described there do not present as
a problem because in mod_python sub interpreters are never destroyed
while the process is running. Thus as far as the implementation of
mod_python goes it is fine to key off the pointer to the interpreter
as one knows interpreters will never go away.

In the more general case I can see that it may be an issue for some
small percentage of C extension modules which may want to cache
information per interpreter. This though would only be the case if
they wanted to exclusively hold everything directly within the C code
space. Although it would perceivably slow access down, there is
nothing to stop such a module instantiating its own pseudo module
within the context of a sub interpreter using PyImport_AddModule().
This Python module could then be used to hold objects created by
PyCObject_FromVoidPtr() with access later being had by using
PyCObject_AsVoidPtr() after having looked up the object in the module.
As necessary, when creating these objects, the C extension module can
associate a cleanup function to be called when the object is destroyed
by virtue of the sub interpreter being destroyed. Thus the C extension
module would be able to cope with sub interpreters coming an going.

So, more work is required and some may be concerned about efficiency
and that a user may screw with the cached data from Python code, but
it is possible to have per interpreter information with a C extension
module.

 [...] Even so, to get such a C extension module working in the context of
 mod_pythonsimply means tellingmod_pythonto run that particular
  application in the first interpreter instance by specifying the
 mod_pythondirective:

PythonInterpreter main_interpreter

 [...]

 Is it possible to askmod_pythonto start separate processes to serve
 requests, rather than separate interpreters?  We couldn't see a way.

Within the context of Apache it is possible to write modules which
could spawn off a separate daemon process to which requests could
later be passed for processing. An example of this included with
Apache is something like mod_cgid. Other examples of modules which
allow requests to be farmed off to separate processes, although they
work a bit differently, are mod_fastcgi, mod_scgi and mod_proxy_ajp.

To do something similar with mod_python isn't really practical because
of the way it hooks into more than just the response handling phase of
Apache. This concept though is being investigated for some version of
mod_wsgi after the initial version has been released. When
implemented, it would allow mod_wsgi to either handle WSGI
applications in the same style as mod_python within the Apache child
processes, or optionally farm the request off to a separate process
running either as the same user as Apache or a different user, in the
same style as mod_fastcgi and mod_scgi. The difference with mod_wsgi
would be that it would be one self contained module all managed from
Apache and would not require a separate executable or daemon process
to Apache to be run to which it would communicate with as the separate
daemon processes would ultimately just be a fork of the Apache parent
process and be running code from the Apache module itself. Also the
application scripts would be exactly the same no matter which mode it
was running in so no need to modify them in any special way to run
under the separate process.

Graham

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John Nagle]

John J. Lee wrote:
 Graham Dumpleton [EMAIL PROTECTED] writes:
 
On Mar 11, 12:31 pm, [EMAIL PROTECTED] (John J. Lee) wrote:

 Is it possible to ask mod_python to start separate processes to serve
 requests, rather than separate interpreters?  We couldn't see a way.

That's what CGI does.

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John J. Lee]

John Nagle [EMAIL PROTECTED] writes:

 John J. Lee wrote:
  Graham Dumpleton [EMAIL PROTECTED] writes:
 
 On Mar 11, 12:31 pm, [EMAIL PROTECTED] (John J. Lee) wrote:
 
  Is it possible to ask mod_python to start separate processes to serve
  requests, rather than separate interpreters?  We couldn't see a way.
 
 That's what CGI does.

I meant long running processes, as I hoped was obvious from context...


John
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jorge Godoy]

[EMAIL PROTECTED] (John J. Lee) writes:

 John Nagle [EMAIL PROTECTED] writes:

 John J. Lee wrote:
  Graham Dumpleton [EMAIL PROTECTED] writes:
 
 On Mar 11, 12:31 pm, [EMAIL PROTECTED] (John J. Lee) wrote:
 
  Is it possible to ask mod_python to start separate processes to serve
  requests, rather than separate interpreters?  We couldn't see a way.
 
 That's what CGI does.

 I meant long running processes, as I hoped was obvious from context...

Maybe FastCGI should help, then.  It can run forever after a request has
finished so it is suitable for long running processes. 

-- 
Jorge Godoy  [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

OLPC vs. mobile phones (was Re: merits of Lisp vs Python)

[Paul Boddie]

Gabriel Genellina wrote:
 En Fri, 09 Mar 2007 16:10:51 -0300, Tim Bradshaw [EMAIL PROTECTED] escribió:

  The electronic gadget people need in the developing world is a mobile phone 
  not a
  computer.

 What for?
 That requires a phone company, installed antennas everywhere, and
 available power to charge batteries. Without forgetting  you to pay the
 bill, of course.

What people in the developing world needs is Iridium! Oops! ;-) I've
heard of people doing interesting things with mobile phones in various
developing countries, and I'm sure that the infrastructure is
gradually expanding in some places, but the mobile phone is largely a
consumer device: you pay big corporations to use their networks and
to download largely frivolous content. I hardly think such things are
on the same page as the OLPC vision.

 I don't think OLPC would actually help people so much, but a mobile phone
 would be almost useless. Like it was -actually happened- donating nice
 computers for use in remote elementary schools with no power source.

Yes, such things were mentioned in the FOSDEM OLPC talk [1]. It's all
very well having rich Europeans or Americans (especially thinking of
people like Bill Gates who seems to opine regularly on such things in
a way which is unlikely to be completely disconnected to his business
interests) saying that all the old kit that people don't want any more
(because they must have that new quad-core laptop!) should be shipped
out to places that need it, but the issue is whether the recipients
really do need to have aging, power-hungry technology with special
waste disposal requirements when it finally gives up the ghost.

Sure, give people a bunch of old PCs (and why not all those CRTs,
too?) which consume tens of watts per unit. Do we have any old solar
panels to ship out with them? Or how about building some nuclear power
stations to go with all this equipment? Still a good idea?!

Paul

[1] Videos are available at http://www.fosdem.org/2007/media/video -
and in an open format, too. (Hint to any conference people thinking of
just uploading stuff to YouTube!)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John J. Lee]

Gabriel Genellina [EMAIL PROTECTED] writes:

 En Fri, 09 Mar 2007 16:10:51 -0300, Tim Bradshaw [EMAIL PROTECTED] 
 escribiŽ�:
[...]
  ill-conceived idea (not because of Python, note!).  The electronic
  gadget people need in the developing world is a mobile phone not a
  computer.
 
 What for?
 That requires a phone company, installed antennas everywhere, and
 available power to charge batteries. Without forgetting  you to pay
 the  bill, of course.
 I don't think OLPC would actually help people so much, but a mobile
 phone  would be almost useless.
[...]

How wrong can you get?

Mobile phones have been making a significant economic impact in many
places in the third world.  Sub-saharan Africa has seen huge growth in
access to mobile phones over the past few years, for example.  A
recent report indicates there are now over 100 million mobile phones
in use in Africa.  That's a huge change im communications from five
years ago, but more than that, since people often don't own a mobile,
but rent them by the minute from at the roadside, access levels must
be much higher than that would imply (i.e., much greater than 10% of
the continent's population).

Mobile connections are intrinsically cheaper than fixed-line networks,
can be rolled out faster, and have a disproportionately large impact
in places where such electronic communications have in the past been
absent, when compared with places like Europe and the US.  For
example, farmers report that they find mobile phones valuable to get
information on market prices; without them, they would in the past
have little choice but to physically go to market and hope for the
best.

http://www.timesonline.co.uk/tol/news/world/article737130.ece


I know nothing about OLPC, but I hope they're spending lots of time
talking to children, teachers, and academics, and to anybody with a
good criticism.  It must be tricky for big projects to stay connected
to reality.


John
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John J. Lee]

John Nagle [EMAIL PROTECTED] writes:
[...]
 Python, on the other hand, is uphill all the way.  Constant trouble
 with version issues, especially with C components called from Python.
 MySQLdb, M2Crypto, SSL - they all have platform/version
 incompatibility problems.  I just spent three days making M2Crypto
 work on a new Linux server with a different Red Hat version.
 Neither Python's packaging tools nor the platform's packaging
 tools deal adequately with these issues.
[...]

You haven't been using mod_python, by any chance?


John
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John Nagle]

John J. Lee wrote:
 John Nagle [EMAIL PROTECTED] writes:
 [...]
 
Python, on the other hand, is uphill all the way.  Constant trouble
with version issues, especially with C components called from Python.
MySQLdb, M2Crypto, SSL - they all have platform/version
incompatibility problems.  I just spent three days making M2Crypto
work on a new Linux server with a different Red Hat version.
Neither Python's packaging tools nor the platform's packaging
tools deal adequately with these issues.
 
 [...]
 
 You haven't been using mod_python, by any chance?
 
 
 John

No, haven't started to deal with that yet.  Still using
CGI.  Not sure whether to use mod_python or fastcgi for the
small requests where the Python load time swamps the time
to do one SQL select and reply.  Comments?

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John J. Lee]

John Nagle [EMAIL PROTECTED] writes:

 John J. Lee wrote:
  John Nagle [EMAIL PROTECTED] writes:
  [...]
 
 Python, on the other hand, is uphill all the way.  Constant trouble
 with version issues, especially with C components called from Python.
 MySQLdb, M2Crypto, SSL - they all have platform/version
 incompatibility problems.  I just spent three days making M2Crypto
 work on a new Linux server with a different Red Hat version.
 Neither Python's packaging tools nor the platform's packaging
 tools deal adequately with these issues.
  [...]
  You haven't been using mod_python, by any chance?
  John
 
 No, haven't started to deal with that yet.  Still using
 CGI.  Not sure whether to use mod_python or fastcgi for the
 small requests where the Python load time swamps the time
 to do one SQL select and reply.  Comments?

mod_python relies on an unsupported feature of Python, namedly
multiple interpreters -- risk of more pain with C extensions.


John
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Graham Dumpleton]

On Mar 11, 12:31 pm, [EMAIL PROTECTED] (John J. Lee) wrote:
 John Nagle [EMAIL PROTECTED] writes:
  John J. Lee wrote:
   John Nagle [EMAIL PROTECTED] writes:
   [...]

  Python, on the other hand, is uphill all the way.  Constant trouble
  with version issues, especially with C components called from Python.
  MySQLdb, M2Crypto, SSL - they all have platform/version
  incompatibility problems.  I just spent three days making M2Crypto
  work on a new Linux server with a different Red Hat version.
  Neither Python's packaging tools nor the platform's packaging
  tools deal adequately with these issues.
   [...]
   You haven't been usingmod_python, by any chance?
   John

  No, haven't started to deal with that yet.  Still using
  CGI.  Not sure whether to usemod_pythonor fastcgi for the
  small requests where the Python load time swamps the time
  to do one SQL select and reply.  Comments?

 mod_pythonrelies on an unsupported feature of Python, namedly
 multiple interpreters -- risk of more pain with C extensions.

As usual, those bashing up on mod_python tend not to really know what
they are talking about. :-(

Although multiple Python interpreters cannot be manipulated directly
from within a Python script, they can from the Python C API and it is
very much a feature of Python and has been for a long time.

The only issue with multiple sub interpreters in respect of C
extension modules is that implementers of those C extension modules
take the easy path and use the simplified thread API for GIL locking.
The consequence of them doing that is that their C extension module
may not work when used in anything but the first interpreter created
by Python. If instead of using the simplified thread API for GIL
locking they used other parts of the Python threading API as
appropriate and did thread lock handling properly for multiple
interpreters, there would not be an issue.

Even so, to get such a C extension module working in the context of
mod_python simply means telling mod_python to run that particular
application in the first interpreter instance by specifying the
mod_python directive:

  PythonInterpreter main_interpreter

Thus, the problem is not mod_python at all, but that the C extension
modules implementer didn't bother to implement their module so as to
be usable within a system such as mod_python where multiple
interpreters are used. Further, mod_python even provides a way to work
around the problems with such third party C extension modules.

If you feel that this is not the case and mod_python is still broken
in some way, please properly explain what the problem is.

PS. Yes I do know that forcing using of main interpreter in mod_python
only helps solve this problem in mod_python 3.2 and later and did not
help with older versions.

Graham

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Terry Reedy]

Alex Martelli [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
| later sold for mucho dinero) is an unabashed fan of Python; the XO
| (nee One Laptop Per Child, OLPC, and once known as the $100 laptop)
| uses Python as its preferred (only?-) application language, and it's
| slated to be the most widely distributed Python distro if it hits even
| half of its ambitious target-numbers...

The exciting part to me is that the somewhat inovative user inteface is 
writen in Python and intended to be hacked on by the users (kids) around 
the world.

tjr



-- 
http://mail.python.org/mailman/listinfo/python-list

Python-friendly hosting (was Re: merits of Lisp vs Python)

[Paul Boddie]

On 9 Mar, 02:32, John Nagle [EMAIL PROTECTED] wrote:


[Dedicated server offerings]

I'm not so familiar with dedicated servers, being unlikely to buy into
that kind of hosting any time soon - I'm not running a business with
serious reliability/control/uptime constraints where I could justify
spending that kind of money. However...

  In neither case is the Python environment typically ready for serious use
 out of the box.

Well, I can't say much about the off-the-shelf, locked down solutions
with Plesk control panels, but if you just get a box with the pipes
(an empty machine in a rack), you make from that what you will. Such
a solution isn't likely to be any good for Perl, PHP or Ruby out of
the box, either. I mean, what's the operating system? Do you have to
provide that? If so, any modern GNU/Linux distribution would give you
lots of acceptable packages for Python.

  There's denial in the Python community that this is a problem, but it is.
 The Ruby on Rails people get it; they work to provide a seamless experience
 for web developers.  Which is why their market share is way up over two years
 ago.

They got a number of things right. However, the big difference as I
see it is that instead of wondering why various providers don't
support Rails, they've either gone and started their own (including
virtual private server solutions), or they've found existing, flexible
providers (such as WebFaction) who were already providing lots of
plumbing for various Python-based solutions and persuaded them to
provide support for Rails. Last time I looked, Rails deployment
situation seemed closely tied to FastCGI and a lot of other stuff that
is arguably less attractive to various hosting providers than many of
the ways you can deploy Python Web solutions.

As for the denial, I can see your point to an extent. Before the Rails
hype there were discussions about making Python solutions as
attractive to deploy as PHP solutions, but a lot of the movers and
shakers in the Python Web community seem to have the luxury of
managing their own Internet-facing infrastructure. Thus, any progress
really has to be driven by people like you with your own hosting
requirements.

Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Tim Bradshaw]

On 2007-03-09 07:00:06 +, [EMAIL PROTECTED] (Alex Martelli) said:

 (nee One Laptop Per Child, OLPC, and once known as the $100 laptop)
 uses Python as its preferred (only?-) application language, and it's
 slated to be the most widely distributed Python distro if it hits even
 half of its ambitious target-numbers...

But it won't get anywhere near that because it's a stupid an 
ill-conceived idea (not because of Python, note!).  The electronic 
gadget people need in the developing world is a mobile phone not a 
computer.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Michael Bentley]

On Mar 9, 2007, at 1:10 PM, Tim Bradshaw wrote:
 On 2007-03-09 07:00:06 +, [EMAIL PROTECTED] (Alex Martelli) said:

 (nee One Laptop Per Child, OLPC, and once known as the $100  
 laptop)
 uses Python as its preferred (only?-) application language, and it's
 slated to be the most widely distributed Python distro if it hits  
 even
 half of its ambitious target-numbers...

 But it won't get anywhere near that because it's a stupid an
 ill-conceived idea (not because of Python, note!).  The electronic
 gadget people need in the developing world is a mobile phone not a
 computer.

Isn't the idea to provide a learning environment for children in the  
developing world (rather than a generally useful gadget)?  Perhaps a  
mobile phone would also be good for this sort of thing -- if it had a  
'show source' button :-)

obpython: isn't OLPC is right in line with 'Computer Programming for  
Everybody'?







-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Gabriel Genellina]

En Fri, 09 Mar 2007 16:10:51 -0300, Tim Bradshaw [EMAIL PROTECTED] escribió:

 On 2007-03-09 07:00:06 +, [EMAIL PROTECTED] (Alex Martelli) said:

 (nee One Laptop Per Child, OLPC, and once known as the $100 laptop)
 uses Python as its preferred (only?-) application language, and it's
 slated to be the most widely distributed Python distro if it hits even
 half of its ambitious target-numbers...
 But it won't get anywhere near that because it's a stupid an
 ill-conceived idea (not because of Python, note!).  The electronic
 gadget people need in the developing world is a mobile phone not a
 computer.

What for?
That requires a phone company, installed antennas everywhere, and  
available power to charge batteries. Without forgetting  you to pay the  
bill, of course.
I don't think OLPC would actually help people so much, but a mobile phone  
would be almost useless. Like it was -actually happened- donating nice  
computers for use in remote elementary schools with no power source.

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John Nagle]

Brian Adkins wrote:
 Ken Tilton wrote:
 
 John Nagle wrote:

 Turns out John is having quite a tough time with Python web hosting (the 
 thread has split off to a c.l.p only fork), so I'm going to cut him some 
 slack. Maybe with some lovin' we can woo him over to c.l.l ;)

 Been there, done that.  I've actually used an original refrigerator
sized Symbolics LISP machine.

 I tend to think of Python as a LISP with infix syntax.
We have a better handle on what to put in a dynamic language now, and
Python does a good job in that direction.  I'm happy with the
language; it's the integration with external components that isn't
working.

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Stephen Eilert]

On Mar 8, 5:23 am, John Nagle [EMAIL PROTECTED] wrote:
 Brian Adkins wrote:
  Ken Tilton wrote:

  John Nagle wrote:
  Turns out John is having quite a tough time with Python web hosting (the
  thread has split off to a c.l.p only fork), so I'm going to cut him some
  slack. Maybe with some lovin' we can woo him over to c.l.l ;)

  Been there, done that.  I've actually used an original refrigerator
 sized Symbolics LISP machine.

  I tend to think of Python as a LISP with infix syntax.
 We have a better handle on what to put in a dynamic language now, and
 Python does a good job in that direction.  I'm happy with the
 language; it's the integration with external components that isn't
 working.

 John Nagle


OMG! And I thought the thread was dead!

Necromancers! Run!!!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Chris Mellon]

On 3/8/07, Dennis Lee Bieber [EMAIL PROTECTED] wrote:
 On Thu, 08 Mar 2007 06:13:15 GMT, John Nagle [EMAIL PROTECTED]
 declaimed the following in comp.lang.python:

 
  When starting out with this project, I'd made the assumption that
  Python was a stable, working, well-supported technology, like Perl
  hosting.  It isn't.
 
 It is interesting how your text seems to blame Python (the
 language) when comparing not to Perl (the language) but to a service
 field of Perl hosting.

 At the least, be fair and use the phrase Python hosting in any
 place you'd have used Perl hosting...


 (I note in passing you did have a comment about Python, the language,
 being good... but anyone reading quickly would tend to interpret, say
 the part quoted above, as Python is unstable, doesn't work, and
 unsupported -- none of which, in my experience, is true... Low-cost web
 hosting with Python is a different kettle of fish [chowder, probably
 G])


Mr. Nagle has a history of phrasing his personal problems as if they
were vast, sweeping, general issues affecting the entire industry. The
original post, and several followups, referred to *real* hosting
provides, with the emphasis, and in the context of industrial
strength. Any *real* hosting provider is going to support whatever
language and environment I tell them to, because I'm going to pay them
a lot of money for excellent support and if they give me any trouble I
will go with someone who provides what I want.


What was *meant* was low priced, zero maintenance, reasonably reliable
consumer level hosting. Thats a totally different market, it's not
industrial strength, and it doesn't merit the emphasis on *real*
provider. And it is true that in that realm Python is not well
represented.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Chris Mellon [EMAIL PROTECTED] writes:
 Any *real* hosting provider is going to support whatever
 language and environment I tell them to, because I'm going to pay them
 a lot of money for excellent support and if they give me any trouble I
 will go with someone who provides what I want.

Hosting providers are generally not in the business of doing anything
like that, except the low end ones that mostly support PHP.  

 What was *meant* was low priced, zero maintenance, reasonably reliable
 consumer level hosting. Thats a totally different market, it's not
 industrial strength, and it doesn't merit the emphasis on *real*
 provider. And it is true that in that realm Python is not well
 represented.

Python is not so well represented in industrial strength hosting
either; that kind of hosting generally leaves language support up to
the customer.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Aahz]

In article [EMAIL PROTECTED],
Paul Rubin  http://[EMAIL PROTECTED] wrote:

Care to name a real hosting provider that cares whether Python works?

http://www.webfaction.com/
-- 
Aahz ([EMAIL PROTECTED])   * http://www.pythoncraft.com/

I disrespectfully agree.  --SJM
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

[EMAIL PROTECTED] (Aahz) writes:
 Care to name a real hosting provider that cares whether Python works?
 http://www.webfaction.com/

Thanks!  This is good to know about.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John Nagle]

Paul Rubin wrote:
 Chris Mellon [EMAIL PROTECTED] writes:
 
Any *real* hosting provider is going to support whatever
language and environment I tell them to, because I'm going to pay them
a lot of money for excellent support and if they give me any trouble I
will go with someone who provides what I want.

Who are you buying from?

 Hosting providers are generally not in the business of doing anything
 like that, except the low end ones that mostly support PHP.  
 
 
What was *meant* was low priced, zero maintenance, reasonably reliable
consumer level hosting. Thats a totally different market, it's not
industrial strength, and it doesn't merit the emphasis on *real*
provider. And it is true that in that realm Python is not well
represented.
 
 
 Python is not so well represented in industrial strength hosting
 either; that kind of hosting generally leaves language support up to
 the customer.

 The industry trend seems to be towards two dedicated server offerings.
One is dedicated hosting in a relatively controlled manner, with web based
server control and a somewhat locked down environment.  You get
root access, but if you mess with the controlled environment, it's
your problem if anything breaks.  The Plesk control panel is widely
used for this.

 The other offering is power, pipe, and ping - an empty machine in
a rack.  What you do with it is your problem.

 In neither case is the Python environment typically ready for serious use
out of the box.

 There's denial in the Python community that this is a problem, but it is.
The Ruby on Rails people get it; they work to provide a seamless experience
for web developers.  Which is why their market share is way up over two years
ago.

 Here's an overview of the dedicated server industry from the Gartner
Group:

http://www.savvis.net/NR/rdonlyres/E2C3E79F-8F8D-46D0-9718-E26C76805D0F/13782/SAVVISPositionedasLeaderinGartnerNAHostingMQGARTNE.pdf

 There's an emphasis on standardized offerings from the major players.
Customized environments are usually either user-managed or offered
as part of enterprise IT outsourcing.

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

John Nagle [EMAIL PROTECTED] writes:
  There's denial in the Python community that this is a problem,
 but it is.  The Ruby on Rails people get it; they work to provide a
 seamless experience for web developers.  Which is why their market
 share is way up over two years ago.

I do know that a big Perl site that I hang out on (but am not involved
with the software for) decided to redo its software and had a big
discussion of what to use.  Python/Django was a serious contender but
in the end they chose Ruby on Rails.  I didn't pay too close attention
to the exact rationale but it was somewhat disappointing and yet
unsurprising.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Alex Martelli]

Paul Rubin http://[EMAIL PROTECTED] wrote:

 alex23 [EMAIL PROTECTED] writes:
   Hosting providers and distro
   makers aren't concerned over whether Python works.  They
   care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
   Ask them.
  
  Do you have any real experience with recent linux distros? Or with any
  _real_ hosting providers?
 
 Care to name a real hosting provider that cares whether Python works?

The first name that comes to mind is xs4all, the major Dutch provider
(they've even got their own Wikipedia entry!-) -- they've long offered
outstanding sponsorship to the Python community, hosting lots of
services for us, btw.

But the OP's mention of distro ain't even funny -- ever since RedHat's
original implementation of RPM (in Python), ever more Linux distros are
positively _fanatical_ about Python.  Ubuntu, for example, has as its
BDFL Mark Shuttleworth, who (since, as he explains, he made his fortune
thanks to Python -- Python's what allowed him to build Thawte, which he
later sold for mucho dinero) is an unabashed fan of Python; the XO
(nee One Laptop Per Child, OLPC, and once known as the $100 laptop)
uses Python as its preferred (only?-) application language, and it's
slated to be the most widely distributed Python distro if it hits even
half of its ambitious target-numbers...


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Brian Adkins]

George Sakkis wrote:
 [EMAIL PROTECTED] wrote:
 
 1. Lisp is the only industrial strength language
   ^^^
 You keep using that phrase. I don't think it means what you think it
 means.

[Vizzini has just cut the rope The Dread Pirate Roberts is climbing up]
Vizzini: HE DIDN'T FALL? INCONCEIVABLE.
Inigo Montoya: You keep using that word. I do not think it means what 
you think it means.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John Nagle]

Brian Adkins wrote:
 George Sakkis wrote:
 
 [EMAIL PROTECTED] wrote:

 1. Lisp is the only industrial strength language

Neither Lisp nor Python is an industrial strength language.
The infrastructure is too weak.  Hosting providers and distro
makers aren't concerned over whether Python works.  They
care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
Ask them.

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Brian Adkins]

John Nagle wrote:
Neither Lisp nor Python is an industrial strength language.
 The infrastructure is too weak.  Hosting providers and distro
 makers aren't concerned over whether Python works.  They
 care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
 Ask them.
 
 John Nagle

In your excitement to post a sweeping and inaccurate generalization (you 
missed diss'ing Ruby), I think you may have missed the point of my post. 
I surely wasn't trying to restart a dead thread, I just thought it was 
funny that there was a similarity to a line from Princess Bride in the 
thread (see relevant part below that you cut out).

If you want to restart a debate, please go back and reply to some 
serious post in the thread - don't hijack mine for your own evil 
purposes and cut out the good parts - did you even see the movie?

George Sakkis wrote:
  You keep using that phrase. I don't think it means what you think it
  means.

[Vizzini has just cut the rope The Dread Pirate Roberts is climbing up]
Vizzini: HE DIDN'T FALL? INCONCEIVABLE.
Inigo Montoya: You keep using that word. I do not think it means what 
you think it means.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Brian Adkins wrote:
 John Nagle wrote:
 
Neither Lisp nor Python is an industrial strength language.
 The infrastructure is too weak.  Hosting providers and distro
 makers aren't concerned over whether Python works.  They
 care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
 Ask them.

 John Nagle
 
 
 In your excitement to post a sweeping and inaccurate generalization (you 
 missed diss'ing Ruby), I think you may have missed the point of my post. 
 I surely wasn't trying to restart a dead thread, I just thought it was 
 funny that there was a similarity to a line from Princess Bride in the 
 thread (see relevant part below that you cut out).
 
 If you want to restart a debate, please go back and reply to some 
 serious post in the thread - don't hijack mine for your own evil 
 purposes and cut out the good parts - did you even see the movie?

Yes. I think George did, too. (I was wondering what you were up to.)

:)

kt


 
 George Sakkis wrote:
   You keep using that phrase. I don't think it means what you think it
   means.
 
 [Vizzini has just cut the rope The Dread Pirate Roberts is climbing up]
 Vizzini: HE DIDN'T FALL? INCONCEIVABLE.
 Inigo Montoya: You keep using that word. I do not think it means what 
 you think it means.

-- 
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
   -- Elwood P. Dowd

In this world, you must be oh so smart or oh so pleasant.
   -- Elwood's Mom
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John Nagle]

Brian Adkins wrote:
 John Nagle wrote:

 If you want to restart a debate, please go back and reply to some 
 serious post in the thread - don't hijack mine for your own evil 
 purposes and cut out the good parts - did you even see the movie?

If you want to post jokes, try rec.humor.funny.  Although
they mave moderation and you may not

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[alex23]

John Nagle wrote:
 Hosting providers and distro
 makers aren't concerned over whether Python works.  They
 care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
 Ask them.

Do you have any real experience with recent linux distros? Or with any
_real_ hosting providers?

Because what you've said is clearly not true. Just because the
situation isn't as easy _for you_ as you would like, doesn't mean that
Python is being ignored to the extent you're trying to claim.

-alex23

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

alex23 [EMAIL PROTECTED] writes:
  Hosting providers and distro
  makers aren't concerned over whether Python works.  They
  care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
  Ask them.
 
 Do you have any real experience with recent linux distros? Or with any
 _real_ hosting providers?

Care to name a real hosting provider that cares whether Python works?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Brian Adkins]

alex23 wrote:
 John Nagle wrote:
 Hosting providers and distro
 makers aren't concerned over whether Python works.  They
 care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
 Ask them.
 
 Do you have any real experience with recent linux distros? Or with any
 _real_ hosting providers?
 
 Because what you've said is clearly not true. Just because the
 situation isn't as easy _for you_ as you would like, doesn't mean that
 Python is being ignored to the extent you're trying to claim.
 
 -alex23
 

alex23 - please don't feed the trolls.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John Nagle]

Brian Adkins wrote:
 alex23 wrote:
 
 John Nagle wrote:

 Hosting providers and distro
 makers aren't concerned over whether Python works.  They
 care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
 Ask them.


 Do you have any real experience with recent linux distros? Or with any
 _real_ hosting providers?

Do you?  You're writing from a gmail account, not your own site.

I have four hosting accounts with EZpublishing and a dedicated server
at Aplus.net.  I spent weeks trying to find a hosting provider that
would provide a Python environment that just works, like everyone
does for Perl.  What you typically get is a basic Python 2.4,
and a refusal to install more packages, because it's so time-consuming.
Or a quote of $50 to $150 per hour to install Python packages.

There are a very few hosting providers that actually want to provide
Python hosting, such as Hard Hat Hosting.  But most don't.

 Because what you've said is clearly not true. Just because the
 situation isn't as easy _for you_ as you would like, doesn't mean that
 Python is being ignored to the extent you're trying to claim.

I don't see any evidence to back up this unsubstantiated claim.

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Brian Adkins]

John Nagle wrote:
 Brian Adkins wrote:
 alex23 wrote:

 John Nagle wrote:

 Hosting providers and distro
 makers aren't concerned over whether Python works.  They
 care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
 Ask them.


 Do you have any real experience with recent linux distros? Or with any
 _real_ hosting providers?
 
Do you?  You're writing from a gmail account, not your own site.
 
I have four hosting accounts with EZpublishing and a dedicated server
 at Aplus.net.  I spent weeks trying to find a hosting provider that
 would provide a Python environment that just works, like everyone
 does for Perl.  What you typically get is a basic Python 2.4,
 and a refusal to install more packages, because it's so time-consuming.
 Or a quote of $50 to $150 per hour to install Python packages.
 
There are a very few hosting providers that actually want to provide
 Python hosting, such as Hard Hat Hosting.  But most don't.

 Because what you've said is clearly not true. Just because the
 situation isn't as easy _for you_ as you would like, doesn't mean that
 Python is being ignored to the extent you're trying to claim.
 
I don't see any evidence to back up this unsubstantiated claim.
 
 John Nagle

Ok, since you provided some details you appear less troll-like, so I'll 
ignore my own advice.

With prices of dedicated servers and virtual private servers so cheap, 
why would anyone get a hosting account without root access? Once you 
have root, just install whatever you want. It shouldn't take more than a 
few minutes to install Python or whatever language you desire.

If apt-get install doesn't give you a recent enough version, just 
download the source and compile it.

Brian

P.S. very cool rag doll physics by the way...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Brian Adkins [EMAIL PROTECTED] writes:
 With prices of dedicated servers and virtual private servers so cheap,
 why would anyone get a hosting account without root access? 

Because it turns you into a sysadmin instead of letting specialists
handle all the OS stuff so you can concentrate on your application.

Also, no VPS where you have to run your own httpd instance (and
usually your own database if you're using one) can possibly be as
cheap as a virtual host where you're sharing the same httpd with
thousands of other sites.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Brian Adkins]

Paul Rubin wrote:
 Brian Adkins [EMAIL PROTECTED] writes:
 With prices of dedicated servers and virtual private servers so cheap,
 why would anyone get a hosting account without root access? 
 
 Because it turns you into a sysadmin instead of letting specialists
 handle all the OS stuff so you can concentrate on your application.

I'm not sure what OS stuff you're referring to, but my interactions 
with my dedicated host are quite similar to when I had a shared hosting 
account (except I never have to contact the hosting company like I used 
to with a shared account - it just keeps humming along).

Besides, this whole thing got started with John resurrecting the 
industrial strength argument. I hardly think a shared hosting account 
would be considered industrial strength. If you're not willing to deal 
with a dedicated server, then I don't think you're serious about 
industrial strength, right? Not to mention the fact that none of this 
has anything to do with the industrial strengthness of the language.

 
 Also, no VPS where you have to run your own httpd instance (and
 usually your own database if you're using one) can possibly be as
 cheap as a virtual host where you're sharing the same httpd with
 thousands of other sites.

And you *want* to share the same httpd with thousands of other sites?

I can relate to what you're saying. I tried the shared hosting thing 
originally, but the saying, you get what you pay for holds some truth 
here.

Maybe y'all should change the thread to Why don't shared hosting 
companies treat Python customers better? or something along those 
lines. We seem to have drifted from Princess Bride quotes and the 
merits of Lisp vs. Python ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[John Nagle]

Paul Rubin wrote:
 Brian Adkins [EMAIL PROTECTED] writes:
 
With prices of dedicated servers and virtual private servers so cheap,
why would anyone get a hosting account without root access? 
 
 Because it turns you into a sysadmin instead of letting specialists
 handle all the OS stuff so you can concentrate on your application.

Exactly.  I want to outsource these headaches to someone who's
doing it for a thousand servers and has a standardized just works
configuration that's Python-friendly.  It's inefficient to work
through all these issues for a single server.  I have better things
to do with my time.

When starting out with this project, I'd made the assumption that
Python was a stable, working, well-supported technology, like Perl
hosting.  It isn't.

It's really amazing how stable Perl hosting is.  I have a site,
downside.com, that's been running a Perl application since 2000,
with essentially no attention since 2002.  It's been migrated to new
servers twice by the hosting provider, without my having had to change
anything.  Or even do anything.  It's talking to a MySQL database,
going out and retrieving files from the SEC, parsing complex documents,
gettting a feed from NASDAQ, responding to queries, and doing
quite a bit of work.  When developing that, I had no serious problems with Perl.

Python, on the other hand, is uphill all the way.  Constant trouble
with version issues, especially with C components called from Python.
MySQLdb, M2Crypto, SSL - they all have platform/version
incompatibility problems.  I just spent three days making M2Crypto
work on a new Linux server with a different Red Hat version.
Neither Python's packaging tools nor the platform's packaging
tools deal adequately with these issues.

The language is fine.  It's those weakly-supported packages out
there in the cold that are the problem.  (I definitely agree with
Guido that SWIG is a bad idea.  I've been combing through the 24,000
lines of C generated by SWIG for M2Crypto, figuring out the compile
errors and what caused them.  This is neither fun nor desirable.)

I get the feeling that Python isn't used much for general web hosting
any more.  Only about two messages per month on this newsgroup mention
a hosting-related issue.

One wonders how many people try and give up.

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Brian Adkins]

John Nagle wrote:
 Paul Rubin wrote:
 Brian Adkins [EMAIL PROTECTED] writes:

 With prices of dedicated servers and virtual private servers so cheap,
 why would anyone get a hosting account without root access? 

 Because it turns you into a sysadmin instead of letting specialists
 handle all the OS stuff so you can concentrate on your application.
 
Exactly.  I want to outsource these headaches to someone who's
 doing it for a thousand servers and has a standardized just works
 configuration that's Python-friendly.  It's inefficient to work
 through all these issues for a single server.  I have better things
 to do with my time.
 
When starting out with this project, I'd made the assumption that
 Python was a stable, working, well-supported technology, like Perl
 hosting.  It isn't.
 
It's really amazing how stable Perl hosting is.  I have a site,
 downside.com, that's been running a Perl application since 2000,
 with essentially no attention since 2002.  It's been migrated to new
 servers twice by the hosting provider, without my having had to change
 anything.  Or even do anything.  It's talking to a MySQL database,
 going out and retrieving files from the SEC, parsing complex documents,
 gettting a feed from NASDAQ, responding to queries, and doing
 quite a bit of work.  When developing that, I had no serious problems 
 with Perl.

This may sound like I'm baiting you, but it's a sincere question. If 
your experience with Perl was so good, why did you decide to pursue 
Python? Trouble free hosting and no problems in development - sounds 
like it worked out well for you.

I do think that hosting for the masses is geared toward PHP, Perl, 
.NET, etc.

I primarily develop in Ruby on Rails (I'm here 'cause the original 
thread was posted to c.l.p and c.l.l) and I admit that trying that in a 
shared hosting environment will probably lead to frustration, but once I 
bit the bullet and got a VPS, and later a dedicated server, it was 
smooth sailing, and the performance is *so* much better.

A bit of a learning curve getting Apache, Mongrel, MySQL, etc. up and 
running (which was a fixed amount of time), then it just runs. In my 
case, the productivity gains over my previous environment 
(Java/Spring/Hibernate) was enough to justify a little pain for long 
term gains. Switching from the VPS to the dedicated server with a 
different company was easy because I already had the recipe to get a 
server setup.

 
Python, on the other hand, is uphill all the way.  Constant trouble
 with version issues, especially with C components called from Python.
 MySQLdb, M2Crypto, SSL - they all have platform/version
 incompatibility problems.  I just spent three days making M2Crypto
 work on a new Linux server with a different Red Hat version.
 Neither Python's packaging tools nor the platform's packaging
 tools deal adequately with these issues.

Now I understand your original post a bit better. Sounds like you've had 
a fair amount of frustration.

The language is fine.  It's those weakly-supported packages out
 there in the cold that are the problem.  (I definitely agree with
 Guido that SWIG is a bad idea.  I've been combing through the 24,000
 lines of C generated by SWIG for M2Crypto, figuring out the compile
 errors and what caused them.  This is neither fun nor desirable.)
 
I get the feeling that Python isn't used much for general web hosting
 any more.  Only about two messages per month on this newsgroup mention
 a hosting-related issue.

It could be that the web folks are concentrated elsewhere - maybe a 
TurboGears or Django forum? Are you just using Python with CGI, or with 
a web framework? If the latter, I expect the framework folks could be 
quite helpful.

 
One wonders how many people try and give up.
 
 John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

John Nagle wrote:
 Brian Adkins wrote:
 
 John Nagle wrote:
 
 
 If you want to restart a debate, please go back and reply to some 
 serious post in the thread - don't hijack mine for your own evil 
 purposes and cut out the good parts - did you even see the movie?
 
 
If you want to post jokes...

fer chrissakes, it was the OP of means what you think it means who was 
obviously doing Princess Bride and being reasonably funny, Brian just 
missed that it was deliberate.

, try ...

comp.lang.lisp. All the SBCL bug reports are starting to drag down 
the mood of this NG.

kt

-- 
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
   -- Elwood P. Dowd

In this world, you must be oh so smart or oh so pleasant.
   -- Elwood's Mom
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Brian Adkins [EMAIL PROTECTED] writes:
 This may sound like I'm baiting you, but it's a sincere question. If
 your experience with Perl was so good, why did you decide to pursue
 Python? Trouble free hosting and no problems in development - sounds
 like it worked out well for you.

Er, because the Perl language itself is up there with Vogon poetry in
bletcherousness?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Brian Adkins]

Ken Tilton wrote:
 John Nagle wrote:
 Brian Adkins wrote:
 John Nagle wrote:
 If you want to restart a debate, please go back and reply to some 
 serious post in the thread - don't hijack mine for your own evil 
 purposes and cut out the good parts - did you even see the movie?


If you want to post jokes...
 
 fer chrissakes, it was the OP of means what you think it means who was 
 obviously doing Princess Bride and being reasonably funny,

Turns out John is having quite a tough time with Python web hosting (the 
thread has split off to a c.l.p only fork), so I'm going to cut him some 
slack. Maybe with some lovin' we can woo him over to c.l.l ;)

 Brian just 
 missed that it was deliberate.

D'oh!

 , try ...
 
 comp.lang.lisp. All the SBCL bug reports are starting to drag down 
 the mood of this NG.
 
 kt
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Aahz]

In article [EMAIL PROTECTED],
Ant [EMAIL PROTECTED] wrote:

So far? After a bit of pain getting started and finding decent docs
(while waiting for the books to arrive) I've found the language quite
easy to use. I haven't got into closures or macros yet - I need to get
more familiar with the basics first, but first impressions are
favorable. It seems that there is nothing conceptually in Python that I
can't reasonably easily do in Lisp, but the Python syntax is much more
straightforward for most of the basics I think (such as dictionaries,
sets, list comprehensions etc), and the function/naming conventions for
the core language is much clearer and more obvious than in Lisp.

Just remember: today is the car of the cdr of your life.

Once upon a time, I was working at a company that was a commercialized
MIT Lisp project rewritten in C.  One day I was amused to discover that
buried deep in the code were a pair of functions, car() and cdr()...
-- 
Aahz ([EMAIL PROTECTED])   * http://www.pythoncraft.com/

Plus ca change, plus c'est la meme chose.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Ant]

Hi all,

On Dec 28 2006, 4:51 pm, Paddy3118 [EMAIL PROTECTED] wrote:
 This month there was/is a 1000+ long thread called:
  merits of Lisp vs Python
 In comp.lang.lisp.

 If you followed even parts of the thread, AND previously
 used only one of the languages AND (and this is the
 crucial bit), were persuaded to have a more positive view
 of the other language;

I sort of fall into this category. I'm a Java developer by trade, but
use Python for all of my non-work related projects, and any scripting I
need at work. I hadn't looked at Lisp.

I've been tempted a few times to look more into Lisp, especially after
reading some of Paul Graham's stuff which has a strong bias toward
Lisp.

The thread gave me a kick start into looking into Lisp more deeply, and
over the Christmas break I downloaded CLisp and ordered a couple of
Lisp books. There were no arguments that persuaded me particularly -
more curiosity about a few of the concepts that were bandied about:

a) Closures - and what they give you that Python co-routines don't.
b) Macros - how they can be used, and what advantages they give you.

They were the real persuasion points for me.

So far? After a bit of pain getting started and finding decent docs
(while waiting for the books to arrive) I've found the language quite
easy to use. I haven't got into closures or macros yet - I need to get
more familiar with the basics first, but first impressions are
favorable. It seems that there is nothing conceptually in Python that I
can't reasonably easily do in Lisp, but the Python syntax is much more
straightforward for most of the basics I think (such as dictionaries,
sets, list comprehensions etc), and the function/naming conventions for
the core language is much clearer and more obvious than in Lisp.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Lawrence D'Oliveiro]

In message [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:

 [3] I thought it was particularly cool how Tcl could bolt on a class
 based object oriented system as a library.  The word class isn't
 built into the language, but that kind of evaluator lets you add it.

I have written about two notrivial scripts in Tcl. I don't think I will ever
bother to write another, particularly since I now know Python. Dealing with
arrays is an absolute pain, because the language doesn't have references
and arrays as first-class objects.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Lawrence D'Oliveiro]

In message [EMAIL PROTECTED], Paul
Hummer wrote:

 I learned PHP for ease of web application development ...

PHP is great for easily developing _insecure_ web applications. But if you
want them not to leak like a sieve, things get a bit more complicated.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Paddy]

Carl Banks wrote:
 If you were so keen on avoiding a flame war, the first thing you should
 have done is to not cross-post this.

I want to cover Pythonistas looking at Lisp and Lispers looking at
Python because of the thread. The cross posting is not as flame bait.

- Paddy.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Aahz]

[x-post removed]

In article [EMAIL PROTECTED],
Paddy [EMAIL PROTECTED] wrote:
Carl Banks wrote:

 If you were so keen on avoiding a flame war, the first thing you should
 have done is to not cross-post this.

I want to cover Pythonistas looking at Lisp and Lispers looking at
Python because of the thread. The cross posting is not as flame bait.

If a Lisper is looking at Python, zie will be reading c.l.py, no?
-- 
Aahz ([EMAIL PROTECTED])   * http://www.pythoncraft.com/

I support family values -- Addams family values --www.nancybuttons.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Kaz Kylheku]

Paddy wrote:
 Carl Banks wrote:
  If you were so keen on avoiding a flame war, the first thing you should
  have done is to not cross-post this.

 I want to cover Pythonistas looking at Lisp and Lispers looking at

That's already covered in the orginal thread. Same two newsgroups, same
crowd of people. What's the difference?

Keep it in the original thread where uninterested people can continue
to ignore it.

 Python because of the thread. The cross posting is not as flame bait.

You're re-starting the same thread under a new root article, thereby
evading kill filters set up on the original thread.

In halfway decent newsreaders, people can killfile by thread, whereby
all articles associated with the same ancestral root article are
removed.

It's very bad practice to re-introduce continuations of long flamebait
threads under different thread identities.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Carl Banks]

Paddy wrote:
 Carl Banks wrote:
  If you were so keen on avoiding a flame war, the first thing you should
  have done is to not cross-post this.

 I want to cover Pythonistas looking at Lisp and Lispers looking at
 Python because of the thread. The cross posting is not as flame bait.

Then post a separate message to each group.  If you expect everyone on
Usenet to obey your command to reply with only what you want them to
reply with, you're a sad naive fool.


Carl Banks

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Steven Haflich]

Ray wrote:
 Can one really survive knowing just
 one language these days, anyway? 

いいえ！ 違います。
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Kaz Kylheku]

Steven Haflich wrote:
 Ray wrote:
  Can one really survive knowing just
  one language these days, anyway?

 いいえ！ 違います。

iie! chigaimas.

No, I beg to differ!

(Hey, I'm in right the middle of preparing my Kanji-drilling Lisp
program for distribution).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[xscottg]

Paddy3118 wrote:
 This month there was/is a 1000+ long thread called:
  merits of Lisp vs Python
 In comp.lang.lisp.

 If you followed even parts of the thread, AND previously
 used only one of the languages AND (and this is the
 crucial bit), were persuaded to have a more positive view
 of the other language; (deep breath, this is a long, as
 well as grammatically incorrect sentence), THEN WHY NOT
 POST ON WHAT ARGUMENTS PERSUADED YOU.


I fail two thirds of your requirements - at least now.  However,
several years ago, I knew Python and was only passingly familiar with
Lisp.  To me, at that time, Lisp was a language where the
compiler/interpreter writers were too lazy to write a real parser. I
object to doing things that computers can do [1].

I wasn't completely happy with Python though.  It does threads poorly
(no concurrency unless you release the GIL in a C extension).  The
buffer protocol has issues (particularly if you release the GIL) [2].
The Numpy stuff is bogged down with it's own backward compatible
history.  Tkinter leaks memory if you're not careful with it.  Adding a
C extension is non-trivial and takes your application from being a
collection of scripts to a distutils driven thing.  These are real
issues that I still bump my head on (because I still use Python a lot
of the time).  For those reasons, I'm still searching for a better
language for my needs.

Anyway, at that time, I saw an article about adding Hygienic Macros to
Python.  The term caught my attention, and it was shot down in the
Python world.  Of course, malcontent that I am, I had to go find out
what that was about.  I had already seen how in Tcl you could create
new constructs. [3]  Turns out Scheme and Common Lisp take that idea to
a new and higher place.

I found out the reason Lispers [4] stuck with their lazily written
parsers is that in exchange for infix operators, they can pretty much
assimilate any other language.  Here is an easily readable piece of
Python:

def doit(n):
   for i in xrange(n):
  print i

With very little effort, here it is in Scheme:

(def doit(n)
   (for i in (xrange n)
  (print i)))

Don't any other Pythonistas find that interesting?  Scheme could suck
in all of Python's beloved semantics with an incredibly similar syntax
in a couple days. [5]  It was an interesting revelation to me.  Then if
you wanted to add new features (Python 2.5 with for example), you
could do it yourself.  Moreover, you could steal good features from
other languages too.

The point to all of this is that the cross pollination is arguably a
good thing. [6]  If the Schemer's had stuck in their camp, I would
never had known that they had something worth looking at.  This is the
same way that I was happily using Perl in college, and some Perl/Python
exchange got me to look at Python.


 OTHERWISE LET THIS POST WITHER AND DIE ALONE.

It will die on it's own.  Add it to your killfile, ignore it in Google
Groups whatever.  More bandwidth was wasted by Paris Hilton and Britney
Spears than in this winding thread...

Cheers.



[1] A quote from Olin Shivers, and apparently he likes Lisp.  That
struck me as ironic at first.

[2] Interestingly, Jython handles threads and buffers much better
because it's built on a virtual machine that considers those important.
 Of course with Jython, you have to embrace the rest of the Java
environment...

[3] I thought it was particularly cool how Tcl could bolt on a class
based object oriented system as a library.  The word class isn't
built into the language, but that kind of evaluator lets you add it.

[4] I don't consider myself a Lisper or Schemer.  I'm just exploring
the programming language space trying to learn new ideas.

[5] Incidently, I haven't found the version of Scheme that gives me
concurrent threads, efficient buffers, C FFI, and numeric arrays the
way I want, but I'm still looking.

[6] Kenny Tilton pointed that out several times in the other thread.
There are many more lurkers looking and learning than posters posting.

-- 
http://mail.python.org/mailman/listinfo/python-list

Anyone persuaded by merits of Lisp vs Python?

[Paddy3118]

This month there was/is a 1000+ long thread called:
 merits of Lisp vs Python
In comp.lang.lisp.

If you followed even parts of the thread, AND previously
used only one of the languages AND (and this is the
crucial bit), were persuaded to have a more positive view
of the other language; (deep breath, this is a long, as
well as grammatically incorrect sentence), THEN WHY NOT
POST ON WHAT ARGUMENTS PERSUADED YOU.

OTHERWISE LET THIS POST WITHER AND DIE ALONE.

(I suspect this thread to be very short - even the
original poster seems to have given up on the day he
started the thread).

- Paddy.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Ray]

Paddy3118 wrote:
 This month there was/is a 1000+ long thread called:
  merits of Lisp vs Python
 In comp.lang.lisp.

snip

 (I suspect this thread to be very short - even the
 original poster seems to have given up on the day he
 started the thread).

I use both. And Java, and C++ too. Can one really survive knowing just
one language these days, anyway? 

 
 - Paddy.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Paul Hummer]

I am rather annoyed at the apples vs. oranges arguments I frequently
see on Reddit and the like.  I picked up python last summer after going
through a very messy breakup (it seemed like a good thing to do with all
the alone time).  Anyway, ever since I started writing python, I've been
bugged by a apples vs. oranges coworker to learn Lisp, because they
are very similar.  So at the beginning of this thread, I was reminded
that I should go check it out.

That's all it did for me.  It reminded me to do something I was planning
on doing myself anyway.  Lisp vs. Python?  How 'bout Haskell vs. Java,
PBASIC vs. C++, and while we're at it, SmallTalk vs. Assembler!
 This month there was/is a 1000+ long thread called:
  merits of Lisp vs Python
 In comp.lang.lisp.
snip

 I use both. And Java, and C++ too. Can one really survive knowing just
 one language these days, anyway? 

 

I agree with this entirely.  I started learning PBASIC to work with a
microcontroller.  I learned Java for portability.  I learned PHP for
ease of web application development (I've been largely unimpressed with
the python frameworks...but it's also lack of experience).  I use python
for utilities I need, and Lisp is great for some of the functional needs
I have (see Mosquito-Lisp and the MOSREF project), and I can see use in
it.  But how many web applications have you seen written in Assembler? 
How many OS kernels written in Lisp?

I bought my girlfriend an art desk for Christmas.  I didn't use a
freakin' hammer to drive the screws.  Wrong tool for the job.  Each
language has its ups and downs.  Call me the Martin Luther King of
programming languages, but I have a dream.  We can no sooner say one
language is better than another than say white people are superior to
black people.  We're equal in our own respects.

Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone persuaded by merits of Lisp vs Python?

[Carl Banks]

Paddy3118 wrote:
 This month there was/is a 1000+ long thread called:
  merits of Lisp vs Python
 In comp.lang.lisp.

 If you followed even parts of the thread, AND previously
 used only one of the languages AND (and this is the
 crucial bit), were persuaded to have a more positive view
 of the other language; (deep breath, this is a long, as
 well as grammatically incorrect sentence), THEN WHY NOT
 POST ON WHAT ARGUMENTS PERSUADED YOU.

 OTHERWISE LET THIS POST WITHER AND DIE ALONE.

If you were so keen on avoiding a flame war, the first thing you should
have done is to not cross-post this.


Carl Banks

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Lars Rune Nøstdal]

On Sat, 23 Dec 2006 12:38:30 -0800, Fuzzyman wrote:

 
 Lars Rune Nøstdal wrote:
 On Fri, 08 Dec 2006 03:07:09 -0800, Mark Tarver wrote:

  How do you compare Python to Lisp?  What specific advantages do you
  think that one has over the other?
 
  Note I'm not a Python person and I have no axes to grind here.  This is
  just a question for my general education.
 
  Mark

 Kill this frakkin thread; Lisp rules -- while Python is boring (but better
 than many other alternatives). E.O.F.

 
 Perhaps only with the addendum that although 'Lisp roolz', no-one uses
 for anything of relevance anymore and it is continuing it's geriatric
 decline into obscurity. ;-)

Screw it; I'll die a non-professional programmer if I have to. Meanwhile
ridiculing and scorning all the fools using inferior languages. *hah!*

If I can't do what I love when it comes to programming I'd rather have a
shitty non-programming job that enables me to instantly forget what I've
been doing while at work as soon as I'm done for the day.

My trade -- my tools. :}

-- 
Lars Rune Nøstdal
http://nostdal.org/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Juan R.]

Fuzzyman ha escrito:

 Perhaps only with the addendum that although 'Lisp roolz', no-one uses
 for anything of relevance anymore and it is continuing it's geriatric
 decline into obscurity. ;-)

I do not think that i cannot agree with the contrary of this but i do
not think the contrary neither.

I am being said that LISP is being actively pursued by a number of
joung hackers as Graham and Tilton. Do not believe?

Ken Tilton has noticed that Dalai Lama has becomed interested in LISP
also.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Fuzzyman]

Lars Rune Nøstdal wrote:
 On Fri, 08 Dec 2006 03:07:09 -0800, Mark Tarver wrote:

  How do you compare Python to Lisp?  What specific advantages do you
  think that one has over the other?
 
  Note I'm not a Python person and I have no axes to grind here.  This is
  just a question for my general education.
 
  Mark

 Kill this frakkin thread; Lisp rules -- while Python is boring (but better
 than many other alternatives). E.O.F.


Perhaps only with the addendum that although 'Lisp roolz', no-one uses
for anything of relevance anymore and it is continuing it's geriatric
decline into obscurity. ;-)

Python is dull, except to the ever increasing group of programmers who
use it for practical purposes.

Hmm... a fitting. EOF.

Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml

 -- 
 Lars Rune Nøstdal
 http://nostdal.org/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[defcon8]

All of you are nazis!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Fuzzyman]

defcon8 wrote:
 All of you are nazis!

Hmmm... that might work. :-)

Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Lars Rune Nøstdal]

On Fri, 08 Dec 2006 03:07:09 -0800, Mark Tarver wrote:

 How do you compare Python to Lisp?  What specific advantages do you
 think that one has over the other?
 
 Note I'm not a Python person and I have no axes to grind here.  This is
 just a question for my general education.
 
 Mark

Kill this frakkin thread; Lisp rules -- while Python is boring (but better
than many other alternatives). E.O.F.

-- 
Lars Rune Nøstdal
http://nostdal.org/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Anders J. Munch]

Rob Thorpe wrote:
 Anders J. Munch wrote:
 Let u(t) be the actual memory used by the program at time t.
 Let r(t) be the size of reachable memory at time t.

 Require that u(t) is a member of O(t - max{t'=t: r(t')})

 There. That wasn't so hard, was it?
 
 That's quite a clever definition actually.
 But, let's say I have a lisp machine.  It has an unusual architecture,
 it's made entirely of SRAM cells of ~9bits.  Sometimes these cells are
 used as storage, sometimes their contents represent logic circuits and
 the routing between them is configured to form them into a processor.
 Please tell me what reachable memory is ;).  (The above processor is
 not science fiction, it could easily be done with FPGAs)

Reachable memory is the set of interpreter objects (conses, closures, scopes, 
atoms and what have you) reachable from from some appropriately defined root 
set.  It can be unambiguously defined with respect to a virtual machine, with 
no 
regard to how actual implementations represent these things.

For actual memory use, a simple byte count would do fine.  If code and data are 
intermingled, just use the combined size of both of them.

If you're worried about comparing incompatible units, don't be: apples and 
oranges compare just fine under big-Oh.

- Anders
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Rob Thorpe]

Anders J. Munch wrote:
 Rob Thorpe wrote:
  Anders J. Munch wrote:
  Let u(t) be the actual memory used by the program at time t.
  Let r(t) be the size of reachable memory at time t.
 
  Require that u(t) is a member of O(t - max{t'=t: r(t')})
 
  There. That wasn't so hard, was it?
 
  That's quite a clever definition actually.
  But, let's say I have a lisp machine.  It has an unusual architecture,
  it's made entirely of SRAM cells of ~9bits.  Sometimes these cells are
  used as storage, sometimes their contents represent logic circuits and
  the routing between them is configured to form them into a processor.
  Please tell me what reachable memory is ;).  (The above processor is
  not science fiction, it could easily be done with FPGAs)

 Reachable memory is the set of interpreter objects (conses, closures, scopes,
 atoms and what have you) reachable from from some appropriately defined root
 set.  It can be unambiguously defined with respect to a virtual machine, with 
 no
 regard to how actual implementations represent these things.

Yes.

 For actual memory use, a simple byte count would do fine.  If code and data 
 are
 intermingled, just use the combined size of both of them.

Well, in my example the code, the data and the processor are
intermingled.  Still you could do it this way.  But, what would happen
for example if on a normal machine someone wrote a program that
generated lots of functions that it never used, would it have to be
detected by the GC.  This is hard to do.  The solution is probably to
define the root set only in terms of data.

 If you're worried about comparing incompatible units, don't be: apples and
 oranges compare just fine under big-Oh.

Yes. Thank you for comprehensively out-arguing me.

I'll give one last reason why it may not be a good thing to define:
reference counting.  Some people want to use refcounts, and believe
that under certain circumstances they provide better performance than
GC.  I don't know if they're right, I suspect they are for some limited
circumstances.  A normal ref-count system can't be gauranteed to have
no memory holes introduced by loops in the data.  But, if the
programmer causes no loops to come into being then he/she is safe.  An
implementation that used refcounting might not be of much general use,
but for specific purposes, embedded programming for example, it might
be useful.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Anders J. Munch]

jayessay wrote:
   Please note: GC is not part of CL's definition.  It is likely not part
 of any Lisp's definition (for reasons that should be obvious), and for
 the same reasons likely not part of any language's definition.  

Really?  So how do you write a portable program in CL, that is to run 
for unbounded lengths of time?

- Anders

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Rob Thorpe]

Anders J. Munch wrote:
 jayessay wrote:
Please note: GC is not part of CL's definition.  It is likely not part
  of any Lisp's definition (for reasons that should be obvious), and for
  the same reasons likely not part of any language's definition.

 Really?  So how do you write a portable program in CL, that is to run
 for unbounded lengths of time?

You can't.

The thing about the spec not defining GC is almost a bit of humour.
No-one would use an implementation with no GC.

The issue with specifying it is: How would you do it?  The memory used
by a program is an aspect of the language implementation and the system
the program is running on, so how can it be defined in a useful way?

You could say for example Storage allocated for an object is released
when the object is no longer visible and memory usage is high.  But
how do you define how high memory usage should be?  You could say when
memory is almost exhausted, even that is difficult to define.  Then you
could have the situation where someone creates a lisp compiler than
emits FPGA netlists, how do you check something like this?

None of this would be in the spirit of the spec, which doesn't even
define memory AFAIK.  The spec deals entirely in matters of the
language and it's appearance to the programmer.  For what it's worth I
think the C spec is the same, and says nothing about actual memory
usage.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[[EMAIL PROTECTED]]

Anders J. Munch wrote:
 jayessay wrote:
Please note: GC is not part of CL's definition.  It is likely not part
  of any Lisp's definition (for reasons that should be obvious), and for
  the same reasons likely not part of any language's definition.

 Really?  So how do you write a portable program in CL, that is to run
 for unbounded lengths of time?

 - Anders

Write it, and depend on the implementation to do its job well, and
complain to the implementors if it doesn't.

How do you write a portable program in C that is to run for unbounded
lengths of time? Even if you religiously call free() on every
malloc()'d block, you could eventually fragment memory enough that the
allocator might eventually fail. You can exceed the VM capacity. The OS
could decide to crash periodically. The power supply could fail, the
sun could progress to the red giant phase...

The real answer is that these are not issues for the language
definition, but for the implementor.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Bourguignon]

Rob Thorpe [EMAIL PROTECTED] writes:

 Anders J. Munch wrote:
 jayessay wrote:
Please note: GC is not part of CL's definition.  It is likely not part
  of any Lisp's definition (for reasons that should be obvious), and for
  the same reasons likely not part of any language's definition.

 Really?  So how do you write a portable program in CL, that is to run
 for unbounded lengths of time?

 You can't.

You can.  Just use reversible operations.

Or use pre-allocated objects. Yes, that means that you implement your
own memory management or garbage collector, but this would be portable.

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality
 -- on a wall many years ago in Oxford.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Anders J. Munch]

Rob Thorpe wrote:
  Anders J. Munch wrote:
  Really?  So how do you write a portable program in CL, that is to
  run for unbounded lengths of time?
 
  You can't.
 
  The thing about the spec not defining GC is almost a bit of humour.
  No-one would use an implementation with no GC.
 
  The issue with specifying it is: How would you do it?  The memory
  used by a program is an aspect of the language implementation and
  the system the program is running on, so how can it be defined in a
  useful way?

Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.

Require that u(t) is a member of O(t - max{t'=t: r(t')})

There. That wasn't so hard, was it?

- Anders
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Rob Thorpe]

Anders J. Munch wrote:
 Rob Thorpe wrote:
   Anders J. Munch wrote:
   Really?  So how do you write a portable program in CL, that is to
   run for unbounded lengths of time?
  
   You can't.
  
   The thing about the spec not defining GC is almost a bit of humour.
   No-one would use an implementation with no GC.
  
   The issue with specifying it is: How would you do it?  The memory
   used by a program is an aspect of the language implementation and
   the system the program is running on, so how can it be defined in a
   useful way?

 Let u(t) be the actual memory used by the program at time t.
 Let r(t) be the size of reachable memory at time t.

 Require that u(t) is a member of O(t - max{t'=t: r(t')})

 There. That wasn't so hard, was it?

That's quite a clever definition actually.
But, let's say I have a lisp machine.  It has an unusual architecture,
it's made entirely of SRAM cells of ~9bits.  Sometimes these cells are
used as storage, sometimes their contents represent logic circuits and
the routing between them is configured to form them into a processor.
Please tell me what reachable memory is ;).  (The above processor is
not science fiction, it could easily be done with FPGAs)

I suppose a solution would be:-

If the lisp implementation runs on a fixed processor that has separate
storage then ...

Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.
...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[jayessay]

Anders J. Munch [EMAIL PROTECTED] writes:

 jayessay wrote:
Please note: GC is not part of CL's definition.  It is likely not part
  of any Lisp's definition (for reasons that should be obvious), and for
  the same reasons likely not part of any language's definition.
 
 Really?

Really.


 So how do you write a portable program in CL, that is to run
 for unbounded lengths of time?

Make it non-consing (like for any such program in any language).  Of
course, this won't guarantee success as the implementation or OS or
... may leak or other wise cons memory even if your program doesn't.


I'm surprised there are people out there that find this interesting
let alone surprising.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

[EMAIL PROTECTED] wrote:
 Come on; you guys can't just leave this at 999 posts!
 

Funny you should whine, i was just getting ready to sign off with:

I noticed while singing the praises of auto-indentation that there was a 
shortcoming in The Greatest Feature Known to Editing source code, which 
is the ability to copy an arbitrary block of code (say, a case statement 
in the else branch of an if statement in a loop) with a single 
control-click of the mouse, viz, that I still had to reindent if it was 
a multiline statement. The first line of course landed exactly where I 
clicked so that was fine, but other lines in the block were retaining 
the indentation extant at the time of the click.

A few glasses of...cough a few hours ago I dashed off an RFE to Franz 
tech support apologizing for a trivial matter but wondering if it might 
not be just a line or two, and lawdy-it-must-be-xmas a glass later back 
came a patch I am just wallowing in.

interestingly, the techie happens not to have been a user of 
control-click, probably a hardcore keyboard guy who never touches the 
mouse. I started programming GUIs on a Mac 512, didn't /have/ a keyboard.***

And now the punch line: spare me the oh gosh reindentation is so easy 
dodge. So is a manual control-shift-p to auto-reindent after an ungainly 
paste, but this is definitely one of those deals where we don't notice 
until we stop hitting ourselves with that hammer.

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

BLISS programs Just Work.
Never revisited, they
Never get refined.
- Warnock's Explanation of Large Programs
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jon Harrop]

Rob Thorpe wrote:
 Once you can do the above then you can phrase programs entirely in
 terms of composition of functions, which is what functional programming
 is about.

There are many aspects to functional programming. Some languages (like Lisp
and Python) are very impure and hardly encourage functional programming.
Other languages (like OCaml, SML, F# and Scheme) are impure but make
functional programming easy (e.g. higher-order functions, currying,
continuation passing style are all concise and statically checked). Some
languages (like Haskell) are purely functional, so everything must be
immutable.

 Getting good performance though is problematic without being able to
 evaluate parts at compile time.  This is why almost all functional
 languages provide that feature in some form.

Actually the languages that don't provide compile-time execution (OCaml, SML
and F#) are typically much faster than those that do (Lisp, Scheme, Dylan).

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

This is not a response to any particular post, but rather to the
general argument that macros are not as useful as we Lispers claim.

Here is a fairly complete GUI RSS reader in 90 lines of Lisp (the GUI
code itself is 90 lines, but it makes use of some RSS reading/writing
code I had laying around and two public CL libraries: s-xml and
trivial-http).  The code employs a handy macro called DEFINE-INTERFACE
that LispWorks provides with their CAPI toolkit.  I hope this will be
useful as an illustration of what macros (and Lisp in general) can do,
and as an example of what a moderately practical CL application looks
like.

The application presents a list of feeds and allows the user to add
new feeds or to delete existing feeds.  The feeds are presented as a
tree, with each channel acting as a parent to several items.  The user
can refresh all of the feeds with the Refresh All button.
Double-clicking on any item will display its description field (as in
the screenshot).  Each channel shows the number of unread articles and
the articles are arranged so that the unseen articles appear before
the articles that have already been read.

Important things to note:

 1) the DEFINE-INTERFACE syntax closely resembles the syntax of the
standard DEFCLASS macro, so newcomers have a basic idea of what
DEFINE-INTERFACE is going to do

 2) the expansion ( http://galoot.org/~bill/code/rss-reader/expanded.lisp )
of just the DEFINE-INTERFACE is quite involved, a testament to
the amount of work the macro saves

 3) much of the GUI can be specified declaratively because of the
DEFINE-INTERFACE syntactic abstraction, and this declarativeness
makes it very easy for maintainers to understand what's going on

 4) even without knowing the implementation of DEFINE-INTERFACE and
even without prior experience with it, one can make good guesses
about what it does

 5) the GUI code is stunningly concise

Here is the GUI code alone:  

   http://galoot.org/~bill/code/rss-reader/rss-gui.lisp 

Here is a screenshot of the application in development:

   http://galoot.org/~bill/code/rss-reader/development.png 

and two screenshots of the application in use

   http://galoot.org/~bill/code/rss-reader/in%20action.png 
   http://galoot.org/~bill/code/rss-reader/in%20action%202.png 

Here are the support files:

   http://galoot.org/~bill/code/rss-reader/ 

Here is an OS X universal binary (run at your own risk; I've only
done very basic testing):

   http://galoot.org/~bill/code/rss-reader/BarebonesRSS.app.tar.gz 

Enjoy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bruno Desthuilliers]

Paul Rubin a écrit :
 Rob Thorpe [EMAIL PROTECTED] writes:
 
Once you can do the above then you can phrase programs entirely in
terms of composition of functions, which is what functional programming
is about.

Getting good performance though is problematic without being able to
evaluate parts at compile time.  This is why almost all functional
languages provide that feature in some form.
 
 
 I'm not aware of any special features in Haskell for that purpose, or
 in Scheme until maybe with the more recent versions.  I thought the
 main feature needed for functional programming besides first-class
 functions was guaranteed tail call optimization.

Strictly speaking, only first-class functions are required, and 
tail-recursion optimisation is only an implentation detail. Now it's 
obvious that when it comes to real-life-size programs, this is a *very* 
important detail !-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bruno Desthuilliers]

Mathias Panzenboeck a écrit :
 Bruno Desthuilliers wrote:
 
Mathias Panzenboeck a écrit :

Rob Thorpe wrote:


Mathias Panzenboeck wrote:


Mark Tarver wrote:


How do you compare Python to Lisp?  What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. 
This is
just a question for my general education.

Mark


I do not know much about Lisp. What I know is:
Python is a imperative, object oriented dynamic language with duck
typing,

Yes, but Python also supports the functional style to some extent.



I currently visit a course about functional programming at the
university of technology vienna:
python implements only a small subset of things needed to be called a
functional language (list
comprehension).

Python has functions as first-class objects (you can pass functions as
arguments to functions, return functions from functions, and bind
functions to identifiers), and that's the only thing you need to use a
functional approach.
 
 
 You mean like function pointers in C and C++? 

Absolutely not. Python's functions are normal Python objects, instances 
of the (builtin) class 'function'. FWIW, any object implementing the 
__call__ method can behave as a function.

Python functions can take functions as arguments, and return functions - 
this is how 'decorators' work.

 I think this should be possible in assembler, too.
 I thought functional languages have to be declarative?

For what definition of 'declarative' ?

 The boost C++ library has even lambdas!

So does Python - even if in a restricted way.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bruno Desthuilliers]

Kaz Kylheku a écrit :
 Bruno Desthuilliers wrote:
 
André Thieme a écrit :

Bruno Desthuilliers schrieb:


(snip)

Both are highly dynamic. Neither are declarative.


Well, Lisp does support some declarative features in the ansi standard.

If you go that way, there are declarative stuff in Python too... But
neither Lisp nor Python are close to, say, SQL.
 
 
 False. Common Lisp can be made to support SQL syntax.
 
And Python can be made to support something really close to it, cf 
SQLAlchemy. And Python has list comprehensions, which are mostly on the 
declarative side (ie : what, not how):

[x for x in range(100) if x % 2 == 0]

Etc, etc, etc...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[André Thieme]

Paul Rubin schrieb:

 GC also gets rid of programs.  There are programs you can write in C
 but not in Lisp, like device drivers that poke specific machine
 addresses.

You are talking about an ANSI Common Lisp implementation.
But nothing stops a vendor to deliver its CL with libs that support
the writing of device drivers.
When Naughty Dog programmed games for the Play Station 2 the used
Common Lisp to develop a Lisp called GOAL (Game Oriented Assembly
Lisp) that was specialized for writing PS2 games.


André
-- 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Rob Warnock]

[EMAIL PROTECTED] wrote:
+---
| Paul Rubin wrote:
|  [...]  There are programs you can write in C but not in Lisp,
|  like device drivers that poke specific machine addresses.
| 
| I should assume you meant Common Lisp, but there isn't really any
| reason you couldn't
|  (poke destination (peek source))
| in some version of Lisp that was meant for writing device drivers
| (perhaps under a Lisp machine or something).
+---

I do this kind of thing *every day* in CMUCL!! It's my primary
user-mode hardware debugging tool. Here's a typical utility function:

;;; Used for things like polling for a done flag.
;;; BUG: Assumes contents of ADDR will change within fixnum polls.
(defun spin-until-change (addr)
  (declare (optimize (speed 3) (debug 0) (safety 0)))
  (loop with v0 of-type (unsigned-byte 32) = (r32 addr)
with counts fixnum = 0
while (= v0 (r32 addr))
 do (setf counts (the fixnum (1+ counts)))
 finally (return counts)))

+---
| SIOD actually has (%%% memref address) for peek.
+---

CMUCL has SYSTEM:SAP-REF-{8,16,32} and SETFs of same. The R32
above is just my convenience wrapper around SYSTEM:SAP-REF-32:

(declaim (inline r32))

(defun r32 (addr)
  (declare (optimize (speed 3) (debug 0) (safety 0)))
  (system:sap-ref-32 (system:int-sap addr) 0))

(defun w32 (addr rest values)
  (declare (optimize (speed 3) (debug 0) (safety 0)))
  (loop for i fixnum from 0 by 4
and v of-type (unsigned-byte 32) in values
do (setf (system:sap-ref-32 (system:int-sap addr) i) v))
  (values))

Most other Common Lisp implementations surely have something similar.


-Rob

-
Rob Warnock [EMAIL PROTECTED]
627 26th Avenue URL:http://rpw3.org/
San Mateo, CA 94403 (650)572-2607

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Bruno Desthuilliers [EMAIL PROTECTED] writes:
 Strictly speaking, only first-class functions are required, and
 tail-recursion optimisation is only an implentation detail. Now it's
 obvious that when it comes to real-life-size programs, this is a
 *very* important detail !-)

I don't buy this.  One of my favorite quotes about specifications
(http://www.sgi.com/tech/stl/drdobbs-interview.html):

Let's take an example. Consider an abstract data type stack. It's not
enough to have Push and Pop connected with the axiom wherein you push
something onto the stack and after you pop the stack you get the same
thing back. It is of paramount importance that pushing the stack is a
constant time operation regardless of the size of the stack. If I
implement the stack so that every time I push it becomes slower and
slower, no one will want to use this stack.

We need to separate the implementation from the interface but not at
the cost of totally ignoring complexity. Complexity has to be and is a
part of the unwritten contract between the module and its user. The
reason for introducing the notion of abstract data types was to allow
interchangeable software modules. You cannot have interchangeable
modules unless these modules share similar complexity behavior. If I
replace one module with another module with the same functional
behavior but with different complexity tradeoffs, the user of this
code will be unpleasantly surprised. I could tell him anything I like
about data abstraction, and he still would not want to use the
code. Complexity assertions have to be part of the interface.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[jayessay]

Paul Rubin http://[EMAIL PROTECTED] writes:

 [EMAIL PROTECTED] writes:
  I should assume you meant Common Lisp, but there isn't really any
  reason you couldn't
  
   (poke destination (peek source))
 
 That breaks the reliability of GC.  I'd say you're no longer writing
 in Lisp if you use something like that.

Please note: GC is not part of CL's definition.  It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.  So,
your point here is actually a category error...


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bruno Desthuilliers]

Paul Rubin a écrit :
 Bruno Desthuilliers [EMAIL PROTECTED] writes:
 
Strictly speaking, only first-class functions are required, and
tail-recursion optimisation is only an implentation detail. Now it's
obvious that when it comes to real-life-size programs, this is a
*very* important detail !-)
 
 
 I don't buy this. 

Fine - I'm not trying to sell it !-)

 One of my favorite quotes about specifications
 (http://www.sgi.com/tech/stl/drdobbs-interview.html):
 
(snip).

 From a purely logical POV, the fact that a stack implementation has 
constant-time access or not is totally irrelevant (real-time problems 
set aside). This doesn't mean it's not important in practice.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[greg]

Bill Atkins wrote:
 This is not a response to any particular post, but rather to the
 general argument that macros are not as useful as we Lispers claim.
 
 Here is a fairly complete GUI RSS reader in 90 lines of Lisp

For comparison, here's how something with a similar
API might be used from Python.

class RSSInterface(Interface):

   def __init__(self):
 Interface.__init__(self,
   panes = [
 TextInput('url_pane',
   title = 'Feed URL:',
   callback = 'add_feed',
   callback_type = 'interface'),
 PushButton('add',
   text = 'Add Feed',
   callback = 'add_feed',
   callback_type = 'interface'),
 PushButton('refresh',
   text = 'Refresh All',
   callback = 'refresh_feeds',
   callback_type = 'interface'),
 PushButton('delete',
   text = 'Delete Feed',
   callback = 'delete_feed',
   callback_type = 'interface'),
 TreeView('tree',
   visible_min_width = ('character', 84),
   visible_min_height = ('character', 40),
   action_callback = 'browse_item',
   callback_type = 'item_interface',
   expandp_function = lambda: True, # not sure how best to translate
   children_function = 'tree_item_children',
   print_function = 'tree_item_string')
 ],
   layouts = [
 ColumnLayout('main', ('top', 'tree')),
 RowLayout('top', ('url_pane', 'add', 'refresh', 'delete'))
 ],
   title = 'Barebones RSS Reader v1.0')
 self.channels = [
   parse_rss_from_url(url) for url in [
 'http://planet.lisp.org/rss20.xml',
 'http://feeds.theonion.com/theonion/daily']]

   def add_feed(self):
 ...

   def delete_feed(self):
 ...

   # etc.

--
Greg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Kaz Kylheku]

Paul Rubin wrote:
 Raffael Cavallaro [EMAIL PROTECTED]'espam-s'il-vous-plait-mac.com writes:
  For example, a common lisp with optional static typing on demand would
  be strictly more expressive than common lisp. But, take say, haskell;
  haskell's static typing is not optional (you can work around it, but
  you have to go out of your way to do so); haskell's pure functional
  semantics are not optional (again, workarounds possible to a limited
  extent). This requires you to conceive your problem solution (i.e.,
  program) within the framework of a particular paradigm. This lock-in
  to a particular paradigm, however powerful, is what makes any such
  language strictly less expressive than one with syntactic abstraction
  over a uniform syntax.

 Incorrect, I believe.  The above is like saying Lisp's lack of
 optional manual storage allocation and machine pointers makes Lisp
 less powerful.

That is true. By itself, that feature makes Lisp less poweful for
real-world software dev, which is why we have implementation-defined
escape hatches for that sort of thing.

 It's in fact the absence of those features that lets
 garbage collection work reliably.

This is a bad analogy to the bondage-and-discipline of purely
functional languages.

The removal for the need for manual object lifetime computation does
not cause a whole class of useful programs to be rejected.

In fact, all previously correct programs continue to work as before,
and in addition, some hitherto incorrect programs become correct.
That's an increase in power: new programs are possible without losing
the old ones.

Wheas programs can't be made to conform to the pure functional paradigm
by adjusting the semantics of some API function. Programs which don't
conform have to be rejected,

  Reliable GC gets rid of a large and
 important class of program errors and makes possible programming in a
 style that relies on it.

Right. GC gets rid of /program errors/. Pure functional programming
gets rid of /programs/.

 You can make languages more powerful by removing features as well as by 
 adding them.

Note that changing the storage liberation request from an imperative to
a hint isn't the removal of a feature. It's the /addition/ of a
feature. The new feature is that objects can still be reliably used
after the implementation was advised by the program that they are no
longer needed. Programs which do this are no longer buggy. Another new
feature is that programs can fail to advise the implementation that
some objects are no longer needed, without causing a leak, so these
programs are no longer buggy. The pool of non-buggy programs has
increased without anything being rejected.

Okay, that is not quite true, which brings me back to my very first
point. GC does (effectively) reject programs which do nasty things with
pointers. For instance, hiding pointers from being visible to GC.
However, such things can be made to coexist with GC. GC and non-GC
stuff /can/ and does, for pragmatic reasons, live in the same image.

Likewise, functional programming and imperative programming can also
coexist in the same image.

/Pure/ functional programming isn't about adding the feature of
functional programming. It's about  eliminating other features which
are not functional programming.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[jayessay]

Paul Rubin http://[EMAIL PROTECTED] writes:

 Kaz Kylheku [EMAIL PROTECTED] writes:
   Lisp just seems hopelessly old-fashioned to me these days.  A
   modernized version would be cool, but I think the more serious
   Lisp-like language designers have moved on to newer ideas.
  
  What are some of their names, and what ideas are they working on?
 
 http://caml.inria.fr
 http://www.haskell.org

Aren't these old-fashioned and boring as well?



/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jon Harrop]

Raffael Cavallaro wrote:
 On 2006-12-16 13:58:37 -0500, Jon Harrop [EMAIL PROTECTED] said:
 Why do you think that uniform syntax is necessary to provide new
 paradigms when it is equivalent to infix syntax?
 
 Because it doesn't require one to write a parser for each new syntax
 for each new paradigm.

Why not use a single, extensible parser, e.g. camlp4?

 In what way is Haskell's support for imperative programming limited?
 
 It requires one to frame everything in functional terms or to jump
 through the hoop of monads.

Can you give some example code demonstrating these hoops?

 Can you give an example of a Lisp macro that does something useful that
 you can't do in these other languages?
 
 It isn't a question of can't do in these other languages, it's a
 matter of can't do as easily in these other languages.

Yes, absolutely.

 Look at kenny 
 tilton's cells. Its a dataflow paradigm built largely of macros. It 
 goes completely against the semantics of haskell - cells is all about
 the eager evaluation of side effecting state mutation.

Perhaps that is because Cells is written in a language (Lisp) that forces
you to jump through hoops to get lazy evaluation?

The Cells project appears to deal with a graph (in the graph-theoretic
sense). There is nothing inherently side-effecting about that and the
problem that Cells is trying to solve seems to be fundamentally lazy:
update cells only when necessary.

 Could you do it 
 in haskell? Yes, in the greenspun/turing-completeness sense, but not
 nearly as easily as in common lisp, because the very paradigm - eager
 evaluation combined with side effecting state mutation - goes against
 the basic semantics of haskell.

Can you give some evidence to back that up, e.g. a program that solves a
problem like this in Haskell but is more convoluted that the Lisp?

 You'd have to jump through extra hoops 
 to build a system whose very nature contradicts two of the semantic
 foundations of haskell - laziness and absense of side effects.

What if eager impurity isn't the very nature of the problem but, rather,
is the very nature of Tilton's chosen solution?

 Then there's the issue of the new syntax. Easy to build in lisp without
 learning another language - lisp macros use lisp.

You can use Lisp macros to add some of the features found in modern FPLs.
Once you've done that, users of your modern Lisp variant must learn how to
use your macros. How is that better than learning a modern FPL directly?

 What little I've seen 
 of caml4p looks like perlesque line noise. Ultimately I think that the
 defaults of both haskell and ocaml - functional, static typing,
 non-uniform syntax - are things I don't want as defaults, but as
 options for later in the development of only certain pieces of code. I
 don't want to be required to jump through the pure-functional,
 must-use-monads-for-any-side-effects, static-type, non-uniform-syntax
 hoops to express my ideas. It makes me less flexible in dealing with
 individual parts of a program differently.

You can use tools like camlp4 to generate uniform syntax from OCaml's
syntax. You can also use the -dlambda to output OCaml's Lisp-like
intermediate representation.

Why do you think that uniform syntax like this Lisp:

(defun intersect (orig dir scene)
  (labels ((aux (lam normal scene)
 (let* ((center (sphere-center scene))
(lamt (ray-sphere orig
  dir
  center
  (sphere-radius scene
   (if (= lamt lam)
   (values lam normal)
   (etypecase scene
 (group
  (dolist (kid (group-children scene))
(setf (values lam normal)
  (aux lam normal kid)))
  (values lam normal))
 (sphere
  (values lamt (unitise
(-v (+v orig (*v lamt dir))
center)
(aux infinity zero scene)))

is better than syntax with conventional mathematical grammar, like this
equivalent OCaml:

  let rec intersect orig dir (lambda, _ as hit) (center, radius, scene) =
let lambda' = ray_sphere orig dir center radius in
if lambda' = lambda then hit else match scene with
| Sphere - lambda', unitise (orig +| lambda' *| dir -| center)
| Group scenes - List.fold_left (intersect orig dir) hit scenes

From my point of view, people started with Lisp and used its macros to add
new syntax to the language and they got Haskell and OCaml. After all,
Haskell and OCaml are more popular that any given Lisp variant with similar
features (e.g. pattern matching), AFAIK.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Raffael Cavallaro]

On 2006-12-17 07:54:28 -0500, Jon Harrop [EMAIL PROTECTED] said:

 What if eager impurity isn't the very nature of the problem but, rather,
 is the very nature of Tilton's chosen solution?

That's the whole point which you keep missing - that a programming 
language is expressive precisely to the extent that it allows you to 
express the solution in the *programmer's* chosen form, not the 
paradigm imposed by the language.

You look down your nose at cells, but if that's the way kenny conceived 
of the problem - as a graph of changing state, why should he be forced 
to reconceptualize it according to someone else's notion of programming 
correctness (be that pure functional or any other paradigm)?

By asking this question you've implicitly admitted that to solve it *as 
he thought of it* in a pure functional language would require 
reconceptualizing it (i.e., the aforementioned jumping through 
hoops). We don't want to reconceptualize everything according to a 
particular paradigm, we want the flexibility to write the solution to 
the problem in the terms we think and talk about it, not the 
procrustean bed of pure functional semantics.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Raffael Cavallaro]

On 2006-12-17 07:54:28 -0500, Jon Harrop [EMAIL PROTECTED] said:

 After all,
 Haskell and OCaml are more popular that any given Lisp variant with similar
 features (e.g. pattern matching), AFAIK.

What doublespeak!

haskell and ocaml are more popular than any lisp library that tries to 
imitate Haskell and ocaml. So what! This only speaks to the relative 
unpopularity of imitating these features of haskell and ocaml when you 
already have lisp.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jon Harrop]

Raffael Cavallaro wrote:
 On 2006-12-17 07:54:28 -0500, Jon Harrop [EMAIL PROTECTED] said:
 What if eager impurity isn't the very nature of the problem but,
 rather, is the very nature of Tilton's chosen solution?
 
 That's the whole point which you keep missing - that a programming
 language is expressive precisely to the extent that it allows you to
 express the solution in the *programmer's* chosen form, not the
 paradigm imposed by the language.

That is the ideal, yes.

In practice, different languages encourage you to use different solutions.
For example, when faced with a problem best solved using pattern matching
in Lisp, most Lisp programmers would reinvent an ad-hoc, informally
specified and bug-ridden pattern matcher of their own. Do you not think
that Lispers typically compile their high-level algorithms into low-level
Lisp constructs like COND or IF?

 You look down your nose at cells, but if that's the way kenny conceived
 of the problem - as a graph of changing state, why should he be forced
 to reconceptualize it according to someone else's notion of programming
 correctness (be that pure functional or any other paradigm)?

Kenny isn't being forced to do anything.

 By asking this question you've implicitly admitted that to solve it *as
 he thought of it* in a pure functional language would require
 reconceptualizing it (i.e., the aforementioned jumping through
 hoops).

You are saying that solving it as he solved it requires a different
solution. How does that make Lisp any different to the next language?

 We don't want to reconceptualize everything according to a 
 particular paradigm, we want the flexibility to write the solution to
 the problem in the terms we think and talk about it, not the
 procrustean bed of pure functional semantics.

Of the programming paradigms that can be implemented in Lisp, Lisp doesn't
exactly make them easy. Moreover, every time you pick a random Lisp library
off the wall to implement some feature already found in most other
languages, you fragment the already tiny user base into even fewer people.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jon Harrop]

Raffael Cavallaro wrote:
 haskell and ocaml are more popular than any lisp library that tries to
 imitate Haskell and ocaml.

Implementing pattern matching does not mean imitating Haskell or OCaml.

 This only speaks to the relative  
 unpopularity of imitating these features of haskell and ocaml when you
 already have lisp.

On the contrary, Lisp predates the features and, since their inception, most
Lisp programmers have moved on to newer languages.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Raffael Cavallaro]

On 2006-12-17 12:49:46 -0500, Jon Harrop [EMAIL PROTECTED] said:

 For example, when faced with a problem best solved using pattern matching
 in Lisp, most Lisp programmers would reinvent an ad-hoc, informally
 specified and bug-ridden pattern matcher of their own.

No, I think most of us would use an exising lisp pattern matcher, like 
cl-unification.


 
 By asking this question you've implicitly admitted that to solve it *as
 he thought of it* in a pure functional language would require
 reconceptualizing it (i.e., the aforementioned jumping through
 hoops).
 
 You are saying that solving it as he solved it requires a different
 solution. How does that make Lisp any different to the next language?

Give kenny some credit for not being a complete idiot. Cells was 
originally designed to keep UI elements in sync with an internal 
application model. The UI domain is I/O, i.e., a side effect. To do 
this lazily invites situations where an inherently unpredictable user 
action forces a complex series of constraints to be computed before 
anything can be displayed to the user, so the user must wait while the 
lazy system catches up. To do this eagerly means that at any time, any 
unpredictable user action will cause already computed state to be 
displayed, because everything has been kept up to date automatically 
all along.

I'm saying that he conceived of the problem in the most natural way - 
state with mutations - and implemented it that way. He was not forced 
by his language to reconceive it purely functionally, have haskell 
implement the default lazy semantics, only to require the programmer to 
find an escape hatch from this default laziness since what he really 
wants is eager evaluation of side effects (i.e., I/O - syncing of model 
state with GUI display).

People habitually think of the world as state and mutations of state. 
We've been doing so for a minimum of tens of thousands of years, quite 
possibly a million or more. People are good at thinking about mutation. 
Maybe this should tell us something about the desirability of certain 
programming language semantics and that referential transparency is a 
bit overrated.

 
 We don't want to reconceptualize everything according to a particular 
 paradigm, we want the flexibility to write the solution to
 the problem in the terms we think and talk about it, not the
 procrustean bed of pure functional semantics.
 
 Of the programming paradigms that can be implemented in Lisp, Lisp doesn't
 exactly make them easy. Moreover, every time you pick a random Lisp library
 off the wall to implement some feature already found in most other
 languages, you fragment the already tiny user base into even fewer people.

Not all lisp programmers will be solving the same sorts of problems as 
each other, so naturally they'll be using different sets of libraries. 
This use of different sets of libraries for different tasks doesn't 
constitute laguage fragmentation.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Raffael Cavallaro]

On 2006-12-17 12:52:34 -0500, Jon Harrop [EMAIL PROTECTED] said:

 Implementing pattern matching does not mean imitating Haskell or OCaml.

We were explicitly comparing lisp with haskell and ocaml. Adding 
features built into haskell and ocaml but not present in ANSI common 
lisp would therefore constitute imitating haskell and ocaml in the 
context of this discussion. Surely you don't think I'm unaware of the 
fact that haskell and ocaml weren't the first languages to use some 
form of pattern matching. I acutally used SNOBOL once upon a time.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Slawomir Nowaczyk]

On Sat, 16 Dec 2006 14:05:06 -0500
Kirk Sluder [EMAIL PROTECTED] wrote:

# And there is something that is missing here in arguing about computer
# language notations in relationship to human language readability, or
# correspondence to spoken language. I'm not writing code for another
# human, I'm writing code for a machine. Often, the optimum expression
# of an mathematical concept for a machine is relatively baroque
# compared to the optimum expression for a human being.

Well, the memorable quote from Structure and Interpretation of Computer
Programs states that Programs should be written for people to read,
and only incidentally for machines to execute.

-- 
 Best wishes,
   Slawomir Nowaczyk
 ( [EMAIL PROTECTED] )

If at first you do succeed, try not to look astonished.

-- 
http://mail.python.org/mailman/listinfo/python-list