Thursday, January 7, 2010

4 Levels of Abstraction for Computer Programmers

Every program is divided up into different levels of abstraction and the goal of any project is to write code that mirrors the problem as closely as possible. The Forge computer program is about Magic: The Gathering, so it should reference things like players, cards, library, and creature. Some of the high level of code in Forge should almost be readable by non-programmers.

In "Code Complete" by Steve McConnell, he writes about the 4 different levels of any computer program.

Level 1 is programming in a language "higher" than assembly. Level 2 is Computer Science structures like stacks, queues, linked lists, tress, sort algorithms, search algorithms, etc... Level 3 is low-level problem-domain terms. "At this level, you have the primitives you need in order to work in terms of the problem domain. The routines might be too primitive to be used to solve the problem directly, but they provide an Erector (Lego) set that higher-level routines can use to build a solution to the problem."

Level 4 is the highest level and is defined as "high-level problem-domain terms" "This level provides the abstractive power to work with a problem on its own terms. Your code at this level should be somewhat readable by someone who's not a computer-science whiz. Code at this level won't depend much on the specific features of your programming language because you'll have built your own set of tools to work with the problem. Consequently, at this level your code depends more on the tools you've built than on the capabilities of the language you're using."

The goal is to build the other levels so that you can program on level 4, in terms of the problem itself. Forge version 1 is probably written on level 3 1/2. I tried my best to get to level 4 but I just didn't have the "big picture" in mind. My main priority was to get the code running, so I mostly programmed at level 3. Hopefully in version 2 I can get to level 4. Personally I always things of programming like building a house. First, you start with a good foundation. Then you build the wall and finally you put on the roof. If there are any problems building the house, they will affect other parts of the house as well.

If you lower level code isn’t robust, your high level code won’t be robust either.


Silly Freak said...

thanks forge, this is a great post in my opinion. I think another important thing is that level 3 should be flexible enough to plug in new tools when needed. If these tools are later developed on level 4 (i think "tool on level 4" is the essence of a hack), you slowly fall back on level 3 1/2

Forge said...

Talking about programming is hard because the "devil is always in the details" but if you know about different levels of abstraction, you can code better.

Incantus said...

This is my approach for Incantus. I believe layer 3 is equivalent to designing a mini DSL for magic - either internal (like Incantus) or external (i'm not sure if any projects do this fully - most only work for simple cards). This layer provides the basic set of functions/objects (like characteristics, cards, replacement effects, things you can do to cards) which then lets you implement cards in layer 4. I agree with Silly freak, if layer 3 is flexible enough, it should be possible to accomodate any future changes to the rules (for example, updating Incantus to support the major M10 changes only took a few evenings).