Is it just a coincidence that I submitted one of Pieter Hintjens's old articles about code generation earlier today? If I'm not mistaken, Martin Sustrik worked with Hintjens.
You're right, they both worked on ZMQ together, however Sustrik disagreed with some of the design decisions and decided to make nanomsg. Hintjens and co have worked on code generation tools since the mid-90's. Read the zproto github page for more information!
Are you sure the programming language and libraries you are using allow this "higher level code"? Code generators are a general way to write low redundancy "higher level code" as input models and templates with minimal disruption of technology choices, without the effort, uncertainty and unreasonable cost of looking for "better" languages and libraries.
You sound like a consultant who talks about programming but has never done any. The words kindof make sense in the order you are saying them, but I can't find any relationship to reality. Are you some kind of GPT bot?
I suspect your "reality" consists of very small and very homogeneous projects that leave you a fair chance of doing well with simple refactoring and reorganizations, not to mention starting from scratch frequently. But generating code allows you to make changes that cannot be expressed well in your programming language or using your libraries, for example validating the same data in the same way in two different front ends that don't allow refactoring.
I'm using code generation to go from a super simple finance DSL to a c program which then gets compiled using clang. Could I do it without code generation? Maybe, but I get the flexibility of a dynamic language to do the DSL parsing etc.
I see it as a bit like LLVM - an intermediate stage that adds flexibility.
You are describing a compiler, not code generation as I am criticizing. When people generate code, the generated code is the code they check in and modify going forward, not just some intermediate step in a language implementation.
There's a misunderstanding, generated code is only "modified going forward" by very immature organizations.
For extra negative credits there is the false idol of "round-trip engineering", like in the old Together Control Center, usually involving UML.
Generating from nice models and nice templates (the real source code) verbose and correct "boilerplate" that won't be usually read, let alone modified, is simply a shift to an ad hoc, specialized programming language.
You were critical of this tool. I could easily see this tool being used for my use case. It generates human readable c which I can exactly what I want and is not what compilers do.
Who says you have to check the generated code in and modify it going forward?
You're commenting on your own definition of 'code generator' without properly considering this tool and its use cases.
Well, I use templating languages and I think they are quite useful. I've used many in my career, probably 10 or more. Now there is another one, which is good to know I guess.
Seems like they could have made some different design decisions to make the input a lot more readable. Also IMHO code generation should be a last-resort anti-pattern; after all that's what you (the programmer with a brain) are for.
> Also IMHO code generation should be a last-resort anti-pattern; after all that's what you (the programmer with a brain) are for.
Code generation should be the "first-resort" pattern.
When talking code generation, it enforces you to think about your data model, your flow, patterns, usability, readability.
It is perfect to build repetitive boilerplate you can type on your own without thinking, so instead of taking up 10 minutes fighting input/UX bandwith of your hands and tools, you can generate huge chunks of code you would have to write anyways (and possibly make a mistake).
You should not have repetitive boilerplate at all, and if your speed of programming is limited by how fast you can type you are writing some really bad code without understanding high level programming at all.
Repetitive boilerplate isn't just "wrapper spaghetti code".
Repetitive boilerplate is what builds systems.
If I can make a model that has 50 lines and will generate 50 different classes, 50 files and 600 methods where I only need to fill out the expressions, that is writing code.
If I am going to say how it's all boilerplate and write it by hand, chances are I will have something nobody else will understand with bugs I cant remember or will have to rewrite the above by hand into a boiler-plate-like way again, which to me, makes no sense to do manually.
> Also IMHO code generation should be a last-resort anti-pattern; after all that’s what you (the programmer with a brain) are for.
What I am for, as a programmer, is writing code to automate tasks that are determined by some input tasks to allow humans with brains to focus on things that need to thought.
To the extent some part of coding is such a determined task, automating it with code generation makes sense. Though there tends to be a lot of overlap between what is addressable by code generation and what is addressable by reusable libraries, and in most cases if both solve the same problem, I’d prefer a library to a generation template.
Wouldn't it be more readable if the "syntax" was the other way round? My instinct tells me that I'd prefer to read the output-code better, and that the generation would just be simple stuff.
26 comments
[ 3.1 ms ] story [ 62.9 ms ] threadFor performance in super specific situations where you can use it like a jit of sorts to reduce overhead.
To intentionally obfuscate code or avoid shipping core logic to clients for fear it will be copied.
Any other use is probably just inexperienced programmers trying to find a way to write higher level code and failing.
I see it as a bit like LLVM - an intermediate stage that adds flexibility.
Generating from nice models and nice templates (the real source code) verbose and correct "boilerplate" that won't be usually read, let alone modified, is simply a shift to an ad hoc, specialized programming language.
Who says you have to check the generated code in and modify it going forward?
You're commenting on your own definition of 'code generator' without properly considering this tool and its use cases.
Did you make this? It seems like you and HelloNurse are very upset by anything that suggests this isn't perfect.
Code generation should be the "first-resort" pattern.
When talking code generation, it enforces you to think about your data model, your flow, patterns, usability, readability.
It is perfect to build repetitive boilerplate you can type on your own without thinking, so instead of taking up 10 minutes fighting input/UX bandwith of your hands and tools, you can generate huge chunks of code you would have to write anyways (and possibly make a mistake).
If I can make a model that has 50 lines and will generate 50 different classes, 50 files and 600 methods where I only need to fill out the expressions, that is writing code.
If I am going to say how it's all boilerplate and write it by hand, chances are I will have something nobody else will understand with bugs I cant remember or will have to rewrite the above by hand into a boiler-plate-like way again, which to me, makes no sense to do manually.
What I am for, as a programmer, is writing code to automate tasks that are determined by some input tasks to allow humans with brains to focus on things that need to thought.
To the extent some part of coding is such a determined task, automating it with code generation makes sense. Though there tends to be a lot of overlap between what is addressable by code generation and what is addressable by reusable libraries, and in most cases if both solve the same problem, I’d prefer a library to a generation template.