2 ms·
The main reason is that our "code management" (essentially code weaving) system allows coders to painlessly mix their own custom code in the same file as genera
by jonathanlydall 8y ago
The main reason is that our "code management" (essentially code weaving) system allows coders to painlessly mix their own custom code in the same file as generated code.
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.
- taeric 8y agoThis sounds like a large part of the reason is you deliver the code to others, but don't want to deliver the tool you used to make the code. This makes sense to me. 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.
- jonathanlydall 8y agoHere a recording of one of our guys on a webcast and it also shows the tool in action: https://www.youtube.com/watch?v=vA3L8_DaECQ https://www.youtube.com/watch?v=vA3L8_DaECQ "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.