Runtime vs. Design/Compile Time

Chris asks:

At what point with code gen / templating do you start to think about doing all this codegen at runtime instead of compile time?

And if we were to be doing it at runtime would be be better served by using a dynamic language such as ruby to program in?

That’s a good point. In a perfect world, there would be no need for code generation. We would write nothing but business/domain specific code and everything else would just happen. But for well over twenty years we’ve been aiming for that perfect world and we seem only a few baby steps closer than in 1987.

In an imperfect world, we have two basic choices, manage an architecture and run a lot of code at design time or manage an architecture and run a lot of code at runtime. Both require a fair amount of configuration.

And both can offer the real long term benefit of switching away from coding code – which is transitory and dying before you even finish coding. We want to switch away from coding code and toward creating metadata which is a true business representation. Of course metadata changes. But it changes at the speed the business changes – not due to artificial technology shifts.

For my effort – I want the extra code run at design time to offer the best possible runtime behavior, including performance. I can extend an architecture I’m expressing in templates far easier than I can extend an architecture I am expressing via an OR/M tool. I also want to debug directly into code specific to the problem at hand – I want to debug through generated code, not an OR/M engine.

The next round of effort at making plumbing simpler from Microsoft is also code generation – Entity Framework. When someone gets the plumbing correct and we truly never need to care, we can turn off the code gen and go direct to whatever structure, however its’ done and completely ignore the problems code gen is primarily used for today. In the long term, we shouldn’t care about anything except the business problem we’re solving.

Dynamic languages certainly change the architecture. I’m looking forward to exploring them as the overall knowledge base expands. But we’ve been sitting with a pretty dynamic language in our laps for many years, the majority of us have programmed in it, and with the exception of precisely one person – everyone I know varies between mild distaste and downright hatred for it. I think a lot of Javascript’s problems have been related to debugging and platform issues, and I realize that there are differences between Ruby/Python and Javascript. However, if we didn’t fall in love with the dynamic aspects of Javascript in the last ten years, I remain slightly skeptical about dynamic languages in the next few years. Some of the differences, and our attitudes and skills may change as a result, are that the new languages have a broader platform base and we’re increasing our understanding of how to actually use them as opposed to hacking them enough to solve some trivial website detail.

But at the core, the technique for expressing metadata into a working application is not half as important as metadata at the core of the application, however its expressed.

7 thoughts on “Runtime vs. Design/Compile Time”

  1. > everyone I know varies between mild distaste and downright hatred for it.

    Were people’s frustrations with javascript with javascript the language or the poor implementation on the part of browser vendors + the lack of a good debugger?

    I think in a dynamic world you don’t really need an OR/M…or maybe just a very thin one, because the database itself is used to build the model.

    But I think getting the object to the database is just a very small piece. I’m not sure how you would build a GUI, but my vision would be something like:

    Entity Address
    #custom behaviors, but don’t need to declare properties

    UserInterface AddressForm

    layout :grid
    row do
    input :states, :on_change => :update_cities

    row do
    input :cities

    row do
    command :save, :execute => :save_address

    def update_cities
    cities = Cities.find_for_state :state
    reload_input :cities, cities

    def save_address


    So I totally just made that up, but the idea is that I’m still programming in metadata, but the behind the scenes stuff could figure out to generate WPF form or HTML. I think we’re both trying to get to the same place, but I would rather have a programming language *be* my template syntax instead of some form of XML or ‘template’

  2. I agree completely that we want as much as possible in metadata. I actually think we have progressed significantly in our capability to do that. Code-generation tools are much more accessible than they used to be, as is our ability to make that generation dynamic rather than static.

    There is always a line though, between what we want the freedom to express in code, and what we want to be the default (unspecified, generated) behavior. It seems like understanding that relationship, and providing natural extension points is still somewhat of a black art. Do Dynamic languages help in doing that?

  3. Chris,

    Thanks for your comments!

    I agree on the JavaScript perhaps getting a bad rap due to implementations. It’s good to see both efforts to fix that and focus on real tools with the other dynamic languages.

    OR/M – whether design or runtime – exists precisely becuase we can’t map directly to databases. I know Ruby on Rails does a pretty direct mapping (last I checked it did provide an option for mapping but I never looked under the hood for that. I think demanding databases and business objects directly syncrhonize is a bad idea.

    Did you have in mind the lines in your code that are”input cities” etc to manage or something different? I am generating UI’s but I’d like to wait that discussion until I get through the current round of stuff and a round of harness stuff. I think there is a lot more interchange of ideas still needed for UI generation.

    Is there anything in what you are thinking here that requires a dynamic language to simplify?


  4. Steve,

    I see the big picture of deveopment as a huge mess that we divide and conquer. Attacking the biggest problems and removing them leaves room for a better understanding of the next round of simplification if that makes sense.

    I think we’ve got the main extension points for the plumbing pretty well down. Moving into the broader application there is a not to do. I’m not sure of the relative contributions of static langauges, dynamic languages, workflow plug ins, rules engines and other techniques. We, rather obviously, won’t solve it all with code generation. And we will definitely be doing a lot with handcrafted code for now. But I’m also excited about the next round which needs to address both bigger and smaller issues than the block of things code generation does a good job with.


  5. I don’t think that a business object need map 1:1 with a database. But for cases where you would have a template like
    public class < %= table.ToClassName %> {
    < % for column in table.columns %>
    public < %= column.CLRType %> < %= column.ToPropertyName %> {get; set;}
    < % end %>

    Why do you need to have the template? why not just have the class query the DB and whatever columns it finds those are the properties. Also if I want to add / modify the behavior of a column I can just do that as part of the class.

    My example was trying to say that I tell the UI how to lay things out, grid / flow etc. In this case I said grid, so I would need to tell it what goes in each row. When I call input it should look at what :cities refers to and generate an appropriate input field.

    I don’t know that I’d say a dynamic language is required, but with as sophisticated as your code gen system seems to be it is almost as if you are building your own language on top of VB . If that’s the case it seems like why fight with VB when there are languages that have better support for metaprogramming.

  6. Chris,

    How do you know which are one to one and which are not, and how that will evolve? How would you create a system where the code accessing teh business object would not need to know anything about its one to one nature so that it oculd change over time?

    I never create a class that iterates over the table columns. It always iterates over the definition of a business object which may or may not map directly to the database.

    The templates are all design time. By the time we get to runtime, we have a rather large pile of static language code. I’m not sure how that will evolve as I better understand dynamic langauges.

  7. I don’t know if you ever really need to know that it is one to one.

    If I have a customer object and I can call Customer.Name from other code then I can, whether or not there is a column behind there shouldn’t matter. If there does happen to be a column in a Customers table called name, then I never needed to declare a property, if not then I did.

Leave a Reply

Your email address will not be published. Required fields are marked *