You can't expect people to be reasonable when it comes to language flamewar. Personally, I think weak advocacy is worse than no advocacy at all. So why not cr

You can't expect people to be reasonable when it comes to language flamewar. Personally, I think weak advocacy is worse than no advocacy at all. So why not create syntax that catches 99% of the cases for which you intend the language to be used and abolish the ability to create further syntax? Although it's possible to create new syntax in Common Lisp via reader macros -- I don't think lispers recommend to extend the syntax. But when you miss a language feature, instead of fighting against the language, you could implement it. I don't remember exactly who said it in one the SICP video lecture, Harold Abelson or Gerald Sussman, but he said something like Lisp is not good at solving a particular problem. What Lisp is good at is extending the language to solve a class of problems. The problem with syntax is that it's difficult to use correctly with macros. It's no wonder that most introduction books to C warns against the pitfalls of using macros. Even the simple ones could bite you if you're not careful. Consider: #define DOUBLE(x) (2*x) /* should be (2*(x)) */ #define MAX(a, b) ((a) < (b) ? (b): (a)) Even the last one is not immune against multiple evaluation problems if you try to evaluate MAX(a++, b). In Lisp you could avoid this by using gensym and local bindings. That being said, C macros and Lisp macros are completely different beasts. And I recommend reading ``On Lisp'' for advanced use of Lisp macros.