Generally, you don’t want to use eval in Common Lisp, but among newbies it’s common to think it should be used in many places where you should do it in another, easier & cleaner way. Have a look at http://www.faqs.org/faqs/lisp-faq/part3/section-13.html (“When is it right to use eval”) for more info.

Same thing goes for macros: newbies tend to think of them as working like their crippled relatives in the C world, and as such use them as a way to inline code. With strange results. :)

This is really what I’m referring to: the wise use of advanced features is essential. Python, Common Lisp, Ruby, etc, all give programmers the ability to create very clever and unmaintainable code. I wouldn’t blame any one feature for this either — for instance, eval is very dangerous, but I certainly wouldn’t remove it. Runtime patching of code is similar. Or, to give an example from SQLObject, I do operator overloading there in a particularly peculiar way, using operators to build expressions instead of calculate expressions. Generally I would say that’s a dangerously clever technique. Specifically for that problem (constructing SQL expressions) I think it works well. Experience and experimentation is generally the best guide for figuring this out. But that experience doesn’t have to be entirely personal; the community has experience and can offer important guidance.

As an example in Ruby and Python, community experience will come down on anyone using eval for anything that doesn’t absolutely require eval. In Ruby it still is seen as a valid metaprogramming technique. I don’t know the Common Lisp community well enough to know what community convention accepts and avoids, but I’m sure there as in any community there are particular standards.

Who says SQL isn’t the right abstraction level for many problems? Maybe the average “CRUD” application benefits from things like SQLObject, but the most significant complaint about most ORM solutions is how they reinvent SQL badly in the solution developer’s language of choice, and how you have to jump through hoops to write something that may be difficult in SQL, but which is natural in that language. I’ve done a fair amount of work with relatively large databases of late and I can’t see how hiding the database system (and its very useful query analysis tools) would have been beneficial.

“A good example of this is the (define-binary-class …) macro Peter Seibel (in the book Practical Common Lisp) creates for his ID3-parser. You essentially define a bunch of classes and functions, automatically, by just defining the layout of the binary file. Enter a bunch of clever macros which then fill the rest out for you.

I think declarative structure parsing is very nice, and there are solutions like this in Python.

“Even though you might not actually start using Lisp, I strongly suggest you read Practical Common Lisp, as I believe it will make you see a lot of things in a new light. (It did to me, and I’ve written my fair share of Python, including a commercial TurboGears-based deployment, attended EuroPython and been quite the Python advocate.)”

I hope you’ll make it back to EuroPython this year, too. ;-)

You are correct.

In fact, monkey patching isn’t necessary in Common Lisp, because of/thanks to multiple dispatch (which follows from methods not belonging to classes, i.e. the reason for having to monkey patch).

It seems the problem doesn’t happen at all. I wonder what similar issues happen in Lisp?

“”"In the case of 3 it’s quite dangerous. I don’t see how generic functions make it any less dangerous.”"”

Quoting Peter Seibel again:

“”"The methods I’ve been discussing so far are called primary methods. Primary methods, as their name suggests, are responsible for providing the primary implementation of a generic function. The standard method combination also supports three kinds of auxiliary methods: :before, :after, and :around methods. An auxiliary method definition is written with DEFMETHOD like a primary method but with a method qualifier, which names the type of method, between the name of the method and the parameter list.

[...]

Auxiliary methods are just a convenient way to express certain common patterns more concisely and concretely. They don’t actually allow you to do anything you couldn’t do by combining primary methods with diligent adherence to a few coding conventions and some extra typing. Perhaps their biggest benefit is that they provide a uniform framework for extending generic functions. Often a library will define a generic function and provide a default primary method, allowing users of the library to customize its behavior by defining appropriate auxiliary methods.”"”

Something like that, maybe?

(The explicit referencing semantics in Perl 5 seem to me to stem from autoflattening in list context, which is a deliberate design decision. They’re an improvement over nested structures in Perl 4, but they’re definitely one of the least beautiful parts of that version of the language.)

The “high level” in Python that I’m trying to refer to isn’t really that high. Not crazy programming techniques, just high enough that you can safely trust that all the basics of programs — functions, conditionals, loops — work safely and well, and you can focus on the stuff that is more challenging. So I would argue that low level abstraction problems in Perl are more concerning than the ability to do highly abstract code. Once you start using closures and metaclasses and other things you have to watch what you are doing, in either language. But I feel much safer doing these high level things when I know the low level stuff is robust. Perl hasn’t made it robust.

There might be a point when even these high-level abstractions are robust. For instance, I’d feel more comfortable with closures if they could be introspected better. That the state in a closer is just inferred (at least in Python) makes it an awkward abstraction. We move up by small steps, and “high-level” and “low-level” is really just a way of placing language on a spectrum specific to this current time in development. I would certainly hope that the high level of today becomes the low level of tomorrow.