Here is the situation:

1. A prototype of Gogetter has been built (and rebuilt once) and has been in heavy production use for several years, with two major projects built on top of it.
2. That prototype is proprietary.
3. I’ve learned so much from building the prototype that it seems best just to rebuild it from scratch as open-source. It won’t bear much resemblance to the proprietary prototypes.

What are the pieces that need to be built in the Gogetter project? (Not necessarily in order.)

So I’ve claimed that Gogetter is interesting. What makes it interesting? I’ll explain here why I find it interesting, and it seems pretty likely to me that you might find one or more of these points interesting, too. Maybe not all of them! That would be perfectly OK.

Aside: I do not claim that the Gogetter framework/paradigm is suitable for all programming problems. No tool is! I am totally confident, however, based on extensive experience, that it is very well suited to a certain narrow class of extremely hard problems. And it is an open question to me how much more widely its usefulness might extend. I am fairly confident of two things, though. (a) Gogetter’s usefulness does extend to more kinds of problems than the one I built it for. (b) Its usefulness does not extend to a really wide class of problems; it is not a competitor to Object-Oriented Programming, for example!

I’ll frame this as a series of observations. In most cases, if you’ve read Parts 1 and 2, you already know enough to see that my observations are accurate. In a few cases, you’ll have to take my word for it until we have more publicly-accessible experience with Gogetter. I will not attempt to distinguish these in the text.

Starting with just the finance charge calculation

Here’s how we would code the calculation of our finance charge in Gogetter. For this first go-round, we’ll leave out the other parts of our credit-card statement. The syntax here is an idealized Gogetter syntax that is only pseudocode at this point in time; I’m sure it will take some tweaks to make it realizable in C++.

An example, and how we might code it at present

We need an example to work with here. So: Suppose we’re writing code to calculate data to go on a credit-card statement. Consider the ‘finance charge’. How is this calculated? Well, the code will obtain several other pieces of data, such as

• the average daily balance on the account
• the interest rate on the account
• the number of days in the statement period

and it will do some calculation on them that results in the finance charge.

For the last step, someone might write something like

Summary:

• Gogetter is a programming framework for complex, data-intensive computing problems.
• It supports a new programming paradigm which has some remarkable properties in the areas of scalability, code quality and debuggability.
• It provides universal unit-testability of all calculations.
• It gives you universal caching of all calculated values.
• So you get all the traditional performance and correctness benefits of caching.
• Plus it supports a new kind of caching benefit that targets the avoidance of cache misses, the biggest performance problem in computing today.
• Its prototype exhibits stunningly good performance.
• Code quality: It makes it hard to write bad code and easy and natural to write good code.
• It shows great promise for promoting code reuse.
• There is a natural and stepwise refactoring path into it for legacy codebases.
• And it’s coming soon, as header-only FOSS, to a C++ development environment near you.

Before you read more about Gogetter, you may want to know:

1. I never set out to create anything like this. I just fell into it. There were some yicky problems in the codebase at work that I wanted to tackle, so I tackled them. Then I noticed that the result was interesting. Most features of Gogetter really just flowed out of the problems I was trying to solve.