Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

runtime generated code is just vastly inferior to compile time generated code

That's a big call. I think you should curtail it, eg. "runtime generate code can be harder to debug". This is often true but not always. Let's not get in to workmen and their tools.



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.


Your 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?


I'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?


I 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.


Lisp macros?


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




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: