4 ms·
I would like to add one other thing I like about go: There is a parser and an abstract syntax tree in the standard library. Sometimes when I'm programming at w
by jxcole 14y ago
I would like to add one other thing I like about go: There is a parser and an abstract syntax tree in the standard library.
Sometimes when I'm programming at work I need to add log messages to every method on a large interface (or several interfaces). It is obvious to me that there needs to be some tool or library that adds these very simple log messages to these methods for me (like "Entering method getUser(UserId=2701, SessionId='AABCF')").
The tool we have at work uses runtime generated code to add these messages to methods automatically. Besides the performance hit this is fine, except for one problem. Sometimes it doesn't work; and it is impossible to figure out why. You turn on the tool, add all the right metadata, and nothing happens. You could argue that it is a tool problem, but I think one of the big things is that runtime generated code is just vastly inferior to compile time generated code.
If I were using go, my tool would open the code, read the interfaces, and spit out a nice implementation of logging in a .generated.go file and if it doesn't work for some reason I can actually go look at the generated code and see why. Trying to figure out why an implementation isn't working by looking at it's dynamically generated bytecode or .net clr is not fun at all.
- contingencies 14y agoruntime 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.
- lemming 14y agoI 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.