6 ms·
> The key problem has been that the resulting programs are fantastically hard to understand. One of the things I think Dijkstra got right in "Goto Considered Ha
by CodeMage 4y ago
> The key problem has been that the resulting programs are fantastically hard to understand. One of the things I think Dijkstra got right in "Goto Considered Harmful" is that humans can reason about programs better when there's a strong correspondence between the textual structure of the code and its execution structure at runtime.
This resonates very strongly with me. I've been doing a whole bunch of side/toy projects in Rust for months, and I can attest that even compile-time metaprogramming can make programs "fantastically hard to understand". Runtime metaprogramming makes that problem an order of magnitude worse.
Don't get me wrong, I'm not against metaprogramming, either compile-time or runtime. But it's way too easy to get overly enthusiastic when doing it.
- nightpool 4y agoHonestly, I think runtime metaprogramming can be a lot easier to understand then compile-time metaprogramming, because it's easier to build runtime debugging features for runtime metaprogramming, compared to building runtime debugging features for metaprogramming that's already been erased at compile-time. For example, a sibling comment mentions Ruby—well, pry already supports "show-source [expr]" for basically any possible Ruby expression you might want to call, no matter how meta-programmed it might be. Navigating and debugging Ruby code can get very fluent once you have the right set of tools.
- int_19h 4y agoCompile metaprogramming can have compile-time debuggers. If it uses the same language for meta and regular, it should be the same debugger, ideally. The IDEs haven't quite embraced this concept properly yet, though: they usually have distinct "editing", and "running" states, but what's really needed is "editing", "building", and "running", with debugging available in the latter two.