#begin

Meta-Programming

When I hear this term I think about static analysis. I’ve done some meta-programming in University to do static analysis on a Java project. It was SQLite if I remember correctly. But in The Pragmatic Programmer Andrew and David have a different definition for meta-programming. They don’t define it explicitly but I think we can derive one from the following quote: “Use metadata to describe configuration options for an application: tuning parameters, user preferences, the installation directory, and so on.”

So what they mean by meta-programming is configuration through data or config files.

They say that details mess up the pristine state of our code, especially if they change often. So we want to extract the mess from our actual implementation. We want to make code highly configurable and keep the software “soft”. Just to quote Uncle Bob; “if you make software hard to change you have thwarted the reason for its existence”. However, we also want to remind ourselves of Prof. Ousterhout’s opinion that extensive use of configuration files is a code smell and just exposes complexity to the end user. So we really need to find a balance here. We need to expose the right data through configuration and not just blindly throw everything in there.

So Andrew and David go on to define what they mean with metadata; they say that meta data is data about data. Ah, that’s not particularly useful. But it is the correct definition. One the most precise examples of metadata is a schema for a database. The schema, is meta data that describes the shape of the actual data. I really never though about it this way but its really great example of metadata.

But they say that they use the term in its broadest sense; “Metadata is any data that describes the application – how it should run, what resources it should use, and so on.” And, typically, metadata is used at run-time, not compile time. An example they give is hiding or showing specific portions of the UI, like a toolbar. In modern software this is often exposed in the settings or preferences. Think about your IDE or even de Unity3D editor. You can create different setups and layouts yourself. Imagine if they needed to make different executables for such things. There would be an immense number of combinations.

Metadata-Driven Applications

Andrew and David say that they want to go fat beyond using metadata for preferences. Their advise is to configure and drive the application via metadata as much as possible. They say that we need to think declarative, describing what needs to be done, not how it’s done. Does this sound familiar to you? This is exactly how modern DevOps, infrastructure as code is done. It’s kind of the perfect example. This way we create highly adaptive and dynamic systems. Thus Andrew and David propose the following rule: “Put abstractions in code, details in the metadata”. And, I couldn’t agree more. I also think that Prof. Ousterhout would agree with this to certain limit. You can always overdo things of course. Again, balance is key.

Next they even list some benefits of this approach, which I will quote directly from the book:

• “It forces you to decouple your design, which results in a more flexible and adaptable program.”

• “It forces you to create a more robust, abstract design by deferring details – deferring them all the way out of the program.”

• “You can customize the application without recompiling it. You can also use this level of customization to provide easy work-arounds for the critical bugs in live production systems”

• “Metadata can be expressed in a manner that’s much closed to the problem domain than a general-purpose programming language might be.”

• “You may even be able to implement several different projects using the same application engine, but with different metadata.”

So all of the above indeed make perfect sense but I think that Prof. Ousterhout would maybe object to the second benefit they list: ”It forces you to create more robust, abstract design by deferring details – deferring them all the way out of the program.” This is indeed a very nice benefit but can also lead to the kind of over-configuration Prof. Ousterhout is warning us for. So you need to keep an eye on this.

Business Logic

Business logic is another thing that could potentially benefit greatly from metadata since the business rules are likely to change. Especially in some domains, the rules change more often than others. For example, your game systems and gameplay logic will change far more often than the logic doing IO to the file system. Not to mention other domains outside of gaming like tax or government or other highly regulated industries.

So, since these business rules are likely to change it’s a good idea to maintain them in a flexible format. This is also what Uncle Bob talks a lot about in, well, all of his books. Everything he writes about boils down to isolating code into modules that are independent of each other, especially the business rules.

Andrew and David mention that you can extract business rules in some sort of rule-based system which is data-driven. This way you can adapt systems, even at runtime, without having to touch the code. I’ve personally used this strategy on multiple occasions. Using data to describe gameplay flow, animations and even entire programs by injecting data, UI and code at run-time using LUA. Although that might count as cheating a little bit, as LUA is executable code and not data. Maybe if we could get Clojure, or any other LISP, to run properly in Unity3D we could take this to a whole other level. There is some really cool work being done on Clojure CLR as we speak but I don’t think its ready yet.

David and Andrew also mention the use of DSL’s again. You can create some mini-language for customization purposes. I believe that most modern software has such capabilities. I’ve written many kinds of Unity3D applications that were driven by data. The data controlled how the scene looks and what gameplay was active or inactive. This will give you a lot of flexibility and reuse between modules.

Cooperative Configuration

Next they mention another interesting bit which is about software configuring itself, or other software. They mention the fact that your OS configures itself to the hardware that is available in your system. Additionally, we have many kinds of software that keeps themselves updated, like browsers or notoriously windows (update). These darn updates never come at a convenient time.

They also recognize that automatic configuration can be tricky sometimes. So they advice to take a hybrid approach. For example, maybe do automatic updates for patches and bug-fixes, yet leave the major updates to be triggered manually. I think this is how most modern software does things now.

Don’t write dodo-code

Don’t let your code die like the dodo bird. Code should always be adaptable and flexible. The use of meta-data will make sure your code will not go extinct just like the bird. So don’t write dodo-code!

#end

01010010 01110101 01100010 01100101 01101110