Comment Re:Why design a new language? (Score 1) 336
It's been my experience that Lisp macros, _when used well_, make code more readable and natural.
The argument that Lisp macros make for un-readable code could also be applied to functions: if a bad programmer writes a bunch of functions named foo1 foo2 bar3 mybar myfoo, that would make the code unreadable as well. I guess ANY abstraction suffers from this potential flaw. It's just a matter of what we're used to.
Most (I hope) programmers know how to write nice, self-contained functions that are well-named and well-documented. This adds to the readability and maintainability of the code. dotproduct(a,b) is a lot clearer than (a.x*b.x + a.y*b.y).
Unfortunately, most programmers don't know how to write nice, self-contained LISP macros, so LISP macros get a bad rep. This is unfortunate, since LISP macros can make code MUCH clearer.
Paul Graham's "On Lisp" offers many great patterns for LISP macros, but he (ironically) names them very strangely. Like, map-> for example..it's not really obvious what that macro is used for. However, what about a macro like with-open-file? In my opinion, with-open-file makes it painfully obvious what a block of code does: It does some stuff to an open file, which is implicitly closed at the end of the block. And this avoids issues like forgetting to close a file after use, because the macro handles this implicitly.
Everyday in my non-LISP programming tasks, I see code that would be much clearer and easier to maintain given some LISP macro-like functionality. You really need to use LISP macros to realize their power, so it becomes second nature to see where they can HELP. Any language feature can be abused, but when used properly, they help greatly.
Peter Seibel's "Practical Common Lisp" offers some great examples of macro usage with the CD Database chapter.
The argument that Lisp macros make for un-readable code could also be applied to functions: if a bad programmer writes a bunch of functions named foo1 foo2 bar3 mybar myfoo, that would make the code unreadable as well. I guess ANY abstraction suffers from this potential flaw. It's just a matter of what we're used to.
Most (I hope) programmers know how to write nice, self-contained functions that are well-named and well-documented. This adds to the readability and maintainability of the code. dotproduct(a,b) is a lot clearer than (a.x*b.x + a.y*b.y).
Unfortunately, most programmers don't know how to write nice, self-contained LISP macros, so LISP macros get a bad rep. This is unfortunate, since LISP macros can make code MUCH clearer.
Paul Graham's "On Lisp" offers many great patterns for LISP macros, but he (ironically) names them very strangely. Like, map-> for example..it's not really obvious what that macro is used for. However, what about a macro like with-open-file? In my opinion, with-open-file makes it painfully obvious what a block of code does: It does some stuff to an open file, which is implicitly closed at the end of the block. And this avoids issues like forgetting to close a file after use, because the macro handles this implicitly.
Everyday in my non-LISP programming tasks, I see code that would be much clearer and easier to maintain given some LISP macro-like functionality. You really need to use LISP macros to realize their power, so it becomes second nature to see where they can HELP. Any language feature can be abused, but when used properly, they help greatly.
Peter Seibel's "Practical Common Lisp" offers some great examples of macro usage with the CD Database chapter.
