How much time it saves code generators?

Question

My question seems easy but is little more theoretical than it looks. There are Code Generation software or application building software that gets done without the use of a programming language. Application like VE Server and VE Designer from Intelliun should accomplish this task. My question is, in reality have someone out there track the amount of real savings of this kind of tool versus having a development team and a source code evolutionary process.

For the specific example of VE Designer the application gets done from the designer and you don't see code for it, you just run the app in VE Server. All code looks like XML Internal commands.

Answer 1

It depends on how we measure that time.

If you compare two control groups - one that types in all the code by hand, and another that uses the code generator - I have no doubt at all that the group that uses the code generator will require less time, hands down. It depends on how far you want to go with the generator, of course, but there's little doubt that as the percentage of generated code goes up that the manual input looks worse and worse.

The only concern I have has to do with where that code generator comes from and how much thought went into its design.

If you don't want to touch the code that the wizard/code generator produces because you don't understand it, it ought to be counted against the code generator.

If the code generator forces you into a bad design, it ought to be counted against the code generator.

If the code generator spits out so many classes that nobody can follow what's happening, it ought to be counted against the code generator.

If the code generator makes your maintenance life a hell on earth, it ought to be counted against the code generator.

I like the idea of understanding and creating my own tools if I can. Wizards that are given by others can cause problems. The accounting for or against them ought to reflect the problems.

Answer 2

You may want to take a look at some of the answers to the question 'Are code generators bad?'. While the question itself pertains more to should/shouldn't I be using a code generator many of the responses have notes about the down sides to code generator use and how the code generated often has to be then looked at/edited by an actual human being. This is not always the case and depends a lot on the quality of the generated code (after all it's really just spitting templates written by a potentially horrible programmer who really wanted to be a lumberjack and shouldn't be allowed near a keyboard). If it's generating high quality code then you are likely going to get a time savings. Otherwise the time spent refactoring the result may end up being the same or greater than the time that would have been spent actually writting the code in the first place.

I've personally have had mixed results with code generators. The code generated automagically by Visual Studio for example (specifically the form designer) I find can be a nightmare to wade through and if I need to implement some special behavior suddenly the form doesn't look or behave as expected which usually ends up costing me more time. I am fond of the one in eclipse (not really a fully automatic code generation tool) because it lets me layout a class and then constructs all the method signatures etc. using built in editable templates (I also know that if it spits out crap it's my own fault). I find the general frame a much more useful time saver (e.g. being given the chassis of a car) than getting something that thinks it's good and does what you want it to exactly but doesn't (e.g. getting a 'fully' constructed car with only three wheels that only turns right).

Answer 3

I've used code generation (i.e. a program that spits out 2/3 or so of the code automatically and lets the programmer fill in the rest) in two situations, one time in a huge company with a giant product and another time using a tool I wrote myself. In both situations I found the results to be mixed.

1) It saved us time developing what we needed to get done at the time.

2) However, it locked us into our design, making the code a lot less flexible. It gave us a lot of duplicated logic that we couldn't easily modify.

From what I can tell, although I'm sure there's exceptions, you'll lose time in the long run if you use a code generation tool which that outputs code that a human will have to modify later on. Essentially, if it doesn't act like a compiler and doesn't allow you to refactor easily, it's probably going to have the trade off mentioned above.

Answer 4

There really isn't a clear distinction between a "code generator" and a "programming language." If you use software to generate code, you are doing programming, even if you don't understand the details. C++, Java, and C# are "code generators" in the sense that they get compiled into lower level languages, and those lower level languages themselves can be hand-coded if a programmer chooses to do so. Many programming languages start out as macro tools, and writing a script using an XML-based tool does not make it less of a "program" than if the same script is written in Perl, Python, or Ruby.

Generally speaking, saving time by using software to generate highly repetitive code is a good idea. The potential downside is that you may lock yourself into a platform--that is, you are limited to functionality that the code generator provides. Whether or not a code generator (or programming language) is worth using entirely depends on how effective it is for a given problem.

Don't fall for the mental trap of thinking that some formats like XML or even HTML are dead "data" and other formats like C++ and Python are "code". Data and code are interchangeable. Need an example of "code" in HTML? Consider the following:

HTML is a declarative language. In it you specify things that exist, in the manner of "here is a paragraph, here is a heading" and so forth. Python and other programming languages have imperative parts where you specify "now add x and y, now write x to memory" and so forth.

You can invert this relationship, however. In the case of HTML, it becomes imperative when fed through a browser. "Here is a paragraph with these properties" is interpreted by Firefox as "now render a body of text with these parameters." As a file, HTML is simply dead data, but in the context of an interpreter, it becomes live code. The same happens in reverse with Python. During execution, your Python instructions become directives to the interpreter, but the Python file itself is simply dead text. In a sense your Python program sits there as a collection of potential instructions in the form of data until you run it through the Python interpreter. In exactly the same way, and HTML sits as data in a file until it comes time for the browser to act on it.

XML is a data format, but instructions are a type of data. You can use XML to contain imperative statements, such as mathematical operations or function calls. Whether you interpret that XML as data or code depends entirely on the context; in a sense, all computer data is both data and code simultaneously. The distinction between data and code is a human convention, not a reality inherent to the computer.

Edit: I guess I should concede here that on the processor architecture level, there is often a very concrete distinction between code and data. Code is what gets fed through the processor core and changes the state of the machine. A typical architecture keeps the bits that are waiting for execution in a separate area of memory from other data which does not represent executable code. But this distinction quickly becomes blurred when you start talking about interpreters.