Why don't people like lisp?

[Brian Kelley]

Matthew Danish wrote:

> I would see this as a dependence on an implementation artifact.  This
> may not be regarded as an issue in the Python world, though.  

As people have pointed out, I am abusing the C-implementation quite 
roundly.  That being said, I tend to write proxies/models (see 
FileSafeWrapper) that do the appropriate action on failure modes and 
don't leave it up the garbage collector.  Refer to the "Do as I Do, not 
as I Say" line of reasoning.

> This is not to say that Python couldn't achieve a similar solution to
> the Lisp one.  In fact, it could get quite nearly there with a
> functional solution, though I understand that it is not quite the same
> since variable bindings caught in closures are immutable.  And it would
> probably be most awkward considering Python's lambda.

I don't consider proxies as "functional" solutions, but that might just 
be me.  They are just another way of generating something other than the 
default behavior.

Python's lambda is fairly awkward to start with, it is also slower than 
writing a new function.  I fully admit that I have often wanted lambda 
to be able to look up variables in the calling frame.

foo = lambda x: object.insert(x)
object = OracleDatabase()
foo(x)
object = MySqlDatabase()
foo(x)

But in practice I never write lambda's this way.  I always bind them to 
a namespace (in this case a class).

class bar:
   def some_fun(x):
        foo = lambda self=self, x: self.object.insert(x)
        foo(x)

Now I could use foo on another object as well.
foo(object, x)

> I'm not sure I understand this paragraph.  The macro only executes the
> body code if the file is successfully opened.  The failure mode can be
> specified by a keyword argument.  

I can explain what I meant with an example: suppose you wanted to tell 
the user what file failed to open/write and specify a new file to open. 
  You will have to write a handler for this and supply it to 
(with-open-file ...) or catch the error some other way.

  > Not sure what `using macros as a default handler' means.

Apologies, I meant to say that writing a macro to handle particular 
exceptions in a default-application wide way is a good thing and 
appropriate.

> The WITH-OPEN-FILE macro is not really an example of a macro that
> performs something unique.  It is, I find, simply a handy syntactic
> abstraction around something that is more complicated than it appears at
> first.  And, in fact, I find myself creating similar macros all the time
> which guide the use of lower-level functions.  

Right.  I'm was only trying to point out, rather lamely I might add, 
that the macros I have been seeing I would solve in an object-oriented 
manner.  This might simply be because python doesn't have macros.  But I 
like the thought of "here is your fail-safe file object, use it however 
you like".  It is hard for me to say which is 'better' though, I tend to 
use the language facilities available (and abuse them as pointedly 
stated), in fact it took me a while to realize that (with-open-file) was 
indeed a macro, it simply was "the way it was done(TM)" for a while. 
Certainly, new (and old) users can forget to use their file I/O in the 
appropriate macro as easily as forgetting to use try: finally:

In python I use my FileSafeWrapper(...) that ensures that the file is 
properly closed on errors and the like.  As I stated, this wasn't handed 
to me by default though like I remember as (with-file-open ...) was from 
my CHLS days.

So let me ask a lisp question.  When is it appropriate to use a macro 
and when is it appropriate to use a proxy or polymorphism?  Perhaps 
understanding this would break my macro stale-mate.

p.s. given some of the other posts, I am heartened by the civility of 
this particular thread.