3 ms·
If you're using code generation, your tooling or architecture needs rethinking. There is 100% no reason to do it.
by meaty 14y ago
If you're using code generation, your tooling or architecture needs rethinking. There is 100% no reason to do it.
- pdwetz 14y agoSorry, to say there's 100% reason not to do anything is rather silly. By your own definition, what if your tooling lets you do codgen? Regardless, I've found code generation to be particularly useful in many scenarios and I would never dismiss it out of hand.
- meaty 14y agoBy my definition, I'd avoid it. The pitfalls, additional abstraction and debugging complexity just aren't worth it.
- btilly 14y agoIf you don't want to use code generation, go back to assembly language. Or did you not know what a compiler does? (Yes, modern "interpreters" have a compilation step.) Of course if you understand what a compiler does, the only question is whether you should be limited to what your official compiler is doing for you. (There are arguments pro and con, but it really isn't as simple as just saying no.)
- meaty 14y agoI am excluding the compiler. Yes it should be limited.
- jzwinck 14y agoHow would you implement something like Google Protocol Buffers without code generation for C++ clients? What about lex and yacc, or ANTLR? They all use code generation. Should we always write parsers by hand?
- meaty 14y agoYou can talk to protobufs without code generation. I'd implement something zeromq style instead however with a higher level payload abstraction I.e. BSON. Lex, yacc and antlr are pretty primitive tools to be honest. Ive written NFA->DFA parser engines which have no code generation step. The parser state and model are just data as per any other piece of functionality. To boot, they are safer than the numerous holes that bison etc leave open through their templating approach. I've written a couple of fairly extensive compilers so please don't assume I'm ignorant of the problem domain.
- contingencies 14y agoThe only correct response is that you are not 100% incorrect. While there are undeniably benefits of not using code generation and simply writing smarter code, sometimes this is not appropriate. Examples: (1) you want to keep some high productivity tools to yourself for financial reasons (eg. generating code to distribute to third parties) (2) you need to generate code with built-in documentation in various human languages, that integrates translations as they occur (3) your target system is fairly throwaway, you need to dumb down the abstraction level for some less experienced programmers, and it's easy to generate boilerplates (4) you are writing a model in a model-oriented language (ABNF, ASN.1, etc.), and generating the code in a completely different domain with different (ie. more complete) capabilities (5) you want to maintain retargetability of your code, ie. ease of switching to a totally new language (6) you want to target multiple languages, eg. generating protocol implementations for other developers to use (7) you want to target multiple platforms, eg. generating crappy apps for nth-mobile-platform-of-the-moment .. or some combination of the above.