>So they reduce line count, they reduce need for kludges or workarounds. They allow more straight code. >But this is within the Land of Lisp, where writing a m

>So they reduce line count, they reduce need for kludges or workarounds. They allow more straight code. >But this is within the Land of Lisp, where writing a macro isn't something "advanced" nor "complex" nor "esoteric". In the Lisp world, writing a macro is 95% similar to writing a run-of-the-mill function. I agree with you but I think there are two aspects to code readability: A/ is it clear what the code does (the intent) and B/ is it clear how it does it (the implementation). I think macros can help massively with A (hiding redundant code and clunky constructs) at the cost of obfuscating B. The thing is that if you want to hack into the code at some point you'll need to understand B too. To take a very simplistic example imagine that you're reading some CL code and see something like: (let ((var 42)) (magicbox var (format t "side effect~%")) (format t "~a~%" var)) Now for some reason you need to figure out what this does. Maybe instead of the 2nd "format" call there's a function you're currently working on and you want to know how it's called. So, without running the code or looking at what "magicbox" does, if you assume that it's a function call, then you can expect that this code will print "side effect" when magicbox is called (since the parameter will be evaluated before the call) and then whenever it returns the 2nd format will display "42" since var is not modified between the let and there. You run your code and you see that it only displays "magic" instead. Uh, What happened? Well there you're lucky because there's only a single statement to consider, the magicbox invocation. You ask emacs to find the definition and you see: (defmacro magicbox (var unused) (list 'setq var "magic")) Now you might say that it's a contrieved example and a bad use of macros and you'd be right, but I'm sure you could find real world example of macros with similar side effects that are well justified. Maybe it makes the code a whole lot nicer and maintainable. Still doesn't change the fact that it makes it harder to figure exactly what's going on. If this magicbox call was in the middle of dozens of statements it might take you a while to figure out why some variably seems to magically change its value.