[zcid]

I heard somebody make a similar argument one time in regards to Common Lisp. He said that with Java you would have to wait several years sometimes to get a feature (assuming the language developers actually cared about the feature), but with Lisp, you could just implement the feature yourself. I've always felt this is one of the strongest arguments for using a lisp-style language.

Edit: this is possible too in languages like Elixer and Ruby using macros, but eventually the readability suffers and debugging complex macros in those languages can be a nightmare.

[dmix]

I haven't done much metaprogramming stuff, is this just the nature of using macros or can it be solved with careful coding?

[ddragon]

Macros are really powerful constructs that allows you to even change the syntax of the language, which means when they are used you can't trust your previous knowledge of how the language should behave. If you do it correctly you can make a Domain Specific Language that makes your code as readable as the documentation in domains the language was not designed to directly solve (or just generate code for you to avoid boilerplate that would be more unreadable by itself). If you do it incorrectly, you can end up with code you cannot trust or even understand (and language design is a skill that not everyone has in the first place).

About debugging, it is somewhat different from normal debugging since macros are a second layer of abstraction. You have a compile-time phase in which the macros are resolved (receiving code and returning code until there is no macro left) and a runtime in which the final generated code is run. If you only consider the runtime, then you're looking at code that is not the same as you wrote, which makes it indeed hard to see mistakes. But if you separate the concerns of compile and run time you can evaluate both separately most of the time.

Also, Ruby does not have macros. It has a very simple syntax in which everything is an object and all function calls are actually messages that can be interpreted in runtime which allows you to extend the syntax very easily by controlling the dispatch rules. What causes trouble is that classes are open and can be extended freely during runtime, so you cannot know that an object you're calling is not modified by any part of the code (including any library), a practice called monkey patching and usually considered bad practice since it makes code hard to reason about.