4 ms·

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

by slaymaker1907 5y ago

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.

gefhfff 5y ago
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 :) )
- silon42 5y ago
  Even if macros are good, they can be overused (like C++ template metaprogramming).
  - dunefox 5y ago
    That's not a very profound argument.
Analemma_ 5y ago
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.
- fivea 5y ago
  > 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.
  - msla 5y ago
    > 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.
  - spaetzleesser 5y ago
    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.
    - fivea 5y ago
      > 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.

gefhfff 5y ago

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 :) )

silon42 5y ago
Even if macros are good, they can be overused (like C++ template metaprogramming).
- dunefox 5y ago
  That's not a very profound argument.

Analemma_ 5y ago

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.

fivea 5y ago
> 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.
- msla 5y ago
  > 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.
- spaetzleesser 5y ago
  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.
  - fivea 5y ago
    > 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.