Great Abstraction

What makes an abstraction a GreatAbstraction?

I give short explanations in terms of the Unix file system calls.

An example of a GreatAbstraction which is not an API might be nice. File formats come to mind, but I don't think there are any qualifying ones. Perhaps a non-computing example would help? -- DanielKnapp

Pure mathematics is composed almost entirely of examples. (Say, group or topological space. Or even, though this is an informal abstraction only, that of space -- what is it that the ideas of "topological space", "metric space" and "vector space" have in common?)

Within the computing field, the notions of class, list, window, and relational database (picking a few examples from many) are great abstractions of this "informal" kind. Going from "informal" to "formal" generally means providing an API or something similar (a type system, or a set of classes or functions, or whatever). Programming languages at any level above assembler are abstractions. Some of them are great, but I shall avoid saying which ones.

Four dimensional space plus time is without a doubt the greatest abstraction ever devised. Humans learn this abstraction at the toddler stage and humanity first learned it about three thousand years ago. It's such a fantastic abstraction that even blind people can learn it just from their hearing and sense of touch. And without the abstraction of time, it becomes exceedingly difficult to remember the past or plan for the future, though obviously it's doable since humans managed to build civilizations before they invented modern 'extended linear time' as an abstraction.

I wish the first author above hadn't used the Unix filesystem API as an example of a great abstraction, because it's a piss poor abstraction. open() is one of the GrossDeficienciesOfUnix. Great abstractions in computer science include:


Exceptions are mentioned in the list above. Is their absence really a necessary property of an interface which is a GreatAbstraction? In C, any exception-like mechanism is ugly. In other languages (not naming names to avoid looking like a troll), it is not. Perhaps the issue with them is that they supposedly make it difficult to understand a program's behavior? Yet littering code with checks for out-of-band return values and other tests for error conditions obscures the algorithm it implements and is at least as non-ideal as a well-designed exception system. -- DanielKnapp


GreatAbstraction produces ClearEncapsulation.

Which is true when there's something to encapsulate. What does the concept of space encapsulate?

I looked up "Space" in the Shorter Oxford Dictionary and its definitions take up an entire page. I guess that was what you were saying - that the concept of space cannot be encapsulated in that form of ClearEncapsulation. True. But when we need to access the contents of a current concept of space within a computer process, we have a clear enough encapsulation of "space" to define access. Like we can say Customer.Data = Get.Customer.Data(Customer.Reference), which abstracts away any physical implementation details, states clearly the intention and allows the Get.Customer.Data process to access the relevant database in any appropriate manner. Actually, I was wondering what the concept of space encapsulates in physical reality. Software abstractions tend to encapsulate something, some implementation of the abstraction. But in physics, what do the concepts of space+time or spacetime encapsulate? Or going back to software, PlanNine and Unix both have the concept of a namespace, and I'm not sure what makes it a clear encapsulation, although it's definitely a great abstraction. Saying that a concept encapsulates something runs into problems when it only abstracts part of that thing and not the totality of it. For example, physical space doesn't abstract away fields and field values at specific points. And namespaces don't abstract away the semantics of the objects in the space, just the syntax to access them. This raises some questions. Going back to encapsulation in software, what if the reason some software abstraction encapsulates is the mere fact that it's an API or an object? Objects encapsulate and isn't it true that even bad abstractions rendered as objects nonetheless encapsulate? If that's the case then 'great abstraction => clear encapsulation' hinges on the meaning of 'clear' more than 'encapsulation'. And at this point, the term 'clear' is much too vague though it does provide a hint.

I think a great abstraction hsa something to do with the boundaries of the abstraction. That's the hint which clear encapsulation provides. Some desirable properties in abstractions are,

So a great abstraction is one that will stand up to various use and abuse. It's also one that will persist in the minds of those who know it both because easy to grasp and recall, and because it's difficult to simplify or otherwise improve. And it's one that is easily understood, transparently fits the uses and needs it's put to, and will be reinvented again and again and again every time it disappears.


A GreatAbstraction shouldn't be described in terms of its persistence, but rather in its utility. Persistence and longevity are incidental properties of abstractions, created only by the social environment in which the abstraction proliferates as a meme - you don't need to let anyone else know about a GreatAbstraction for it to be great. Utility for abstractions is more measurable: a GreatAbstraction is readily applied to a wide array of different domains, lacks any properties one should consider 'accidental' or 'arbitrary' or 'unnecessary' (degree of abstraction is ultimately determined by the number of properties abstracted away; you can't abstract away everything or you end up with nothing, but for any property in the GreatAbstraction you ought be able to provide a reasonable explanation as to WHY it is there and WHY it is necessary), and is readily combined (without arbitrary restrictions) with other GreatAbstractions (since any abstraction, by nature, always has variables - those properties that have been abstracted away). As a consequence, any pre-implementation of a GreatAbstraction (with all its open variables ready for injection) should be a great addition to a language library, if not the core language. By observing this fact, one should note that GreatAbstraction should lead you straight to KeyLanguageFeatures

Unfortunately, GreatAbstractions often aren't easy to understand. A lot of people have difficulty with folds, monads, CategoryTheory (abstracting mathematical topologies), homomorphisms, coinductives, etc. The problem seems to be keeping the abstraction in one's head - the lack of details makes them a bit slippery, at least until one possesses considerable experience with their applications. As an example, I've seen some GreatAbstractions in the Boost and Fusion C++ template metaprogramming libraries (including field accessors, field iterators and visitors, expression templates, lambdas, class-independent interface capture, formatters, loop inverters (so you can iterate over a multi-layer for-loop), etc. ... and I can say for certain that many of them truly blow the minds of many traditional C++ programmers (i.e. the vast majority for whom template metaprogramming is weird compiler voodoo magic). That forces me to add addend the above paragraph: GreatAbstractions are excellent to already have in place and accepted by the infrastructure, because they'll fit any problem; but programmers won't be able to learn or use the GreatAbstraction if and until they bump into several problems that require it (i.e. after they've written several specializations, and are then getting ready to refactor). And writing specializations to handle stuff that your old programming language already did perfectly well is, very simply, both irritating and frustrating. Therefore, there had darn well better be some GreatSpecialization?s and GreatDefault?s readily available for day-to-day use; these will avoid frustration for the normal cases AND provide examples of the GreatAbstraction when comes time to use it.

As a final note, your wonderful GreatAbstractions can be a major source of frustration if the infrastructure isn't already there to support it. You can easily wrap anything from the environment or operating system in the GreatAbstraction, but you can't go the other direction. You CantAbstractMuchPastInterfaces; if your GreatAbstraction isn't supported outside the language, you'll be forced to write all sorts of irritating interface code that will only work for some specializations of the GreatAbstraction, just to let you communicate back outwards towards your OS and environment. But LanguageIsAnOs. GreatAbstractions for languages are also GreatAbstractions for OperatingSystems. There isn't any reason NewOsFeatures shouldn't include support for adding arbitrary new GreatAbstractions.


CategoryAbstraction


EditText of this page (last edited May 13, 2008) or FindPage with title or text search