bookkeeping
An animal is trying to live. It has inflows and outflows of various things - it eats things, it drinks water, it shits. Temperature might flow in or out too.
It has stocks of various kinds, food-in-stomach, oxygen, ATP, sugars, fats, and so on.
It can perform various maneuvers, transforming one thing into another, such as shivering (spending energy to raise temperature), or chasing a prey animal (spending energy to possibly get food-in-stomach).
To some extent, everyone, at every scale (animals, humans, corporations, nations), is doing something like this. What we want to do is be more effective at it.
What we want to know is - was that maneuver advisable? Was it a good thing to do?
The idea of bookkeeping is to use an abstraction (the same kind of thing - economy of design) modeling each stock, AND with each flow that crosses the border of the entity. This is like abstracting numbers from piles of bottle caps, but instead of bottle caps we're talking about bites of flesh, inches of blubber, and shits. This abstraction is called an account. It models and tracks the actual pile in the same way that an entity in Object Orientation is sometimes supposed to model and track something in the real world (a User object in a web-site or a Slide object in a laboratory instrument software).
Viewed as an object, an account has only one mutator - append a transaction.
The account is responsible for keeping a running total, and for many purposes,
that's the only accessor. However, the account is not just a variable that can be added to and accessed. There are two refinements.
One difference is the account's denomination - by which I mean its response to changes in valuations. I think valuations are under-explained in introductory explanations of accounting. If an account is a model of a pile of gold, even if you routinely work with it, for convenience, as "I put 3 dollars worth of gold in", and "I took 5 dollars worth of gold out", it will respond to changes in the price of gold as if it models a pile of gold. If the price of gold goes up, then the amount of gold in the pile stays the same, and your bookkeeping procedures have to handle that - unlike an account that models a pile of dollar bills (unless you routinely work with it as "I put an eighth of an ounce of gold worth of dollars in the pile" and so on).
The other is debugging and reporting. The account's internal write-only log, and the fact that each transaction is oriented - referring to (usually) one other account, and even one other transaction in that account, means that the account is also a partial model of the entire enterprise.
Aside: I think this architecture, of decoupled objects, each modeling some particular aspect of the outside world and simultaneously modeling the entire enterprise, is also present in many other things - each router on the internet has a routing table expressing which way traffic should go to get to different addresses, which can be viewed as an abstract map of the entire internet. A distributed version control system like git might contain (if the branches correspond to people working on those branches, and therefore to repositories) a model of the entire distributed system inside each component of the entire distributed system.
Okay, suppose we have three transactions in an RTS - spend bundles consisting of both gold and lumber to grow workers, use workers (and time that we don't model) to obtain gold from a mine, use workers (and time that we don't model) to obtain lumber from a forest. What accounts to we create? One for each stock: gold, lumber, workers - and one for each boundary flow: forest, mine, growth. Realistically, we would have nonlinear valuation of stocks, but smooth nonlinear valuations are approximately linear for small changes - so let's imagine that we do the books in terms of lumber and currently each gold is worth 10 lumber, each worker is worth 250 lumber, and (of course) each lumber is worth 1 lumber. Then given options like "spend 5 gold and 100 lumber to get a worker or not?", we can abstract the option to "spend a total of 150 lumber worth to get something of 250 lumber worth?" and decide "yes please".
I think we can also use the records to do a sort of backup or backprop, adjusting our valuations (initially unmotivated or intrinsic valuations) to instead reflect the instrumental value. For example, we might, based on our records of transactions with the mine and with the forest, identify that one worker generally produces 6 gold per minute or 50 lumber per minute. Then (assuming we have some way to do discounting) we can incorporate the instrumental value of a worker (that is, as an instrument to obtain lumber) into the valuation of the worker itself.
It has stocks of various kinds, food-in-stomach, oxygen, ATP, sugars, fats, and so on.
It can perform various maneuvers, transforming one thing into another, such as shivering (spending energy to raise temperature), or chasing a prey animal (spending energy to possibly get food-in-stomach).
To some extent, everyone, at every scale (animals, humans, corporations, nations), is doing something like this. What we want to do is be more effective at it.
What we want to know is - was that maneuver advisable? Was it a good thing to do?
The idea of bookkeeping is to use an abstraction (the same kind of thing - economy of design) modeling each stock, AND with each flow that crosses the border of the entity. This is like abstracting numbers from piles of bottle caps, but instead of bottle caps we're talking about bites of flesh, inches of blubber, and shits. This abstraction is called an account. It models and tracks the actual pile in the same way that an entity in Object Orientation is sometimes supposed to model and track something in the real world (a User object in a web-site or a Slide object in a laboratory instrument software).
Viewed as an object, an account has only one mutator - append a transaction.
The account is responsible for keeping a running total, and for many purposes,
that's the only accessor. However, the account is not just a variable that can be added to and accessed. There are two refinements.
One difference is the account's denomination - by which I mean its response to changes in valuations. I think valuations are under-explained in introductory explanations of accounting. If an account is a model of a pile of gold, even if you routinely work with it, for convenience, as "I put 3 dollars worth of gold in", and "I took 5 dollars worth of gold out", it will respond to changes in the price of gold as if it models a pile of gold. If the price of gold goes up, then the amount of gold in the pile stays the same, and your bookkeeping procedures have to handle that - unlike an account that models a pile of dollar bills (unless you routinely work with it as "I put an eighth of an ounce of gold worth of dollars in the pile" and so on).
The other is debugging and reporting. The account's internal write-only log, and the fact that each transaction is oriented - referring to (usually) one other account, and even one other transaction in that account, means that the account is also a partial model of the entire enterprise.
Aside: I think this architecture, of decoupled objects, each modeling some particular aspect of the outside world and simultaneously modeling the entire enterprise, is also present in many other things - each router on the internet has a routing table expressing which way traffic should go to get to different addresses, which can be viewed as an abstract map of the entire internet. A distributed version control system like git might contain (if the branches correspond to people working on those branches, and therefore to repositories) a model of the entire distributed system inside each component of the entire distributed system.
Okay, suppose we have three transactions in an RTS - spend bundles consisting of both gold and lumber to grow workers, use workers (and time that we don't model) to obtain gold from a mine, use workers (and time that we don't model) to obtain lumber from a forest. What accounts to we create? One for each stock: gold, lumber, workers - and one for each boundary flow: forest, mine, growth. Realistically, we would have nonlinear valuation of stocks, but smooth nonlinear valuations are approximately linear for small changes - so let's imagine that we do the books in terms of lumber and currently each gold is worth 10 lumber, each worker is worth 250 lumber, and (of course) each lumber is worth 1 lumber. Then given options like "spend 5 gold and 100 lumber to get a worker or not?", we can abstract the option to "spend a total of 150 lumber worth to get something of 250 lumber worth?" and decide "yes please".
I think we can also use the records to do a sort of backup or backprop, adjusting our valuations (initially unmotivated or intrinsic valuations) to instead reflect the instrumental value. For example, we might, based on our records of transactions with the mine and with the forest, identify that one worker generally produces 6 gold per minute or 50 lumber per minute. Then (assuming we have some way to do discounting) we can incorporate the instrumental value of a worker (that is, as an instrument to obtain lumber) into the valuation of the worker itself.