> It is very unfortunate that C taught multiple generations of programmers that macros are a deadly trap waiting to blow up at runtime if you don’t bend yourself to insane coding idiosyncrasies.
I don't think that's a fair or reasonable take. If anything, generations of programmers learned from experience that instruction systems that are orthogonal to the language and blindly manipulate text strings while ignoring semantics and context and even basic types that is readily available, such as the C preprocessor or M4, leads to a subpar developer experience, code that is far harder to reason about, and causes bugs that are hard to troubleshoot.
Given the choice, implementing features into the language that can be evaluated by static checks is far cleaner and easier to understand and maintain.
> If anything, generations of programmers learned from experience that instruction systems that are orthogonal to the language and blindly manipulate text strings while ignoring semantics and context and even basic types that is readily available, such as the C preprocessor or M4, leads to a subpar developer experience, code that is far harder to reason about, and causes bugs that are hard to troubleshoot.
Good thing Lisp macros are absolutely nothing like that.
Parse tree manipulation, on the other hand, can be extremely reliable and make code that's much easier to read about.
The problem is that the lack of macros in C# makes a lot of people use reflection and other stuff which is even harder to debug. The code emission stuff in Roslyn is very interesting but God be with you if you have to understand somebody else's code who uses it.
Also, if you don't overuse the preprocessor you can save tons of boilerplate.
> The problem is that the lack of macros in C# makes a lot of people use reflection and other stuff which is even harder to debug.
Arguably, the problems that require reflection to be solved are also problems that are not solved with macros in a way that leads to code that's easy to maintain and reason about. Therefore, I don't see a net benefit in advocating macros.
Nevertheless, if anyone really wants to use macros in C# they are free to do so. Just pick your favourite macro processor and bolt it onto a project as a preprocessing step.
I don't think that's a fair or reasonable take. If anything, generations of programmers learned from experience that instruction systems that are orthogonal to the language and blindly manipulate text strings while ignoring semantics and context and even basic types that is readily available, such as the C preprocessor or M4, leads to a subpar developer experience, code that is far harder to reason about, and causes bugs that are hard to troubleshoot.
Given the choice, implementing features into the language that can be evaluated by static checks is far cleaner and easier to understand and maintain.