T4 – Good, Bad and Ugly

So, there’s a buzz on T4 and you’re trying to work out what it means to you?

But, first, what does it mean to me. Why do I spend more than half my time on unpaid research? The next generation of software development will have three legs to stand on: automation, composition, and development process. That’s the whole story. Code generation is the most accessible tool in the automation space – and that space is one-third of the future. I’m ready for that future. I believe technically the industry is ready to be there. I think we have a ways to go to actually get there together and currently my research is in the compositional architecture space.

Code generation is relatively mature. It’s entirely usable. You’re probably using it today. You can probably use it to make your applications better today. You can probably use it better today.

T4 (*) is a very sweet template language. Gareth Jones and the totally awesome DSL team at Microsoft brought you this tool. Its original purpose was to express DSL in 3GL code (VB/C#) but ultimately all transformations are just that, transformations. Generative transformations are almost always merge transformations – you’ve got something called metadata that describes aspects of your application, and you’ve got something called a template and running the template produces something – in our case code. Any transformation engine (XSLT, T4, VB literal XML, etc.) can produce code. T4 can produce any kind of text output (I want blog posts that people customized their Christmas letters by applying category metadata to people on their list and then ran T4 to produce a sensible letter, extra points for outputting Office XML in a pretty format instead of cutting and pasting the results).

This post is the overview of a four part series. Follow-on posts will cover the good, bad, and ugly of T4.

· The good is that it works. It’s a great opportunity.

· The bad is that the level of support for it is way below what we expect from our tools.

· The ugly is an attitude that generation templates are just some under the hood gunk that doesn’t matter. It’s code. You decide whether to write good code or bad code.

I believe we do our work on top of two sciences: The hard science of traditional Computer Science and a fluffy science that is the collision of economics, business and management engineering, human ergonomics, and Computer Science. CS offers the gears – the science of building the machine is more interesting. If there’s a science, we can discover (not invent) principles. I think the code generation principles I published in 2002 still stand:

1) The application remains the responsibility of and in the control of the end programmers

a. It’s that desk someone beats on

b. Primarily in the automation sense, this means they control templates

c. Templates must be in an accessible language

d. Templates must be of high quality to allow modification and reuse

e. Separation of concern applies to templates

2) Metadata is distinct, available and friendly to templates

a. Friendly is necessary to achieve the first principle (There is an approximate N^M ratio of template complexity where m is metadata friendliness factor – the exercise to prove this is creating templates directly with XSD metadata or slightly better EDMX, and treat yourself to something friendly)

b. Metadata is a major point of debugging, it must be viewable/reportable by humans

c. Metadata should come from many sources

d. Separation of concerns applies to metadata

e. Metadata is the business: it must be owned by it and morph between technology

3) Generation should be automatic and simple

a. Simple inclusion in development workflow is necessary to achieve the first principle

b. No checklists, it just happens, one click or no click

c. This means “no friction” in today’s parlance

4) Hand crafted code is sacred and protected

a. Handcrafted code is critical to achieving the first principle

b. Humans are creative, they don’t do things the same way twice

c. Handcrafted code must be embraced by code gen architectures

d. Handcrafted code must be physically protect from mistakes)

5) Generated applications are of equal or higher quality

a. High quality applications are consistent with the goals of the first principle

Post navigation

One thought on “T4 – Good, Bad and Ugly”

Just curious: What kinds of things do use code generation for? what are the scenarios? Have you looked into Metaprogramming such as what is available in Ruby? Would that type of language support address a significant percentage of your scenarios if something similar was available in VB and/or C#?