4 ms·

The problem with generated code is that it is rarely easy to understand or maintain. Suppose you need to add new features or fix a bug, to do so you will need a

The problem with generated code is that it is rarely easy to understand or maintain. Suppose you need to add new features or fix a bug, to do so you will need all of the original specifications and code generation tools. Will those tools work on other platforms? Do they support all of the low level needs of C? For example, do they support bit-level layout for structs or inline assembly? I believe that Rust will make more inroads to replace C in many domains. This will eliminate many of C's known issues that Certified Program Synthesis seeks to address. If you need formal verification or proofs, SPARK https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language) is a mature and effective tool with a proven track record. It lets developers write code that is easy to understand and maintain compared to generated code and can formally prove the correctness of programs.

gravypod 5y ago
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.
jhgb 5y ago
> Suppose you need to add new features or fix a bug, to do so you will need all of the original specifications and code generation tools. So, nothing changes compared to using existing high level language compilers, then?
- thesuperbigfrog 5y ago
  >> So, nothing changes compared to using existing high level language compilers, then? On the contrary, it acts as an additional layer of complexity. Looking at the example generated code snippet from the article: void listcopy(void \*r) { void *x2 = *r; if (x2 == NULL) { return; } else { int vx22 = *(int *)x2; void *nxtx22 = *((void \*)x2+1); *r = nxtx22; listcopy(r); void *y12 = *(void \*)r; void *y2 = (void *) malloc(2 * sizeof(void *)); *r = y2; *((int *)y2) = vx22; *((void \*)y2+1) = y12; return; } } If you don't have the specification for listcopy or the code generation tools, but only the code shown and you need to make changes then you have a more difficult situation than normal, human-written code.
  - jhgb 5y ago
    So, as I said, nothing changes compared to using existing high level language compilers. You wouldn't normally hand-edit .S files from your C compiler either, why would you do it with this intermediate form?
    - thesuperbigfrog 5y ago
      Sometimes you don't get to choose the situation: the intermediate form / generated source code might be all that is available. See https://news.ycombinator.com/item?id=27750554 https://news.ycombinator.com/item?id=27750554
      - jhgb 5y ago
        True, but this situation has always existed with any higher level languages. Ultimately someone will have to write patches for binaries, even.
swiley 5y ago
It's odd, people freak out all the time with hiring saying "hiring a poor candidate does more damage than hiring no one" but spewing ML generated noise directly into your repo is somehow considered reasonable.
amw-zero 5y ago
> Suppose you need to add new features or fix a bug, to do so you will need all of the original specifications and code generation tools. Yes, that is the point of code generation. You had a positive sentiment towards Rust - Rust has a compiler. In order to work with Rust, you have to have "all of the original specifications and code generation tools." Source code is just the specification of the program, and the compiler is the code generation tool. Why do you trust compilers any more than this?
- thesuperbigfrog 5y ago
  >> Source code is just the specification of the program, and the compiler is the code generation tool. Compilers generate machine code. When I said "all of the original specifications and code generation tools", I was referring to tools that generate SOURCE code using models or specification languages such as: https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation https://en.wikipedia.org/wiki/Business_Process_Model_and_Not... https://en.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language These tools use models or specifications as input and generate source code output. Frequently these are expensive, proprietary tools that are intended to let semi-technical domain experts build solutions without needing to know how to program computers. They are the previous iteration of "no code" / "low code" tools. What happens if the model tool company goes out of business? What happens if the model tool company gets acquired and the new owner decides to raise the prices too much and some of their customers cannot afford to pay? What happens to all of the generated source code produced by these tools when the business using the generated source code needs changes made, but no longer has the models or tools?
dragonwriter 5y ago
> Suppose you need to add new features or fix a bug, to do so you will need all of the original specifications and code generation tools. Specs = source code. Code generation tools = compiler. How is this different from any other code? If you need to modify it, you need the source and a compiler.
- thesuperbigfrog 5y ago
  >> How is this different from any other code? Specs = https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation https://en.wikipedia.org/wiki/Business_Process_Model_and_Not... https://en.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language Code generation tools = https://bpmnmatrix.github.io/ https://bpmnmatrix.github.io/ https://model-based-systems-engineering.com/sysml-tools/ https://model-based-systems-engineering.com/sysml-tools/ https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Langu...
  - dragonwriter 5y ago
    Listing a bunch of specification languages and toolchains is not, at all, an answer to how needing to have both the source code and tooling for something coded from specs is different from having to do the same for any compiled language.
    - thesuperbigfrog 5y ago
      What happens if the model tool company goes out of business? What happens if the model tool company gets acquired and the new owner decides to raise the prices too much and some of their customers cannot afford to pay? What happens to all of the generated source code produced by these tools when the business using the generated source code needs changes made, but no longer has the models or tools? Yes, you need both specs and tools. Vendor lock-in can really bite, especially if your business depends on tools that are no longer available.

