3 ms·

There's nothing wrong with generated code if it's never manually modified. Think of binaries: we never manually edit them but they are essentially "generated".

There's nothing wrong with generated code if it's never manually modified. Think of binaries: we never manually edit them but they are essentially "generated". More modern build systems automate this process of hiding the intermediate steps. One great example of this is the way Thrift and gRPC. You never edit the stubs or server code. You just implement an interface.

thesuperbigfrog 5y ago
>> There's nothing wrong with generated code if it's never manually modified. Agreed. The issue is that I have never encountered code that did not need to be changed later. I have encountered generated code for which the code generation system was no longer available and it was a tremendous pain to understand and modify.
- gravypod 5y ago
  The reason this is a pain is the projects doing that were already starting from a broken position. The code gen should be entirely managed by the build system. You should never need to modify or look at the generated code. If you need to change the generation output you should modify the "compiler" (tool doing the generating) or the input source you are using to generate. Examples: If you want to add an int32 into a protobuf you modify the .proto file with your message. If you want to change `int32` to `int32_t` instead of `int` to make the code generator more multi-arch friendly you'd change the protoc plugin for your language. "I have never encountered code that did not need to be changed" is the wrong mindset to have here. You're thinking of the generated code as source code instead of an internal build step (same thing as Clang or GCC's IR). Also if you're in a situation where "code generation system was no longer available" then your build would never succeed. This should be like saying "gcc was no longer available". It shouldn't be possible and in reality the generated code shouldn't even be checked into the source tree.
  - thesuperbigfrog 5y ago
    >> "I have never encountered code that did not need to be changed" is the wrong mindset to have here. You're thinking of the generated code as source code instead of an internal build step (same thing as Clang or GCC's IR). >> Also if you're in a situation where "code generation system was no longer available" then your build would never succeed. This should be like saying "gcc was no longer available". It shouldn't be possible and in reality the generated code shouldn't even be checked into the source tree. No. All I had was the generated code. It was not a "wrong mindset", it was the reality of the situation. The generated code was all that was available. The code generation system was proprietary and ran on a VAX. I did not have the model specifications used to generate the code. I did not have the proprietary code generation system. I did not have a VAX system to do the code generation. All I had was the generated code because that was all that was available. The generated code needed to be ported to a different machine architecture and new operating system (Unix). Compilers for the generated code were available and some of the generated code would build fine while other parts needed to be adapted for machine word size, endianness, etc. >> the projects doing that were already starting from a broken position Sometimes you don't get to choose the situation. Maintaining legacy code and updating it to run in modern environments is not easy, but it does pay well. I completely agree that the original specification and code generation system are the "one true source" and that the generated source code should not have been kept, but those decisions were made long before I entered the picture.
hzhou321 5y ago
What's wrong is that the code is being generated, shown, pushed to repository, and distributed (for the purpose of human editing). With a compiler, the binary output is not shown, not maintained. The source code is. The generated code is no longer source code. Giving it an appearance of source code and even distributed as source code, is wrong. The source code for the mentioned example is: ... [copy linked list: annotations] ... I am not saying that the compiled/generated output shouldn't be human readable -- I strongly support readable intermediate outputs. But we need always recognize what is the real source code and what is the tool. Confusing them inflates the complexity and promotes wrong attitude, such as not taking responsibility for one's code or not caring about understanding the code.
- gravypod 5y ago
  > The generated code is no longer source code. Giving it an appearance of source code and even distributed as source code, is wrong. Yes, exactly.
- amw-zero 5y ago
  this did occur to me while reading the post - why not just generate assembly from the specifications? What's the point of the intermediate translation to C?
  - hzhou321 5y ago
    So each tool can stack on top of another tool.
  - curryst 5y ago
    Assembly is specific to the architecture, potentially in non-trivial ways. They either have to manually write support for each CPU architecture, or they need a higher level abstraction language. C is basically that higher level abstraction language. The tooling also helps. C compilers do some pretty fancy optimizations. Again, they can either re-implement that inside their tool, or they can just output C and use the existing tools.

thesuperbigfrog 5y ago

>> There's nothing wrong with generated code if it's never manually modified. Agreed. The issue is that I have never encountered code that did not need to be changed later. I have encountered generated code for which the code generation system was no longer available and it was a tremendous pain to understand and modify.

gravypod 5y ago
The reason this is a pain is the projects doing that were already starting from a broken position. The code gen should be entirely managed by the build system. You should never need to modify or look at the generated code. If you need to change the generation output you should modify the "compiler" (tool doing the generating) or the input source you are using to generate. Examples: If you want to add an int32 into a protobuf you modify the .proto file with your message. If you want to change `int32` to `int32_t` instead of `int` to make the code generator more multi-arch friendly you'd change the protoc plugin for your language. "I have never encountered code that did not need to be changed" is the wrong mindset to have here. You're thinking of the generated code as source code instead of an internal build step (same thing as Clang or GCC's IR). Also if you're in a situation where "code generation system was no longer available" then your build would never succeed. This should be like saying "gcc was no longer available". It shouldn't be possible and in reality the generated code shouldn't even be checked into the source tree.
- thesuperbigfrog 5y ago
  >> "I have never encountered code that did not need to be changed" is the wrong mindset to have here. You're thinking of the generated code as source code instead of an internal build step (same thing as Clang or GCC's IR). >> Also if you're in a situation where "code generation system was no longer available" then your build would never succeed. This should be like saying "gcc was no longer available". It shouldn't be possible and in reality the generated code shouldn't even be checked into the source tree. No. All I had was the generated code. It was not a "wrong mindset", it was the reality of the situation. The generated code was all that was available. The code generation system was proprietary and ran on a VAX. I did not have the model specifications used to generate the code. I did not have the proprietary code generation system. I did not have a VAX system to do the code generation. All I had was the generated code because that was all that was available. The generated code needed to be ported to a different machine architecture and new operating system (Unix). Compilers for the generated code were available and some of the generated code would build fine while other parts needed to be adapted for machine word size, endianness, etc. >> the projects doing that were already starting from a broken position Sometimes you don't get to choose the situation. Maintaining legacy code and updating it to run in modern environments is not easy, but it does pay well. I completely agree that the original specification and code generation system are the "one true source" and that the generated source code should not have been kept, but those decisions were made long before I entered the picture.

hzhou321 5y ago

What's wrong is that the code is being generated, shown, pushed to repository, and distributed (for the purpose of human editing). With a compiler, the binary output is not shown, not maintained. The source code is. The generated code is no longer source code. Giving it an appearance of source code and even distributed as source code, is wrong. The source code for the mentioned example is: ... [copy linked list: annotations] ... I am not saying that the compiled/generated output shouldn't be human readable -- I strongly support readable intermediate outputs. But we need always recognize what is the real source code and what is the tool. Confusing them inflates the complexity and promotes wrong attitude, such as not taking responsibility for one's code or not caring about understanding the code.

gravypod 5y ago
> The generated code is no longer source code. Giving it an appearance of source code and even distributed as source code, is wrong. Yes, exactly.
amw-zero 5y ago
this did occur to me while reading the post - why not just generate assembly from the specifications? What's the point of the intermediate translation to C?
- hzhou321 5y ago
  So each tool can stack on top of another tool.
- curryst 5y ago
  Assembly is specific to the architecture, potentially in non-trivial ways. They either have to manually write support for each CPU architecture, or they need a higher level abstraction language. C is basically that higher level abstraction language. The tooling also helps. C compilers do some pretty fancy optimizations. Again, they can either re-implement that inside their tool, or they can just output C and use the existing tools.