Hacker News Reader

Comment by slaymaker1907 | Hacker News Reader

slaymaker1907

I think the C macro system (and other similar macro systems) really ruined macros for a lot of people. A lot of the complaints about macros go away if you track scope carefully for generated code either by enforcing hygiene or by a more complex namespace system such as with syntax-case in Racket/Scheme.

View on HN

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. Macros are awesome and problems with them can be caught at compile-time, same as real code! But only if you have a macro system that isn’t worse than the problem it’s trying to solve.

> 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.

Yep, this. Once, I wanted to try Rust (while been heavily invested in C++ and a bit in C), and after just a bit digging into it, I discovered how present macros are in Rust (e.g. printing). This really turned me off such that I aborted learning Rust.

(Gladly I took a deeper look later :) )

Even if macros are good, they can be overused (like C++ template metaprogramming).

That's not a very profound argument.

Reply on news.ycombinator.com