The title of this journal is a threefold pun.
In standard programmer's jargon, functional abstraction means decomposing a program into a network of black boxes called 'functions', each of which to some degree delegates details of implementation to other functions.
Every time you summon Google by punching 'google.com' into the address bar in your browser, you're making use of functional abstraction: you don't care how your computer makes contact with some other computer which is playing host to Google, or anything about that host or even that it exists -- you just want the Google user interface to appear.
And that UI is itself a further instance of functional abstraction: you give it your search string, and ask it to give you the most relevant things it can find in its vast index of the web, desiring to know as little as possible about how the delicious information sausage it serves to you was prepared. In between you hitting the return key on a search for 'Otto von Bismarck' and the apearance of a list of links before your eyes, literally thousands of computers have been indirectly involved, but do you give a fuck about what they did and how they did it? Of course you don't, and you couldn't work (or procrastinate) effectively if you needed to know much about any of that.
This is a concept that's been found absolutely indispensible in the design of computer programs, but its application extends far beyond that domain to encompass the design of any nontrivial structure which serves any sort of purpose. Perhaps the reason you're researching Bismarck is that you're a history postdoc doing a bit of drudgework for a professor you're attached to. He asks you to look up information on some of Bismarck's economic policies, and doesn't care how or where you get it as long as he can trust it and it doesn't create any problems for the argument he's trying to make. Friend, you too are part of the Great Chain of Functional Abstraction -- when you go to work, when you go to the grocer, and when you go to the ballot box.
Functional abstraction, in this sense, is a kind of adaptive ignorance: it is a matter of each part of a system knowing only what it needs to know. One of its benefits is flexibility and modularity of means: with respect to the details you've ignored, one way to skin a cat is as good as another and if the abstraction is successful you'll never know the difference. Once you have this concept, you can see it everywhere and gradually come to understand that civilization depends entirely on it.
The second term of the pun is that you can parse 'functional' in the utilitarian sense and 'abstraction' as a thing rather than an act -- that is, a useful generalization. Our language is essentially built of these, though utility is of course in the eye of the beholder, or rather the intent of the user. A central thesis guiding the work documented here will be that most of the bugs in our cultural software are due to abstractions run amok, having pathological side-effects or being purposely abused.
Abstractions can be good or bad from social as well as individual points of view, and understanding their proper use constitutes one of the core obligations of being a good member of any society. So, brace yourself for frequent digressions on words: imagine if Wittgenstein and Fowler had a lovechild with a natural predilection toward computers and hermeneutics, and you get some idea of what you're in for here.
Finally, the third term of the pun is social. In an older sense, one's function is one's proper work seen in a larger context, and abstraction is a sort of withdrawal from the everyday hurly-burly. So it's about being withdrawn in one's work, though nonetheless serving some greater purpose. Consider this the public interface of one beast's laboratory, whose over-arching purpose is to fix what's broken with our thoughts -- starting from formal languages and artificial systems as tools and test cases, but always with natural languages and actual systems in mind. For any abstraction which is an end unto itself, is an evil.
