>>123
I think that Lisp and C macros have some important similarities that warrant the same term. They're both systems for transforming code before it is evaluated. The only major difference really is that C's macro language is a non-Turing-equivalent text copy-paster, and Lisp's macro language is Lisp.
And as for inventiveness, it is often a matter of standing on the shoulders of giants. If it's hard to reinvent lambda calculus in C, try monads and state-less programming, which builds very heavily on lambda. People don't do these things in C because C doesn't make it worth it. That's what I keep saying. People certainly CAN make complex data structures in asm, but they don't. Not typically. People CAN write an immutable array-mapped hash tri in COBOL, but COBOL does not make it worth it.
And that's what language features are to me. It's when a language makes it
worth it to use a particular strategy. And I really think it takes a language. In C++ and old-style (pre-closure) Java you always see the big systems: a) make an 'architecture' which implement half of a higher level language and b) lots of XML, which makes up the syntax of that language. It seems downright unavoidable.