4 ms·
I agree with the GP's statement, because "harder to debug" == "vastly inferior". In my last job we worked a huge amount with generated code, and having generate
by lemming 14y ago
I agree with the GP's statement, because "harder to debug" == "vastly inferior". In my last job we worked a huge amount with generated code, and having generated source that you can step through is essential. I've never seen runtime generated code that's easy to debug.
- batgaijin 14y agoLisp macros?
- ztzg 14y agoLisp macros are compile-time generated code (think "small compiler plugins"); nothing happens at runtime in a compiled implementation. More importantly, and to tie this back to the OP's comment, I would strongly recommend to implement any non-trivial macro as a "shell" which delegates to a normal function (cf. eval-when); that makes it much easier to debug/trace expansions from the REPL. In other words: you can have it both ways! :)
- contingencies 14y agoYour logic seems to be that because some runtime code can be harder to debug (This is often true but not always), having personally encountered such, you therefore declare that all runtime code is vastly inferior. Sorry, but this is ridiculous. Can you contribute something more solid than an anecdote?
- lemming 14y agoI'm sorry you think it's ridiculous but it's just my opinion, after all. Feel free to ignore it. Can you give us an example of runtime generated code that is easy to debug?
- contingencies 14y agoI can't. However, I do believe that software development in general is headed away from monolithic compilation, and that future systems will be largely real time, parallel, multi-component, perhaps more heterogeneous, and almost certainly predominantly interpreted. Our habits trap us in to seeing things one way.