4 ms·
> It's so easy to write useful but awful things with them, and they're really hard to fix and debug. And it is even easier to write useful, beautiful things wi
by sklogic 11y ago
> It's so easy to write useful but awful things with them, and they're really hard to fix and debug.
And it is even easier to write useful, beautiful things with macros, which are really easy to fix and debug.
- nickpsecurity 11y agoBack when I did a 4GL with them, my amateur trick was to write and test them like normal programs first. Then in the templated form as a normal program. Then do macros. On first two, I can use any technique known to benefit software quality. For programming in the large, interface checks that enforce correct usage are a straight-forward solution. Curious, with your LISP and ML background, what method or methods do you use to ensure your macros are correct and easy to debug?
- sklogic 11y agoA couple of very simple tricks: Macros must be staged - similarly to a good practice of not having too big functions, macros also must be small, and must transform code in small steps, with more macros further breaking the result down. Ideally, each macro must be a trivial rewrite doing only one small thing. Another trick is to have a bunch of macros that would inject debugging output when enabled. Wrap every macro definition body in such a macro, and, with debugging turned on (can be selective), both source and output would be displayed. Another macro can be used to inject debugging info into a generated code. I usually start writing macros the other way around - not from a code I'd like to see generated, but from a final form. Once I find the code with macros passable, I'll start implementing the macros, in small steps. Same applies to a DSL design in general - first I write a code I want to see, and only then I fill in an implementation.
- SixSigma 11y agoI can't remember the exact quote but : LISP's FOR macro got so clever that LISP programmers do everything they can to avoid using it