The second guess is that humans occasionally rewrite the code for optimization. It might then be easier to source controll the code rather than patches.
Optimization can almost make sense, but maintaining a patch process is almost certainly the superior way to go. If only because it supports staying current on the generated code.
Now, I would expect you to have an artifact repository. To that end, you would be able to easily get the generated sources. But, they would decidedly not be in the source repository.
We feel that code generation is something one does explicitly while modelling, not something done every time you build.
Our tool also allows developers to review proposed code changes before choosing to commit them to disk.
Code generation is something you choose to do explicitly as you model.
This is very useful for cases where you want to model signatures of methods in our tool, but then leave it to the developer to implement the method which performs the business code. If you want to change the signature of the method, for example adding a parameter, then our code generation will add it in without messing up your custom code.
Our own templates generate code which is as beautiful looking and readable as code written by the best developers, and we encourage template writers to do the same. This makes working with the code in your IDE and reading it as much of a pleasure as any other well written code, having it in your SCM also gives you a history of how the code has changed over time.
Finally, use of the tool is optional, if you hand the the repository over to another team, or as a contracter you deliver it to a client, they don't need the tool, and just get code which looks as if it was written by a good developer.
For the other cases you gave, that sounds like what Interfaces were made for. :) Granted, I think we are in a world where tooling not necessarily requiring language constructs is a better place.
Regardless, if you are seeing such success, I would be greatly interested in seeing you open up that tool.
"No lock in" is an important aspect for us. We know of some other big players with "RAD" type tools which "generate" code, but unless one continues using their tool, the code they're left with is effectively unusable. Their business models are also often around runtime licensing.
As devs, building a tool for other devs, we want our tool to continue to be used because people clearly find the value in it, not because they feel locked in.
Anything you do that increases the time between the introduction of the bug and the finding of the bug will make it harder to actually fix it.
This allows developers to feel in control of what's changing in their code base during generation, rather than being worried that some custom code is going to get wiped out by code-gen without them realizing.
In a past project I was on, we had our solution build process run T4 templates to generate code, and it significantly slowed down the build process.
We feel code generation is something you explicitly do when you're "modelling", it's not something that's necessary to create a build nor should it create run-time dependency.
My fear is typically around having "mixed edited" code. That is, code that is edited by hand and generated. I greatly prefer being able to know that the generated stuff is extended by language mechanisms and I will never really have even the ability to edit something that the generator will do. I have seen bugs in generated code, but I have always pushed to fix the generator, not just fixed the generated code. (That make sense?)
And, reiterating because I feel it is important, your position is awesome. Thanks for sharing!
Our main development focus right now is on usability for new comers and we're improving it regularly.
I appreciate your reply and that it didn't end with "So, you should use program X (the one you work on) because it's the best software". Your objective response is great.
Otherwise, in general we're far more interested in constructive criticism (or even just normal criticism) of our philosophy (and tool) from a place like HN, rather than trying to score a little free "advertising". When the time is right, we'll do proper promotion, and it won't be by spamming forums.
Our main development focus right now is on usability for new comers and we're improving it regularly.
For about 5 years now, the teams I have been on have found great success in the use of DDD. Towards this we have used a tool which not only allows us to visually model the domain using UML, but also performs what we call “code management” (smarter code-gen which doesn’t get in your way, or produce ugly code) which turns the UML into code for our ORM of choice.
All members of the team are required to use the tool and UML to create new domain entities which then automatically become (beautifully formatted) code.
The enormous advantage of this approach is that the documentation (in the form of UML in this case), never goes out of date and lives with the code, it’s literally checked in to our Git repo in an SCM friendly format next to the normal code.
We are always able to talk around these visual models when planning a new feature or strategising a technical solution for a requirement.
An architect can at any time reason about the domain without having to first build up a mental model of it from code.
When juniors ask questions of seniors, they can both talk around the UML so that they quickly get clarity on the best way forward.
I would never go back to building business software any other way.