On 4/18/2017 4:58 PM, bpr wrote:
Here's how it's done in Nim, a statically typed language similar to D, but with Python syntax, and macros. It takes some knowledge to understand, sure, macros are not a beginner tool, but wouldn't say this is extremely complex. I bet a D-with-macros would have a similar complexity solution.
I'm not saying you cannot do cool and useful things with AST macros. My position is it encourages absolutely awful code as (usually inexperienced) programmers compete to show how clever their macros are.
The language gets balkanized into a collection of dialects that are unrecognizable across user groups.
As a compiler dev who gets stuck figuring out users' bug reports, dealing with templates is bad enough (the first thing I do with a bug report is redo it to remove all the templates). I do not want to deal with some custom syntax. If I may pull the "I'm older" card, programmers will find as they gain experience that the AST macros are just not worth it.
This disastrous state of affairs has occurred with every language that supports macros.
If you want a nauseous example, check out the Boost C preprocessor metaprogramming library. Or C++ expression templates - so cool, and yet so utterly wretched.
Reminds me of a story from the 1980s. Microsoft's MASM stood for "Macro Assembler". Inevitably, Microsoft programmers invented a pile of macros that sort of turned asm programming into a pseudo-high-level language. This was shipped with every copy of MASM.
A friend of mine who worked at MS was once given the task of fixing a bug in 50K of MASM code written in this macro language. The author of it had long since moved on. Every coder assigned to this task failed. My friend got it fixed in a couple hours. He was asked by his astonished manager how he'd managed to do it:
"I assembled the code into an object file. Then I disassembled it with Zortech's OBJ2ASM, figured out how to fix it, then submitted the disassembled code as the new source code."
