About code generators / generating code

James Avery blogs about an article written by a person who calls himself 'Angry Coder' (I thought people called me that ;)) and that article ventilates the opinion that code generators are not useful, to say it in a politically correct way. I agree with James Avery that the article misses the advantages of code generation and how it can benefit you in your daily life. I'd say: the article is totally wrong. Here's why.

In 1993, a professor of the CS department I was a student of held a lecture about code generators. In short it came down to the fact that typing code statements is time consuming, boring and error prone, and has nothing to do with programming, which is defining algorithms, data-structures and functionality specifications, in a language independent way. If you can transform the actual logic, the functionality you want to implement, from a higher abstract level to code which can be compiled by a compiler into executable format without having to type it in, it would be a real time saver plus would give you (almost) error-free software.

Code generators do that. They let you define functionality on a higher abstract level and do the typing for you. LLBLGen v1.x (the open source, free version) f.e. generates code to do the CRUD operations on an SqlServer catalog (C#/VB.NET/t-sql) and some more. You then do not have to type in that code, you can be sure it works and you can go on with what's really important: writing Business Logic (BL).

Even in that area, the days of typing code are numbered, at least for the majority of applications. Look at BizTalk server. It lets you design your BL with standard code blocks. In other words: it generates the glue between default blocks that can be reused. If you want an extra piece of functionality that is not there, you can add it or buy it. Adding it can force you to type some code, but not much. "People who do not understand that code generation is the future will be the first who will not be able to keep up with the rest who do", I said in the comments on James' blog. Print it out on a piece of paper and glue it on your monitor. Code generation is the future, simply because it saves time, is less error prone and it saves the programmer from boring coding sessions, sessions which will result in more bugs than interesting coding sessions.

I really feel sorry for those people who do not understand what power code generation really has. They are doomed to do boring work which can be done by computers in a fraction of the time without any error. Or does the author of that visionary article think he can program a DAL + BL facade tier-set for an application which has 100-s of tables, without errors? It did cost me 2 months to do it for my upcoming LLBLGen Pro application, to develop the framework and the code which is used in the templates. The generator can do it now in 2 seconds. Without 1 error. I definitely know what I'd do if I had to choose between the two :).

Code generators are tools, like a compiler, editor or debugger. Good tools help the user, so a good generator will help the user of that generator. It should be: which generator will I use?, and not: shall I use a generator or not?, like it is already natural to choose a higher order language or a sophisticated editor over their lamer equivalents. If you, as a developer, be aware of the fact that developing software has nothing to do with typing code but has everything to do with choosing which algorithms, which patterns, which OO structure, which database model, which sets of functionality to implement and so forth, you also be aware of the fact that the fastest and most clever way to realize all that is to specify what you want to develop in a tool which will then the best way how to implement what you want to develop. Code generators help you to reach that ultimate goal. We're not there yet, but I'm sure one day we'll. Until that time, code generators are the closed things we got to get near that ultimate goal. Don't stay behind.

6 Comments

  • We used a slightly modified version of LLBLGen 1 for a project at the Fontys University. This saved us roughly 70% of the development time...not only because of the generation features, but also the iterative development made possible with LLBLGen. It's fast and easy to do roundtrip engineering using Visio creating the E/R, let LLBLGen update the DAL accordingly and slapping business-logic on top.





    About 90% of the generation tools out there aren't useful indeed.





    Just to note: LLBLGen also has its weak points... I'm not pr'ing over here ;)

  • :)





    Code generators have disadvantages too, like when they are not able to generate the code for the functionality you define in them, or the generated code is not up to par with the functionality requirements you have. I don't think the percentage of useless generators is around 90%, but there are a couple which are not useful in a wide range of applications, however no tool is (try hammering a nail with a screwdriver ;)). That's why you have to make a choice which generator you'll use. That's the question you have to ask yourself, not if generation of code is useful, because it is.





    The working-method you describe is the one I forsee also: modelling abstract database models in a high end tool, generate code to work with the physical result of that modeling and on top of that, if possible generate BL code, and if not, hand-develop it. With a form-designer to do the gui (which is also a code generator ;)) it's easy to cut down development time using generators. It's just weird not a lot of people understand that. Ah well, the Not Invented Here (NIH)-syndrome is still roaming I guess. ;)

  • I think an important point that should also be made is that programmers the use code generators should understand the code that is generated.

  • I hope you mean: "understand the interface and functionality of the code generated". I really do not see why a developer who uses a code generator, should understand the source code generated, since he shouldn't modify that code anyway, only extend it, and then the developer should know the interface and functionality.





    if class Foo has a method Bar, and all you should hve to do is call 'Bar', why do you want to know how Bar works? I never check the x86 assembler the JIT creates, nor do I decompile .NET library methods (unless they have unexpected behaviour, as in: it looks like a bug).

  • I couldn't agree more here: "code generator is the future".





    btw, when are you planing to release llblgen Pro. I can't wait for that!


    Do you have an estimative month?


    Will you give the sourcecode at the same price?





    thanks,


    Matias


  • Matias: I hope to be finished with it at the end of august 2003 :)





    The system is extensible in a lot of ways: code is generated using templates plus the steps the generator takes are configurable using task definitions in an xml file which bind tasks (f.e. directory creation) to an assembly and class which performs hte task). You can then add whatever you like as custom task, using your own assemblies, f.e. get old sources first from a sourcecontrol system or whatever :). We haven't planned source control release for a price, but perhaps we open up the source of the runtime library for licensees.

Comments have been disabled for this content.