gravypod 5y ago

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.

jhgb 5y ago

> Suppose you need to add new features or fix a bug, to do so you will need all of the original specifications and code generation tools. So, nothing changes compared to using existing high level language compilers, then?

thesuperbigfrog 5y ago
>> So, nothing changes compared to using existing high level language compilers, then? On the contrary, it acts as an additional layer of complexity. Looking at the example generated code snippet from the article: void listcopy(void \*r) { void *x2 = *r; if (x2 == NULL) { return; } else { int vx22 = *(int *)x2; void *nxtx22 = *((void \*)x2+1); *r = nxtx22; listcopy(r); void *y12 = *(void \*)r; void *y2 = (void *) malloc(2 * sizeof(void *)); *r = y2; *((int *)y2) = vx22; *((void \*)y2+1) = y12; return; } } If you don't have the specification for listcopy or the code generation tools, but only the code shown and you need to make changes then you have a more difficult situation than normal, human-written code.
- jhgb 5y ago
  So, as I said, nothing changes compared to using existing high level language compilers. You wouldn't normally hand-edit .S files from your C compiler either, why would you do it with this intermediate form?
  - thesuperbigfrog 5y ago
    Sometimes you don't get to choose the situation: the intermediate form / generated source code might be all that is available. See https://news.ycombinator.com/item?id=27750554 https://news.ycombinator.com/item?id=27750554
    - jhgb 5y ago
      True, but this situation has always existed with any higher level languages. Ultimately someone will have to write patches for binaries, even.

swiley 5y ago

It's odd, people freak out all the time with hiring saying "hiring a poor candidate does more damage than hiring no one" but spewing ML generated noise directly into your repo is somehow considered reasonable.

amw-zero 5y ago

> Suppose you need to add new features or fix a bug, to do so you will need all of the original specifications and code generation tools. Yes, that is the point of code generation. You had a positive sentiment towards Rust - Rust has a compiler. In order to work with Rust, you have to have "all of the original specifications and code generation tools." Source code is just the specification of the program, and the compiler is the code generation tool. Why do you trust compilers any more than this?

thesuperbigfrog 5y ago
>> Source code is just the specification of the program, and the compiler is the code generation tool. Compilers generate machine code. When I said "all of the original specifications and code generation tools", I was referring to tools that generate SOURCE code using models or specification languages such as: https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation https://en.wikipedia.org/wiki/Business_Process_Model_and_Not... https://en.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language These tools use models or specifications as input and generate source code output. Frequently these are expensive, proprietary tools that are intended to let semi-technical domain experts build solutions without needing to know how to program computers. They are the previous iteration of "no code" / "low code" tools. What happens if the model tool company goes out of business? What happens if the model tool company gets acquired and the new owner decides to raise the prices too much and some of their customers cannot afford to pay? What happens to all of the generated source code produced by these tools when the business using the generated source code needs changes made, but no longer has the models or tools?

dragonwriter 5y ago

> Suppose you need to add new features or fix a bug, to do so you will need all of the original specifications and code generation tools. Specs = source code. Code generation tools = compiler. How is this different from any other code? If you need to modify it, you need the source and a compiler.

thesuperbigfrog 5y ago
>> How is this different from any other code? Specs = https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation https://en.wikipedia.org/wiki/Business_Process_Model_and_Not... https://en.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language Code generation tools = https://bpmnmatrix.github.io/ https://bpmnmatrix.github.io/ https://model-based-systems-engineering.com/sysml-tools/ https://model-based-systems-engineering.com/sysml-tools/ https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Langu...
- dragonwriter 5y ago
  Listing a bunch of specification languages and toolchains is not, at all, an answer to how needing to have both the source code and tooling for something coded from specs is different from having to do the same for any compiled language.
  - thesuperbigfrog 5y ago
    What happens if the model tool company goes out of business? What happens if the model tool company gets acquired and the new owner decides to raise the prices too much and some of their customers cannot afford to pay? What happens to all of the generated source code produced by these tools when the business using the generated source code needs changes made, but no longer has the models or tools? Yes, you need both specs and tools. Vendor lock-in can really bite, especially if your business depends on tools that are no longer available.